«В 2024 году ФСТЭК оштрафовал 47 компаний на суммы до 5 млн рублей за уязвимости в веб-приложениях. В 80% случаев проблемы были связаны с банальными ошибками в настройке WAF и отсутствием контроля за SQL-инъекциями. Как проверить свою систему до визита регулятора — разбираем на реальных кейсах.»
Введение
Для компаний из финансового сектора, телекома и госструктур требования ФСТЭК — не рекомендация, а обязательный стандарт. Один неисправленный баг в системе онлайн-банкинга или госуслуг может привести не только к штрафу, но и к утечке персональных данных миллионов пользователей. В этой статье — конкретные шаги по аудиту веб-приложений с примерами кода и чек-листами.
1. На какие уязвимости обращает внимание ФСТЭК при проверках в 2025 году
По данным анализа результатов контроля и актуальных угроз, особое внимание при оценке защищенности уделяется следующим критическим направлениям:
- SQL-инъекции (40% нарушений). (Более подробно об этой уязвимости читайте в SQL-инъекции: как работают и как защититься).
- Небезопасная десериализация данных (например, в API на Java/Python). Важно отметить, что это сложная категория уязвимостей, и реальная защита здесь требует глубокого понимания форматов данных, используемых библиотек и контекста их обработки, а не только поверхностных исправлений.
- Ошибки в настройке заголовков безопасности (CSP, HSTS), а также других важных заголовков, таких как X-Content-Type-Options, X-Frame-Options, Referrer-Policy и Permissions-Policy, которые в комплексе повышают защиту.
Пример уязвимого кода на Python (Flask):
from flask import Flask, request
import sqlite3
app = Flask(__name__)
@app.route('/search')
def search():
query = request.args.get('query')
conn = sqlite3.connect('database.db')
cursor = conn.cursor()
cursor.execute(f"SELECT * FROM products WHERE name = '{query}'") # Уязвимость!
return cursor.fetchall()
Проблема: Прямая подстановка пользовательского ввода в SQL-запрос открывает путь для инъекций. (Примечание: использование SQLite здесь демонстрационное; в высоконагруженных системах под ФСТЭК обычно применяются другие СУБД, но паттерн уязвимости универсален).
Решение:
cursor.execute("SELECT * FROM products WHERE name = ?", (query,)) # Параметризованный запрос
2. Кейс: как банк избежал штрафа в 4 млн рублей
Ситуация:
Во время тестирования на проникновение команда обнаружила, что через форму обратной связи на сайте можно загрузить произвольные файлы (уязвимость Unrestricted File Upload). Это нарушало требования одного из приказов ФСТЭК (в данном кейсе, применимого к инфраструктуре банка как субъекта КИИ – п. 5.1.3 приказа ФСТЭК № 239 (текст приказа можно найти на Официальный сайте ФСТЭК или сайтах справочно-правовых систем)).
Что сделали:
- Внедрили на сервере проверку MIME-типов и расширений файлов, а также дополнительно валидацию содержимого загружаемых файлов (например, проверку “magic numbers”, интеграцию с антивирусным ПО). Были внедрены политики хранения загружаемых файлов вне корневого каталога веб-сервера и использования генерируемых сервером, непредсказуемых имен для хранимых файлов.
- Настроили WAF (ModSecurity) с правилами, блокирующими известные опасные типы файлов (о принципах работы и настройки WAF читайте в Как работает и зачем нужен Web Application Firewall):
SecRule FILES_TMPNAMES "@rx \.(php|exe|sh)$" "deny,status:403,id:1001"При этом важно понимать, что первоначальной настройки WAF недостаточно; требуется его постоянный тюнинг, обновление правил и мониторинг ложных срабатываний для поддержания эффективности и минимизации блокировки легитимного трафика.
- Добавили логирование всех операций загрузки файлов для последующего аудита. Была настроена передача этих логов, а также других ключевых событий безопасности, в централизованную систему мониторинга (SIEM) для оперативного анализа и корреляции.
Итог: Регулятор принял отчёт без замечаний.
3. Чек-лист для подготовки к проверке
- Сканирование зависимостей и статический анализ кода (SAST):
# Использование OWASP Dependency-Check (см. OWASP Dependency-Check Project) dependency-check.sh --project "MyApp" --scan ./src # Дополнительно интегрируйте инструменты SAST для поиска уязвимостей в исходном коде. - Проверка заголовков безопасности:
curl -I https://your-site.com | grep -i "Strict-Transport-Security" # Проверьте также наличие CSP, X-Content-Type-Options, X-Frame-Options и др. - Тест на инъекции и динамический анализ (DAST):Инструменты: SQLmap, Burp Suite (для ручного и автоматизированного тестирования), OWASP ZAP и другие DAST-сканеры.
Заключение
- Приоритеты: Начните с OWASP Top 10 (актуальную версию см. на Официальный сайт OWASP Foundation и релевантных требований ФСТЭК (например, Приказ №239 для КИИ, №17 для ГИС, №21 для ПДн), но помните, что это отправные точки. Реальная безопасность требует комплексного подхода, основанного на моделировании угроз, оценке рисков и непрерывном процессе управления уязвимостями, а не только на формальном следовании чек-листам.
- Документируйте всё: Отчётность — 50% успеха при проверке.
- Автоматизируйте: Настройте регулярное сканирование и интеграцию инструментов безопасности (SAST, DAST, IAST, сканеры зависимостей) в ваш CI/CD пайплайн (например, через GitLab CI/CD) для раннего выявления уязвимостей.
- Не забывайте о человеческом факторе: Регулярно обучайте разработчиков, тестировщиков и администраторов практикам безопасной разработки и эксплуатации систем.
Часто задаваемые вопросы
Q: Как часто нужно проводить тестирование?
A: Рекомендуется проводить внутренний аудит и тестирование на проникновение не реже раза в квартал для поддержания высокого уровня защищенности, особенно для критичных систем. Официальный контроль или аттестационные испытания проводятся в соответствии со сроками, установленными регулятором для вашего класса систем и специфики деятельности (например, ежегодно для некоторых объектов КИИ, или раз в два/три года для других систем). После любых значительных изменений в коде или инфраструктуре также необходим внеплановый аудит.
Q: Какие инструменты дают максимально точные результаты?
A: Комбинация Burp Suite Pro (для глубокого анализа веб-приложений) + сканеры инфраструктурных уязвимостей (например, Nessus или аналоги) + обязательное ручное тестирование экспертами. Автоматизированные инструменты могут пропустить значительную часть уязвимостей, особенно связанных со сложной бизнес-логикой или специфичными конфигурациями.
Загрузка...
