Аудит безопасности сайта: OWASP, pentest, 152-ФЗ и план исправлений

1. Когда аудит безопасности обязателен

Аудит нужен перед запуском нового сайта или портала, после крупного релиза, перед подключением платежей, при появлении личного кабинета, после миграции с конструктора или CMS, перед рекламной кампанией с высокой нагрузкой, после инцидента и при требованиях службы ИБ или контрагентов. Особенно важно проверять проекты, где есть персональные данные, файлы пользователей, роли, документы, интеграции с 1С/CRM и административные функции.

Типичная проблема бизнеса — считать, что если сайт небольшой, атаковать его никому не интересно. На практике автоматические сканеры ищут уязвимости без учета размера компании: открытые .env, старые версии CMS, слабые пароли админки, XSS в формах, отсутствие rate limit, публичные backup-файлы, misconfiguration nginx или Docker. Для злоумышленника даже небольшой сайт может быть точкой входа в почту, CRM или клиентскую базу.

• Перед production-релизом: чтобы не переносить известные риски в боевую среду.
• Перед платежами: чтобы проверить PCI DSS context, вебхуки, хранение токенов и возвраты.
• Перед обработкой ПДн: чтобы проверить 152-ФЗ, согласия, цели обработки и доступы.
• После инцидента: чтобы найти root cause и закрыть не только симптом.

Лучшее время для аудита — до релиза. Второе лучшее — сейчас, пока проблема еще не стала публичным инцидентом.

2. OWASP Top 10 2021: практический чек-лист

OWASP Top 10 2021 — это не сертификат и не магическая гарантия, а удобная карта самых распространенных классов рисков веб-приложений. В аудите мы используем OWASP как основу, но проверяем не абстрактные пункты, а реальные сценарии вашего сайта: формы, авторизацию, API, админку, загрузку файлов, интеграции, платежи и доступ к данным.

Например, Broken Access Control проявляется не только как "пользователь открыл чужой кабинет". Это может быть IDOR в API документов, возможность сменить статус заказа без роли менеджера, доступ к черновикам страниц, просмотр чужих счетов по predictable URL или массовое изменение объектов через незащищенный endpoint. Чем больше ролей и бизнес-логики, тем важнее ручная проверка авторизации.

OWASP полезен как карта рисков, но качество аудита определяется тем, насколько проверка связана с реальными данными, ролями и процессами компании.

3. DAST, SAST и SCA: что дают автоматические проверки

Автоматизация ускоряет аудит, но не заменяет эксперта. DAST проверяет работающее приложение снаружи: сканирует страницы, формы, параметры, заголовки, cookies, CORS, TLS, открытые директории и типовые инъекции. SAST анализирует исходный код: небезопасные функции, ошибки валидации, потенциальные injection, неправильную работу с секретами. SCA проверяет зависимости и версии пакетов на известные CVE.

Главное ограничение автоматических инструментов — контекст. Сканер может найти XSS-подозрение, но не понять, что поле доступно только админу и потом попадает в письмо клиенту. Или наоборот: сканер ничего не найдет, потому что уязвимость связана с логикой скидок, повторной оплатой, сменой владельца заказа или обходом согласования. Поэтому результаты DAST/SAST/SCA нужно триажить вручную.

• DAST хорош для внешней поверхности: headers, cookies, TLS, forms, exposed paths.
• SAST полезен для code review security patterns и поиска опасных участков до релиза.
• SCA обязателен для dependency hygiene и быстрого реагирования на CVE.
• Manual testing нужен для ролей, бизнес-логики, цепочек оплаты и IDOR.

4. Методика pentest: как проходит ручная проверка

Pentest начинается с scope. Мы фиксируем домены, окружения, роли, тестовые аккаунты, допустимые техники, окна нагрузки, контакты на случай инцидента и ограничения. Для production-проверки важна осторожность: не проводить destructive tests, не удалять данные, не запускать нагрузочные атаки без согласования, не трогать реальные платежи. Для staging можно проверять шире, включая сложные сценарии изменения данных.

Дальше идет reconnaissance: карта приложения, технологии, публичные endpoints, robots/sitemap, admin paths, API, заголовки, cookies, CORS, CSP, параметры, формы, upload, authentication flows. Затем проверяются классы атак: injection, XSS, CSRF, SSRF, IDOR, auth bypass, mass assignment, business logic abuse, file upload, rate limit, session management, secrets exposure и misconfiguration.

