Что уже устарело в Уязвимости: разбор методов и практик защиты веб-приложений
 

Введение
Если говорить про уязвимости в веб-приложениях, то надо понимать, что вместе с появлением новых угроз меняются и методы защиты, и подходы к тестированию безопасности. То, что пару лет назад считалось нормой и достаточной мерой, сейчас может быть не просто малоэффективным, а даже дать ложное чувство защищённости. Часто встречаю, как ребята продолжают пользоваться устаревшими методами, забывая про современные реалии и новые инструменты. Этот пост — про то, что именно пора забыть и что нужно обновить в своей безопасности.

Что такое уязвимости и почему они всегда меняются
Уязвимость — это такая штука в коде или конфигурациях, которая позволяет кому-то постороннему получить права, которых не должно быть, посмотреть закрытую инфу или нарушить работу приложения.
Веб-приложения могут пострадать от самых разных видов уязвимостей: классическая SQL-инъекция, XSS (внедрение скриптов), проблемы с аутентификацией и авторизацией, дыры в бизнес-логике, когда логика приложения позволяет делать запрещённые действия. Всё это постоянно меняется — серверные технологии, браузеры, поддержка новых стандартов, способы работы с кодом — всё влияет на то, что нужно делать по-другому.

Где чаще всего всплывают устаревшие методы защиты
Практически везде, где есть веб-часть с формами ввода, API, сессиями и базами данных. Это могут быть интернет-магазины, админки сайтов, корпоративные порталы и даже внутренние инструменты. Зачастую устаревшие методы уходят корнями в старые CMS, которые не обновляют, старые фаерволы (WAF), которые работают по простым фильтрам и не учитывают поведение, а также в привычки программистов — лениться ставить двухфакторную аутентификацию или правильно валидировать ввод.

Конкретные старые методы и почему их нужно бросать

- Простейшее экранирование HTML-тегов для защиты от XSS. Этот способ был популярен, но сейчас его уже много где обходят через хитрые цепочки (например, использование нестандартных кодировок, событий или атрибутов). Лучше брать на вооружение Content Security Policy (CSP), которая ограничивает загрузку внешних скриптов и не даёт браузеру выполнять вредоносный код. Традиционные библиотеки вроде DOMPurify тоже работают лучше, чем просто строчка с replace.

- Использование черных списков (blacklist) для фильтрации входных данных. Это прям классическая ошибка — постоянно появляется что-то новое, что не учтено. В итоге злоумышленник найдет лазейку. Правильнее делать белый список (whitelist), чётко прописывать, какие символы и данные разрешены, проверять типы и длину.

- Заброшенные версии CMS и плагинов. Даже если в них когда-то были какие-то методы защиты, без регулярных обновлений известные уязвимости остаются открытыми и на них быстро найдут эксплойты. Профилактика — регулярные патчи.

- Пароли без двухфакторной аутентификации. Сейчас это уже минимальный уровень безопасности, особенно если у вас нет ограничений по попыткам входа. Простой пароль может украсть любой, у кого есть база ваших пользователей. Двухфакторка (2FA) радикально повышает защиту.

- SQL-инъекции — раньше пытались просто фильтровать запрещённые символы или ключевые слова. Сейчас standard — это подготовленные запросы (prepared statements), ORM или безопасные библиотеки. Любые попытки побыстрому "пофильтровать" ввод — устаревшие и опасные.

Типичные ошибки в современном подходе к безопасности

- Надежда только на клиентскую валидацию. Она нужна для удобства пользователя, но все проверки должны дублироваться на сервере, потому что клиент может быть легко подделан.
- Использование небезопасных хешей для паролей, типа MD5 или SHA1. Современный стандарт — bcrypt, Argon2 или хотя бы PBKDF2. Без этого пароли можно довольно быстро расшифровать при утечках.
- Игнорирование обновлений и последних патчей. Очень часто я вижу, как владельцы систем откладывают обновления под любым предлогом — "пока работает, зачем трогать". Как раз это самая частая причина взломов.
- Реплицирование древних методик и техник из учебников прошлого десятилетия без учета трендов и особенностей новых сред. То, что работало под PHP4-5, не факт, что уместно в современных SPA и микросервисах.
- Отсутствие полноценного логирования событий и мониторинга попыток взлома или неправильных действий. Без этого тяжело быстро понять, что и когда стало поводом для атаки.

Практические рекомендации и примеры

Чтобы не наступать на старые грабли, предлагаю небольшой чек-лист для проверки защиты ваших веб-приложений:

