Почему вообще бизнесу должно быть дело до какого-то списка OWASP
Честно говоря, когда я слышу фразу «у нас всё по OWASP», меня это немного настораживает. Потому что OWASP Top 10 — это не стандарт безопасности, который можно «внедрить». Это срез того, что болит у всех чаще всего. Это как топ-10 болезней в поликлинике: если вы сделали прививку от гриппа, это не значит, что вы здоровы. Но игнорировать эпидемию гриппа, когда вокруг все чихают, — как минимум странно.
В контексте бизнеса безопасность веб-приложений — это управление рисками. Рисками финансовых потерь, репутационных издержек и прямых штрафов от регуляторов. Когда в вашем приложении находят SQL-инъекцию и утекают персональные данные, Роскомнадзор приходит с вопросами не к разработчику, а к директору. И штрафы по 152-ФЗ давно уже не копеечные.
OWASP Top 10 актуален для любых отраслей, где есть веб-интерфейсы: финансы, ритейл, логистика, госуслуги. Даже если вы делаете внутренний портал для сотрудников, утечка HR-данных или бухгалтерии может стать фатальной. Так что давайте разбираться с основными «головными болями» — инъекциями, доступом и шифрованием. Это три кита, на которых держится большая часть проблем.
Инъекции: когда доверие к пользователю выходит боком
Начну с того, что видел своими глазами. Работали мы как-то с одним крупным интегратором, который делал личный кабинет для клиентов. Сайт на популярной CMS, форма обратной связи, поиск по документам. Всё стандартно. Приходит заказчик и говорит: «У нас кто-то базу данных потрошит, техподдержка в логах видит странные SQL-запросы». Начинаем копать. Оказалось, в поле «поиск по номеру документа» можно было ввести не только цифры, но и, скажем, ‘ OR ‘1’=’1. И база данных послушно выдавала всё, что есть. Классика.
Что такое инъекции сегодня
Инъекции (Injection) — это не только старый-добрый SQLi, хотя он по-прежнему в топе. Сюда же входят инъекции в NoSQL (MongoDB, Elasticsearch), в команды операционной системы (Command Injection), в LDAP-запросы. По сути, это ситуация, когда злоумышленник может «скормить» приложению интерпретируемый код, и сервер его выполнит.
Векторы атак тут довольно стандартны: формы ввода, параметры URL, заголовки HTTP, эндпоинты API. Если разработчик слепо доверяет данным, пришедшим от клиента, рано или поздно это приведёт к беде.
Что любопытно, в современной микросервисной архитектуре инъекции могут возникнуть там, где их совсем не ждёшь. Например, при логировании. Если вы передаёте данные пользователя напрямую в систему сбора логов без экранирования, можно подменить запись или вообще выполнить код на сервере сбора логов (Log4j — ярчайший пример, хоть это и не классическая веб-инъекция, но суть та же).
Как с этим жить: защита от инъекций
Методы защиты, по сути, не меняются последние 15 лет, и это хорошо. Потому что они работают.
Параметризованные запросы и ORM. Это железобетонный стандарт. Никогда не склеивайте строки запроса с пользовательским вводом. Во всех современных языках и фреймворках (будь то PHP PDO, Java Hibernate, .NET Entity Framework) есть механизмы параметризации. Пользуйтесь ими всегда. Это должно быть на уровне рефлекса.
Валидация входных данных. Белый список всегда лучше чёрного. Если поле ожидает число — проверяйте, что это число. Если email — проверяйте по регулярке. Но тут важный нюанс: валидация на клиенте — это только для удобства пользователей. Вся серверная проверка должна дублироваться на бэкенде.
Принцип наименьших привилегий для учётки БД. Это уже из области администрирования. Если приложению нужно только читать данные из одной таблицы, не давайте ему права на запись или удаление во всей базе. Даже если инъекция случится, ущерб будет локализован.
По моему опыту, автоматические сканеры (DAST) отлично ищут классические SQLi. Но логические инъекции (например, обход 2FA через подмену параметра) они видят плохо. Тут нужен либо ручной аудит кода (SAST), либо, что лучше, и то и другое в пайплайне CI/CD.
Нарушения контроля доступа: дверь есть, а замка нет
Это, наверное, самая обидная категория уязвимостей. Потому что для её эксплуатации часто не нужно никаких хитрых техник. Просто подменить цифру в URL: /user/123 на /user/124. Или дёрнуть API-эндпоинт /admin/deleteUser, до которого обычный пользователь добраться не должен, но сервер почему-то не проверяет права.
Из практики проектов: недавно аутировали облачный сервис для малого бизнеса. Бухгалтерия, счета, акты. Посмотрели, как работает ролевая модель. Вроде есть админ, есть бухгалтер, есть просто пользователь. Но на одном из API-методов для получения списка контрагентов забыли повесить аннотацию @PreAuthorize. И любой авторизованный пользователь, подставив нужный ID организации в запрос, мог посмотреть контрагентов любой другой компании. Ничего взламывать не надо — просто подставить параметр побольше. И это в 2024 году, между прочим.
Почему это происходит
Часто проблема в том, что контроль доступа реализуют на клиенте. Мол, раз кнопку «Удалить» не видно, значит и права нет. Но API-то всё равно доступен. Или, что тоже часто бывает, проверка доступа есть, но только на чтение, а на запись забыли. В итоге пользователь может читать чужое (горизонтальное повышение привилегий), а иногда и писать/удалять (вертикальное).
Нарушения контроля доступа (Broken Access Control) — это очень широкий класс. Сюда входит и path traversal, когда через ../ можно выйти за пределы веб-папки и прочитать файлы системы, и уязвимости в JWT-токенах, когда подпись не проверяется, и CORS-мисконфигурации.
Технические меры, которые реально работают
Проверка прав на сервере для каждого запроса. Каждого. Это должно быть правило номер один. Не важно, что пользователь уже авторизован. Нужно каждый раз отвечать на вопрос: «Имеет ли этот конкретный пользователь право выполнить это конкретное действие с этим конкретным объектом?».
Использование готовых фреймворков для RBAC/ABAC. Не изобретайте велосипед. Spring Security, ASP.NET Core Identity, Django Guardian — они уже всё продумали. Главное — правильно настроить.
Отказ от «секретных» URL. Часто думают: «Давайте сделаем ссылку для доступа к документу длинной и случайной, типа /doc/ae5f8d3f, и никто не догадается». Это security through obscurity, и это не работает. Как только ссылка утечёт (а она утечёт), документ будет доступен всем. Пароль или явная проверка прав обязательны.
Что бесит больше всего — когда в коде видят комментарии вроде «// TODO: добавить проверку прав». И эта «тудушка» висит годами. Контроль доступа — это не то, что можно отложить на рефакторинг. Это база.
Криптографические неудачи: плохой замок на хорошей двери
Переходим к шифрованию. Название категории поменяли с «Sensitive Data Exposure» на «Cryptographic Failures» не просто так. Суть стала шире: речь не только о том, что данные утекли, но и о том, что криптография использована неправильно или не использована вообще, даже если данные не утекли прямо сейчас.
Представьте: сайт работает по HTTP, пароли хранит в MD5 с солью или без, а для шифрования трафика использует SSLv3. Формально данные вроде как защищены, но это как дверь в квартиру: поставили супер-замок, а ключ под ковриком оставили. Или дверь вообще нараспашку.
Типичные криптографические неудачи на российских просторах
Использование устаревших алгоритмов. MD5, SHA-1 для хэширования паролей — до сих пор встречается на аудитах. Ребята, это прошлый век. Даже если добавить соль, MD5 ломается на видеокартах за секунды. Для паролей сейчас стандарт — bcrypt, Argon2 или PBKDF2. Они специально медленные, чтобы усложнить перебор.
Отсутствие TLS или его неправильная настройка. Сайт на HTTP — это моветон в 2026 году. Весь трафик должен шифроваться. Но мало включить HTTPS, надо правильно настроить протоколы и шифры, отключить устаревшие TLS 1.0/1.1, включить HSTS, чтобы браузер даже не пытался ходить по HTTP.
Проблемы управления ключами. Жёстко зашитые ключи шифрования в коде — классика. Или хранение ключей в той же базе данных, что и зашифрованные данные. Это как ключ от сейфа хранить в том же сейфе, но снаружи.
Из практики SecureDefence: был инцидент в одной финтех-компании. У них всё было по красоте: HTTPS, сертификаты от нормального центра, пароли хэшируются. Но при этом все персональные данные в базе лежали в открытом виде. Злоумышленник нашёл SQL-инъекцию (да, опять она) и просто выгрузил всю таблицу с паспортными данными. Шифрование на диске не помогло — диски-то серверные, а БД отдала данные в чистом виде. Настоящее шифрование должно быть на уровне приложения или базы данных (TDE), но с отдельным ключом.
Стандарты и практики шифрования
Для передачи данных — только TLS 1.2 и выше, лучше 1.3. Для хранения паролей — адаптивные хэш-функции (bcrypt, Argon2). Для хранения чувствительных данных (платёжная информация, ПДн) — симметричное шифрование (AES-256) с корректным management-ом ключей. Желательно использовать Hardware Security Module (HSM) или облачные KMS-системы.
Важно помнить про российские реалии. Если вы обрабатываете ПДн, использование иностранных алгоритмов (тех же AES) разрешено, но ФСТЭК и ФСБ рекомендуют переход на ГОСТовые алгоритмы (ГОСТ 28147-89, ГОСТ Р 34.10-2012) для систем, где это критично. Особенно в госсекторе.
Что в итоге: как выстроить системную защиту на основе OWASP
Мы разобрали три верхние позиции из топа OWASP, но список на десятке не заканчивается. Там дальше идёт небезопасная конфигурация, уязвимые компоненты, недостатки логирования и мониторинга и прочее. Но подход к ним примерно такой же.
Если вы хотите, чтобы безопасность веб-приложений была на уровне, а не «латанием дыр» по факту инцидента, нужно делать системные вещи:
Сдвиг влево (Shift Left). Безопасность должна начинаться на этапе проектирования, а не на этапе, когда код уже в проде. Тренинги для разработчиков, анализ угроз, выбор безопасных архитектурных решений.
Автоматизация в CI/CD. Интегрируйте статические анализаторы кода (SAST) и динамические сканеры (DAST) в процесс разработки. Пусть джуны получают замечания от робота, а не от вас после код-ревью. Но доверять только автоматам нельзя — они дают много ложных срабатываний.
Регулярный аудит и пентeсты. Хотя бы раз в год или перед каждым крупным релизом. Причём пeнтест должен быть не для галочки, а с нормальным отчётом и анализом бизнес-рисков.
Мониторинг и реагирование. Мало написать безопасный код, надо ещё заметить, когда его пытаются сломать. WAF (Web Application Firewall), системы обнаружения вторжений (IDS/IPS), анализ логов и корреляция событий в SIEM — это уже задача для SOC, но и про это нельзя забывать.
Типичная ошибка большинства компаний — думать, что безопасность — это продукт, который можно купить. Купили сканер, купили WAF, и всё защищено. На самом деле безопасность — это процесс. Это культура разработки и эксплуатации. OWASP Top 10 даёт нам список того, на что чаще всего наступают грабли. Ваша задача — эти грабли убрать с дороги.
Практический совет от меня: не пытайтесь закрыть все десять пунктов сразу. Это невозможно. Оцените риски для вашего конкретного приложения. Если вы торгуете шапками онлайн — для вас страшнее всего недоступность сайта (DoS) и потеря данных клиентов. Если вы разрабатываете ПО для управления производством — на первом месте может быть целостность данных и контроль доступа к техпроцессам. Отталкивайтесь от бизнеса, а не от абстрактного списка.
Нужна помощь?
Оставьте заявку на бесплатную консультацию на сайте:
https://securedefence.ru/
Мы подготовим чек-лист по вашему проекту, набросаем дорожную карту внедрения защитных мер и, если потребуется, сделаем коммерческое предложение.
Для первых 5 заявок в этом месяце — расширенный аудит безопасности веб-приложения в подарок к основной консультации.
FAQ для руководителя: OWASP Top-10 и безопасность веб-приложений
1. Что такое OWASP Top-10 простыми словами? Это обязательный стандарт или просто рекомендация?
Если совсем просто — это «топ-10 болячек» веб-приложений, которые встречаются чаще всего. Представьте рейтинг самых популярных ошибок в строительстве домов. OWASP — это такой рейтинг для программистов и архитекторов ПО, составленный огромным сообществом экспертов . Обновляется он раз в несколько лет (последняя версия 2021-го, сейчас готовятся изменения), чтобы отражать актуальные угрозы .
Это не закон и не формальный стандарт типа ГОСТа или PCI DSS. Но это — de facto стандарт для любого, кто хочет строить безопасные системы. На него ссылаются и PCI SSC, и NIST, и ФСТЭК в своих методиках . Если вы проходите аудит или пентест, вас почти наверняка будут проверять именно по методологии OWASP. Так что игнорировать его нельзя, а вот использовать как чек-лист для старта — самое то.
2. Мой сайт написан на современном фреймворке, мы используем HTTPS. Мы ведь уже защищены? Зачем мне вникать в эти риски?
Хороший вопрос, и его часто задают. Современные фреймворки действительно закрывают много базовых проблем, например, те же SQL-инъекции — если вы правильно используете ORM. Но, по моему опыту, «из коробки» фреймворк не защищает от логических уязвимостей (например, когда пользователь может посмотреть чужие данные, просто подменив ID в запросе — это называется IDOR ), от ошибок в бизнес-логике или от неправильной конфигурации самого сервера и облачных сервисов .
Кроме того, безопасность — это не только код. Это ещё и процессы: как вы обновляете библиотеки, как храните ключи шифрования, как реагируете на инциденты. OWASP Top-10 как раз помогает посмотреть на проблему шире, чем просто «у нас стоит HTTPS».
3. Какие из этих уязвимостей самые опасные для бизнеса с точки зрения денег и репутации?
Опасны те, которые ведут к утечке данных или остановке сервиса.
На первом месте — нарушения контроля доступа (Broken Access Control). Это когда кто-то получает доступ к чужим документам, счетам или админке. Это прямая дорога к утечке персональных данных (ПДн) со всеми вытекающими штрафами по 152-ФЗ. По статистике, это самая частая проблема .
Второе — это криптографические ошибки (Cryptographic Failures). Сюда относится не только отсутствие HTTPS, но и, например, хранение паролей в слабом хэше (вроде MD5) или передача данных в открытом виде внутри своей сети. Если злоумышленник перехватит такой трафик — последствия могут быть фатальны .
И третье — инъекции (Injection). SQL-инъекции по-прежнему позволяют злоумышленникам не только украсть базу данных целиком, но иногда и выполнить свои команды на сервере .
Что любопытно, чисто технические атаки, типа DoS, в Top-10 не входят. Список сфокусирован именно на уязвимостях, ведущих к компрометации данных или систем.
4. Если мы решим заняться безопасностью всерьёз, с чего начать? С покупки WAF или с найма пентестеров?
Начинать нужно с аудита и обучения, а не с покупки «железок». WAF (Web Application Firewall) — это хорошо, он отловит многие типовые атаки, но он не исправит кривой код и не закроет логические дыры .
Пошагово я бы рекомендовал так:
- Быстрый аудит (ASVS Level 1): Провести автоматическое сканирование (SAST/DAST) вашего основного приложения, чтобы понять, где у вас «торчат провода» .
- Обучение команды: Разработчики должны понимать, что такое IDOR, как правильно работать с JWT-токенами и почему нельзя доверять данным от клиента.
- Внедрение безопасных практик в процесс разработки: Сдвиг влево (Shift Left) — когда безопасность проверяется на этапе написания кода, а не после выкатки в прод .
- И только потом — средства защиты: WAF, системы защиты контейнеров, сканеры уязвимостей в CI/CD.
5. Сколько это стоит? У нас ограниченный бюджет на ИБ.
Бюджет может быть любым, и начать можно даже с малого. Самое дорогое — исправлять критическую уязвимость в продакшене, когда сайт уже лежит или данные утекли.
На первое время я бы заложил бюджет на:
- Регулярное автоматическое сканирование кода (есть много недорогих или даже бесплатных Open Source инструментов, главное — уметь интерпретировать результаты).
- Периодический ручной пентест (раз в год или перед крупным релизом). Хороший специалист найдет то, что пропустит автомат.
- Обновление стека технологий. Самая дешевая защита — не использовать устаревшее ПО, по которому давно есть публичные эксплоиты .
6. Как OWASP связан с российскими требованиями по защите данных (152-ФЗ, приказы ФСТЭК)?
Напрямую — никак. 152-ФЗ и приказы ФСТЭК требуют выполнения определённых мер защиты, но не говорят, что надо следовать именно OWASP. Однако методологически OWASP — это лучший способ эти меры реализовать технически.
Например, ФСТЭК требует защищать приложения от атак типа «недекларированных возможностей». Один из способов это сделать — внедрить безопасную разработку (SDL), которая включает в себя анализ угроз и тестирование на проникновение по методикам OWASP. То есть OWASP — это инструментарий для выполнения формальных требований регуляторов . Встраивание OWASP ASVS в процессы разработки здорово помогает при аттестации систем.
7. Мы используем много готового ПО и open-source библиотек. Насколько это рискованно?
Риск колоссальный, и OWASP выделил это в отдельную категорию — «Уязвимые и устаревшие компоненты» . Пример с SolarWinds, когда вредонос встроили в обновление легитимного ПО, стал классикой . По некоторым данным, значительная доля взломов сегодня начинается с атак на цепочки поставок (supply chain) — через уязвимости в npm-пакетах, библиотеках Python, Docker-образах .
Что с этим делать? Во-первых, нужен реестр всего используемого ПО (SBOM — Software Bill of Materials) . Во-вторых, автоматические системы (типа Dependabot), которые следят за появлением уязвимостей в используемых версиях и предлагают обновления . В-третьих, принцип «доверяй, но проверяй»: не тащите в проект непроверенные библиотеки из сомнительных источников. Если библиотека не обновлялась пять лет, лучше поискать альтернативу.
8. ИИ помогает нам писать код. Это создаёт новые риски?
Да, и это одна из причин, почему категория «Небезопасный дизайн» и «Ошибки целостности ПО и данных» становятся всё актуальнее . ИИ-ассистенты (вроде Copilot или ChatGPT) могут генерировать код, который содержит уязвимости, или рекомендовать использовать несуществующие библиотеки. Злоумышленники уже создают такие библиотеки с вредоносным кодом, надеясь, что разработчики их скачают, следуя совету ИИ .
Поэтому подход должен быть таким: код, написанный ИИ, должен проходить те же проверки, что и код человека, — статический анализ и код-ревью. Никакого «слепого доверия».
══════
Оставьте заявку на бесплатную консультацию: [Перейти на сайт]