Pentest без бизнес-контекста проверяет только поверхность. Настоящий риск часто находится в правилах: кто что может сделать, когда и с какими последствиями.

5. 152-ФЗ и персональные данные

Для российского бизнеса 152-ФЗ — не абстрактный юридический фон. Если сайт собирает имя, телефон, email, адрес, реквизиты, документы, заявки, файлы или данные личного кабинета, нужно понимать цели обработки, состав данных, согласия, политику конфиденциальности, локализацию, доступы, сроки хранения и порядок удаления. Технический аудит не заменяет юридическое заключение, но помогает выявить инженерные риски, которые мешают соответствию.

Мы проверяем, где хранятся персональные данные, передаются ли они во внешние системы, есть ли шифрование на уровне транспорта, кто имеет доступ к админке, логируются ли чувствительные поля, можно ли выгрузить базу без контроля, как настроены backup, есть ли удаление по запросу, не уходят ли ПДн в аналитические системы, error trackers или публичные логи. Частая проблема — токены и персональные данные случайно попадают в frontend, console logs или URL-параметры.

• Согласия должны соответствовать реальным формам и целям обработки.
• Доступ к ПДн должен быть ролевым и минимально необходимым.
• Логи не должны хранить пароли, токены, полные номера карт, лишние паспортные данные и секреты.
• Интеграции с CRM, рассылками и аналитикой нужно учитывать как передачу данных третьим системам.

6. PCI DSS context: что важно при платежах

Большинство сайтов не должны хранить данные банковских карт. Правильная архитектура отправляет пользователя на платежную форму провайдера или использует безопасный tokenized flow, где чувствительные карточные данные не проходят через сервер сайта. Это снижает PCI DSS scope, но не отменяет ответственность за безопасность платежного сценария: создание платежа, сумма, валюта, описание, metadata, webhook, возвраты и доступ к платежным статусам.

При аудите платежей мы проверяем, можно ли подменить сумму, order_id, return_url или metadata; проверяется ли подпись вебхука; что произойдет при повторной доставке payment.succeeded; можно ли скачать чужой чек; как обрабатывается partial refund; есть ли защита от повторного нажатия; совпадает ли состояние заказа с состоянием платежа. Для YooKassa и Тинькофф важны корректные секреты, изоляция sandbox/production и журнал финансовых событий.

• Не храните PAN/CVV и не логируйте карточные данные.
• Проверяйте платежные вебхуки независимо от frontend redirect.
• Используйте идемпотентность для создания платежей, выдачи доступа и возвратов.
• Разделяйте права: менеджер поддержки не должен иметь лишний доступ к финансовым операциям.

Даже если PCI DSS scope минимален, платежный сценарий остается критичным: ошибка в логике может стоить денег так же быстро, как техническая уязвимость.

7. CVSS и приоритизация: что чинить первым

После аудита почти всегда появляется список находок разной важности. Если чинить их в порядке "что проще", можно оставить критичный риск открытым. Поэтому мы используем CVSS как базовый язык оценки severity, но дополняем его бизнес-контекстом: какие данные затронуты, нужна ли авторизация, насколько легко повторить атаку, есть ли публичный exploit, какой финансовый или юридический ущерб возможен, есть ли компенсирующие меры.

Например, устаревшая библиотека с high CVE может быть недостижима в вашем runtime, а IDOR со скачиванием чужих договоров может иметь меньше "технических баллов", но быть критичным для бизнеса. Поэтому отчет должен объяснять не только severity, но и impact, likelihood, evidence, affected assets, reproduction steps and recommended remediation.

• Critical: удаленное выполнение кода, массовая утечка, обход auth, компрометация платежей.
• High: доступ к чужим данным, stored XSS в админке, серьезная misconfiguration, exploitable CVE.
• Medium: ограниченная XSS, слабые headers, partial information disclosure, rate limit gaps.
• Low: hardening, best practices, informational findings без прямого exploit.

Приоритизация должна отвечать на вопрос руководителя: какой риск мы принимаем, если не исправим это в ближайшие дни?

8. Отчет: что получает заказчик

