Аудит информационной безопасности веб-ресурса

Резюме для руководства

Раздел написан без технических терминов и рассчитан на читателя, который принимает решение о бюджете и сроках, а не выполняет работы.

Цель работ

Независимая оценка защищённости веб-ресурса и связанной инфраструктуры от несанкционированного доступа, утечки данных пользователей, нарушения доступности сервиса и обхода бизнес-логики.

Общая оценка

Уровень защищённости оценивается как удовлетворительный. Уязвимостей, позволяющих немедленно получить контроль над сервером или выгрузить базу данных, не выявлено. При этом найдены недостатки в настройке аутентификации, заголовков безопасности и параметров сессионных cookie, которые по отдельности не критичны, но вместе заметно расширяют поверхность атаки.

Что сделать в первую очередь

1. Ограничить частоту запросов на вход и восстановление пароля. Одна настройка, закрывающая единственную находку высокого уровня.
2. Исправить параметры сессионных cookie и убрать из ответов сервера версии установленного ПО. Правки на полдня работы.
3. Внедрить политику Content-Security-Policy. Требует тестирования, поэтому вынесено в отдельный этап.

Границы работ и методология

Что проверялось

• Домены заказчика и их поддомены в согласованном перечне
• Публичные точки API
• Регистрация, вход, восстановление пароля, управление сессией
• Загрузка и выдача пользовательских файлов
• Конфигурация веб-сервера и заголовков ответов

Что не проверялось

• Сторонние сервисы: CDN и платёжный шлюз. Проверялась только корректность интеграции
• Нагрузочные атаки на отказ в обслуживании
• Социальная инженерия в отношении сотрудников заказчика
• Физическая безопасность и внутренняя сеть офиса

Граница зафиксирована до начала работ и не менялась. Всё, что в неё не входит, не проверялось, и отсутствие находок по этим направлениям не означает их защищённости.

Правила проведения

Работы велись по согласованным правилам (Rules of Engagement), приложение к договору: перечень разрешённых доменов и адресов, окно проведения, контактное лицо для экстренной остановки, запрет на изменение и удаление данных. Действия, способные нарушить работу сервиса, выполнялись только после письменного согласования.

Глубина проверки

Объём работ согласуется до начала и бывает двух уровней. Проверка без эксплуатации: уязвимость фиксируется по признакам, без доведения атаки до конца, безопасно для боевой среды. Контролируемая эксплуатация: найденная уязвимость доводится до подтверждённого результата, чтобы отличить теоретический риск от реального и показать, до каких данных злоумышленник доберётся на самом деле. Второй уровень выполняется только по отдельному письменному разрешению, в согласованное окно и с возможностью немедленной остановки.

В публичной версии отчёта применённые методы, инструменты и цепочки атак не перечисляются. В рабочем отчёте они приводятся полностью: заказчик должен понимать, что именно проверялось и как результат воспроизвести.

Стандарты

• OWASP Web Security Testing Guide, версия 4.2
• OWASP Top 10:2021
• NIST SP 800-115
• Оценка критичности по CVSS версии 3.1

Обращение с данными заказчика

Выгрузка пользовательских данных не производилась. Журналы и конфигурации, переданные для анализа, обрабатывались в закрытом контуре исполнителя. Там, где для разбора объёмов привлекались языковые модели, использовалась модель, развёрнутая локально и не имеющая доступа в интернет: содержимое журналов и конфигураций не передавалось во внешние сервисы. Выводы и формулировки проверены инженером вручную.

Детальные находки

Каждая находка описана по одной схеме: что именно не так, чем это грозит бизнесу, как это было подтверждено и что нужно сделать. Идентификатор используется в переписке и при повторной проверке.

Content-Security-Policy: default-src 'self'; frame-ancestors 'none'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Strict-Transport-Security: max-age=31536000; includeSubDomains
Permissions-Policy: camera=(), microphone=(), geolocation=()

Set-Cookie: session_id=...; Secure; HttpOnly; SameSite=Lax; Path=/

# nginx
server_tokens off;

# приложение — убрать заголовок X-Powered-By

В образце четыре находки из десяти, и каждая урезана. У находки в рабочем отчёте есть шаги воспроизведения, запросы и ответы целиком, снимки экрана, ссылки на затронутые участки кода и конфигурации и — там, где эксплуатация была разрешена, — подтверждённый сценарий с описанием того, до чего удалось добраться. Это всё, что нужно разработчику, чтобы исправить и проверить себя. Публиковать такой текст по чужой живой системе нельзя.

План устранения

Порядок составлен по соотношению «риск к трудозатратам»: первыми идут работы, которые снимают наибольший риск наименьшими усилиями.

По запросу находки выгружаются в трекер заказчика отдельными задачами с описанием, ссылками на затронутые файлы и критерием приёмки.

Повторная проверка и ограничения

Повторная проверка

После внесения правок проводится контрольная проверка по закрытым находкам. По её итогам выпускается приложение к отчёту, где у каждой находки проставляется статус: устранена, устранена частично или остаётся открытой. Срок, в течение которого повторная проверка входит в стоимость работ, фиксируется договором.

Ограничения

• Оценка отражает состояние системы на дату проведения работ. Любое изменение кода или конфигурации после этой даты может создать новые уязвимости.
• Отсутствие находки не доказывает отсутствие уязвимости. Аудит ограничен согласованными границами, временем работ и доступными методами.
• Абсолютная защищённость недостижима. Цель работ — снизить риск до приемлемого уровня и сделать его управляемым.

Справочные материалы

Как читать уровень критичности

Журналы и расследование

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

• Журналы доступа и ошибок веб-сервера
• Журналы аутентификации операционной системы и приложения
• Журналы изменения прав, создания и удаления учётных записей
• Журналы развёртывания: кто и когда менял код и конфигурацию
• Сетевые соединения сервера, хотя бы в агрегированном виде

При подозрении на взлом нельзя переустанавливать систему и удалять файлы. Это уничтожает следы, и восстановить картину происходившего становится невозможно. Правильный первый шаг — снять образ или хотя бы копию журналов, и только потом восстанавливать работу.

Термины

• Grey Box — проверка с частичным знанием системы: есть учётная запись и общее описание, но нет исходного кода.
• CVSS — международная шкала оценки критичности уязвимостей от 0 до 10 с открытой методикой расчёта.
• OWASP Top 10 — перечень десяти самых распространённых классов уязвимостей веб-приложений.
• Rules of Engagement — согласованные до начала работ правила: что, когда и какими методами разрешено проверять.
• Поверхность атаки — совокупность точек, через которые можно попытаться воздействовать на систему.