Чек-лист:
1. Все формы и API валидируются на сервере с применением белых списков.
2. Используется Content Security Policy для ограничения внешнего кода и предотвращения XSS.
3. Пароли хранятся с современными хешами (Argon2/bcrypt).
4. Есть двухфакторная аутентификация или хотя бы возможность её включить.
5. Все библиотеки, CMS и плагины обновлены до последних стабильных версий.
6. В базе данных используются подготовленные запросы (prepared statements).
7. Настроено логирование успешных и неудачных попыток входа и подозрительных действий.
8. Используется современный WAF, который не просто блокирует по сигнатурам, а анализирует поведение.
9. Запущен мониторинг безопасности с автоматическими оповещениями об аномалиях.
10. Проведён аудит кода с использованием SAST-инструментов на этапе разработки.

Инструменты, которые помогут не наступить на эти грабли

- OWASP ZAP и Burp Suite — классический дуэт для ручного и автоматизированного сканирования уязвимостей. Они постоянно обновляются и поддерживают новые техники.
- SAST-инструменты для анализа кода (SonarQube, Checkmarx, CodeQL) — помогут поймать уязвимости ещё на этапе написания.
- Современные WAF, такие как Cloudflare, ModSecurity с расширениями, которые позволяют работать с поведенческим анализом атак.
- Средства автоматического обновления CMS и плагинов, например, Composer для PHP или npm для JS-библиотек, которые не позволяют затягивать с установкой важных патчей.
- Content Security Policy, добавляемая через заголовки HTTP или мета-тэги в HTML, ограничивает выполнение скриптов и загрузку внешних ресурсов только доверенными доменами.

Типичные «разводы» по безопасности — на что лучше сразу обратить внимание

Собираю распространённые моменты, которые часто ведут новичков в ложное чувство защищённости:

- «Я фильтрую < и >, значит XSS нет». Нет, этого недостаточно, современные XSS обходятся через другие углы, например, обработку событий, вставку URL-схем, различные JS-конструкции.
- «У меня есть firewall, значит всё под контролем». Старые фаерволы часто тупо по сигнатурам блокируют известные атаки, но пропускают «новые» варианты, в том числе «живой» трафик с минимальным изменением payload.
- «Двухфакторная аутентификация – лишний геморрой для пользователей». Да, баланс важен, но без неё проще украсть учетку через социнжиниринг или перебор. Некоторые проекты успешно внедряют 2FA и не теряют пользователей.
- «Я использую MD5, но с солью, значит все ок». MD5 давно не безопасен, потому что мощность современных компьютеров позволяет откатить и с солью.
- «Проверка на клиенте ускорит работу и снизит нагрузку на сервер». Да, ускоряет, но не заменяет серверные проверки — нельзя доверять клиенту.

FAQ

– Почему blacklist не считается достаточно хорошим?
Потому что список запрещенных символов или слов редко бывает исчерпывающим. Злоумышленники постоянно находят способы обхода. В белом списке разрешается только то, что явно безопасно, так что вероятность ошибки ниже.

– Чем отличается bcrypt от Argon2?
Argon2 — это более современный алгоритм, который обладает лучшей устойчивостью к атакам с использованием GPU и ASIC, а также оптимизируется под память, что делает его безопаснее на сегодняшний день. Bcrypt тоже хорош, широкораспространён и проверен временем, но Argon2 потихоньку становится стандартом.

– Можно ли полностью забыть про SQL-инъекции?
Нет, потому что даже в современных фреймворках можно случайно написать небезопасный запрос, если обойти привычные ORM или неправильно использовать параметры. Лучше всегда держать защиту на уровне подготовки запросов и проверять код.

– Как часто надо обновлять CMS и плагины?
Оптимально проверять обновления минимум раз в месяц и сразу же ставить критические патчи. Если в проекте много участников, можно и чаще, особенно если разработчики выпускают частые обновления из-за появления багов в безопасности.

– Двухфакторная аутентификация обязательна или можно обойтись?
Для серьезных проектов — лучше включать. Для совсем простых проектов, где данные не критичны, можно не ставить, но тогда нужно иметь другие слои защиты: сильные пароли, ограничение попыток входа, VPN и т.п.

Итоги
Безопасность веб-приложений — это постоянный процесс, и нельзя останавливаться на проверенных годами штуках, которые превратились уже в «устаревшие методы». Если не менять подходы и не обновлять инструментарий, можно очень быстро получить дырку, через которую злоумышленники зайдут без особого труда. Важно пересматривать стратегии, внедрять новые технологии и учиться использовать правильные методы фильтрации и защиты, которые соответствуют сегодняшним реалиям. Не жалейте времени на обновления и автоматизацию безопасности — в долгосрочной перспективе это сэкономит и нервы, и ресурсы.