Хороший отчет по безопасности должен быть полезен и руководству, и разработчикам. Руководству нужен executive summary: общий уровень риска, критичные проблемы, влияние на бизнес, соответствие требованиям, бюджет и сроки устранения. Разработчикам нужны технические детали: endpoint, роль, шаги воспроизведения, payload, скриншоты, логи, причина, рекомендация, ссылки на стандарты и критерий retest.

Мы не ограничиваемся списком "найдено X проблем". В отчет включается remediation roadmap: какие фиксы сделать за 24-72 часа, что вынести в ближайший релиз, что спланировать как архитектурное изменение, какие компенсирующие меры включить временно. Для сложных проектов добавляется risk register, матрица CVSS, карта affected components и план повторной проверки.

• Executive summary для собственника, директора или CISO.
• Технические карточки уязвимостей с PoC и шагами воспроизведения.
• CVSS/impact/likelihood и приоритет исправления.
• Roadmap устранения: срочные, плановые и архитектурные задачи.
• Retest-план после исправлений.

9. Remediation roadmap: как исправлять без хаоса

После аудита важно не впасть в две крайности: игнорировать отчет или пытаться исправить все сразу без контроля. Правильный подход — triage meeting с бизнесом, разработкой, DevOps и ответственным за безопасность. На встрече подтверждаются риски, назначаются владельцы, согласуются сроки, выбираются временные меры и определяется порядок релизов.

Срочные исправления обычно включают закрытие публичного доступа, ротацию секретов, отключение уязвимой функции, включение WAF/rate limit, патч зависимости, запрет опасного endpoint, hotfix авторизации. Плановые исправления — рефакторинг ролей, улучшение валидации, CSP, CSRF-защита, hardening Docker/nginx, обновление CI/CD. Архитектурные изменения — пересмотр модели доступа, сегментация данных, изменение платежного flow или вынос интеграции в отдельный backend.

Цель remediation — не "закрыть пункты в таблице", а реально уменьшить вероятность и ущерб атаки без поломки бизнес-сценариев.

10. Что проверить в инфраструктуре и DevOps

Безопасность сайта — это не только код. Инфраструктура часто содержит не меньше рисков: открытые порты, публичные панели, слабые SSH-ключи, отсутствие backup restore tests, секреты в переменных окружения без ротации, Docker socket, устаревшие образы, неправильные права на файлы, отсутствие network segmentation, небезопасные CI/CD tokens, wildcard-доступы к облаку, отсутствие audit logs.

В DevOps-аудите мы смотрим production/staging separation, секреты, deployment pipeline, доступы разработчиков, журналы действий, rollback, backup, TLS, DNS, security headers, nginx конфигурацию, rate limiting, file upload storage, object storage permissions и мониторинг. Для небольшого сайта это может казаться избыточным, но именно такие "настройки вокруг" часто открывают путь к компрометации.

• Production-секреты не должны использоваться на staging и в локальной разработке.
• Доступы должны быть персональными, с MFA и понятным offboarding.
• Backup проверяется восстановлением, а не наличием файла.
• Security headers и TLS должны соответствовать современным baseline-настройкам.

11. Как Enginx.ru проводит аудит и сколько это стоит

Аудит Enginx.ru начинается с короткого presale-scope: тип проекта, стек, домены, наличие личного кабинета, платежей, API, CRM/1С, персональных данных, окружений и доступа к коду. После этого мы предлагаем формат: экспресс-аудит внешней поверхности, полный аудит веб-приложения, pentest личного кабинета/API или комплексный аудит с инфраструктурой и retest.

Базовая стоимость аудита безопасности сайта — от 180 000 ₽. Итоговая оценка зависит от количества ролей, API, интеграций, платежных сценариев, окружений, необходимости SAST/code review, глубины DevOps-проверки и retest. По итогам вы получаете executive summary, технический отчет, CVSS-приоритизацию, remediation roadmap и консультацию по внедрению исправлений. Подробнее об услуге: /services/security-audit.

• 5+ рабочих дней для базового корпоративного сайта.
• Отдельный scope для порталов, ecommerce, API и платежей.
• Retest после исправлений можно включить сразу в план работ.
• Отчет пишется так, чтобы по нему могли работать и руководители, и разработчики.

Безопасность — это не разовая покупка спокойствия. Аудит дает точку контроля, а устойчивость появляется, когда исправления, мониторинг и security updates становятся регулярным процессом.