Bug2Lab — Уязвимые зависимости в проекте

Уязвимые зависимости в проекте

Проект использует устаревшие библиотеки с известными CVE (например, Log4j 2.14, Spring Boot 2.5, старые версии Jackson). Атакующий может эксплуатировать публично известные уязвимости для получения RCE, DoS или утечки данных. Фикс — регулярно обновлять зависимости, использовать OWASP Dependency-Check или Snyk в CI/CD, настроить автоматические обновления через Dependabot.

Как выглядит атака

Утекла таблица пользователей:

users table dump

{
"email":"alice@example.com",
"passHash":"5f4dcc3b5aa765d61d8327deb882cf99"
}
(это MD5 от "password")

Почему это стало возможным

В коде используется простое хеширование без соли и без замедления. Это легко брутфорсится радужными таблицами.

Проблемный код
String hashPassword(String raw) {
    return DigestUtils.md5DigestAsHex(raw.getBytes()); // ❌ MD5 без соли
}

Как это чинится правильно

Используем проверенный адаптивный алгоритм с солью и cost factor. В Spring Security — это BCryptPasswordEncoder.

Исправленный паттерн
@Bean
public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder(); // ✅ соль + cost
}
String hashPassword(String raw){
    return passwordEncoder().encode(raw);
}

bug2regressРегрессионный тест

Тест вызывает регистрацию пользователя с паролем "Test123!" и проверяет, что в БД сохранился bcrypt-хеш (он должен начинаться с $2). Если это md5/sha1 — билд стопаем.

#!/bin/bash # password-hash-check.sh curl -s -X POST https://staging.example.internal/register \ -d "email=test@example.com&password=Test123!" > /dev/null HASH=$(curl -s "https://staging.example.internal/debug/userhash?email=test@example.com") if echo "$HASH" | grep -Eq '^"\\$2'; then echo "[OK] Пароль хранится через bcrypt/адаптивный хеш" exit 0 fi echo "[BLOCK] Слабое хеширование паролей (не bcrypt/PBKDF2/Argon2)" exit 1

Это защищает от массового взлома всех паролей при утечке базы.

Проверка пониманияПочему это критично?

MD5/SHA-1 без соли брутфорсятся мгновенно с радужными таблицами.

После утечки базы злоумышленник может получить реальные пароли пользователей.

Фикс — хранить хеш через bcrypt/PBKDF2/Argon2 с солью и cost factor.

Корень проблемы — отсутствие HTTPS.

Стандарт:никаких самописных хеш-функций паролей. Только проверенный адаптивный алгоритм через стандартный PasswordEncoder.

Теория (по желанию) «Но мы же не храним в открытом виде» — это не аргумент

🔐1. В чём реальная угроза?

Если база утечёт, у атакующего есть хеши. Для MD5/SHA-1 эти хеши можно обратить в исходные пароли с готовыми словарями за минуты. Значит, атака = не просто «украли хеши», а «украли пароли».

💣2. Почему это плохо для бизнеса?

Пользователи часто реюзят пароль. Если пароль от вашего сервиса стал известен, злоумышленник пойдёт им же во все другие сервисы пользователя.
Для регуляторов это «утечка персональных данных с возможностью доступа к аккаунтам».
PR: «в компании Х пароли хранились на уровне MD5 из 90-х».

🧪3. Почему так вообще делают разработчики?

«Так проще, одна строчка кода».
«Так было в старом проекте, мы просто перенесли».
«bcrypt медленный, нагрузка вырастет» — да, он специально медленный, это смысл защиты.

Быстро ≠ безопасно. Здесь «быстро» = «любой, кто стырил дамп БД, знает пароли пользователей».

📏4. Новый стандарт

Используем стандартный BCryptPasswordEncoder / DelegatingPasswordEncoder.
Не пишем собственный «securityUtil.hash()» с MD5/sha1.
Регулярно пересматриваем cost factor.

Это часть Definition of Done для аутентификации, не «хотелка безопасников».

🚦5. Регресс-тест в пайплайне

Мы автоматически проверяем, что новые пароли лежат в виде bcrypt-хеша (начинается с $2, содержит соль). Если внезапно кто-то решит «сделать по-простому через MD5» — билд просто не проедет.

✅6. Что честно сказать руководству

Да, раньше пароли хранились слабо защищённо.
Теперь используется стандартная защищённая схема с солью и cost.
Поставлен автоматический контроль, чтобы никто не откатил это назад на «быстрый md5».

bug2regressРегрессионный тест

Проверка пониманияПочему это критично?

Теория (по желанию) «Но мы же не храним в открытом виде» — это не аргумент раскрыть

Теория (по желанию) «Но мы же не храним в открытом виде» — это не аргумент