OWASP Top 10 — перечень десяти категорий уязвимостей веб-приложений, который составляет открытое сообщество OWASP. Это не стандарт и не сертификат, а общий язык: заказчик, разработчик и аудитор называют одну и ту же ошибку одним словом. Для вас список полезен тем, что превращает «проверьте безопасность» в десять понятных вопросов.
Список не гарантирует, что приложение безопасно, и не заменяет аудит: его отсутствие в отчёте означает лишь, что типовые ошибки не нашли. Как проходит такая проверка у нас, описано на странице «Аудит безопасности веб-приложения», здесь только смысл списка и то, что из него следует для заказчика.
Что такое OWASP Top 10 и чем он не является
OWASP — некоммерческое сообщество, которое открыто публикует материалы по безопасности программ. Top 10 — его самый известный документ: список категорий уязвимостей, который периодически пересматривается по данным сообщества. Чем он является и чем нет, удобно разделить сразу:
| Это | Это не |
|---|---|
| Список классов ошибок, на которые стоит смотреть в первую очередь | Полный перечень всех уязвимостей |
| Общий язык для заказчика, разработчика и аудитора | Закон или стандарт, который обязан соблюдать любой сайт |
| Основа для чек-листа проверки и для требований в техническом задании | Сертификат: «соответствует OWASP» не существует как документ |
| Отправная точка: что искать и как называть найденное | Проверка бизнес-логики вашего приложения |
Названия и порядок категорий меняются от редакции к редакции. Ниже названия даны по редакции 2021 года, смысл категорий от выпуска к выпуску сохраняется. Когда вы заказываете аудит, укажите, по какой редакции его проводят, иначе отчёты за разные годы сравнивать нельзя.
Десять категорий простыми словами
Для каждой категории ниже: что она значит, как выглядит в жизни и какой вопрос подрядчику это вскрывает.
| Категория | Что это значит | Как выглядит в жизни | Вопрос подрядчику |
|---|---|---|---|
| Нарушение контроля доступа | Пользователь может сделать то, что ему не разрешено | Клиент меняет номер заказа в адресе и открывает чужой заказ | Где в коде проверяются права и как это тестируется из-под каждой роли |
| Сбои криптографии | Данные не зашифрованы или зашифрованы слабо | Пароли хранятся в открытом виде, вход идёт по незащищённому соединению | Как хранятся пароли и ключи и какие данные шифруются при передаче и хранении |
| Инъекции | Приложение принимает ввод пользователя за команду | В поле поиска набрана строка, которая выполняется как запрос к базе | Как защищены запросы к базе и все места, куда попадает ввод пользователя |
| Небезопасное проектирование | Ошибка заложена в устройство, а не в строку кода | Восстановление пароля по вопросу «девичья фамилия матери»; нет лимита попыток | Была ли оценка угроз на этапе проектирования и кто её проводил |
| Ошибки конфигурации | Система настроена небезопасно | Оставлены пароли по умолчанию, открыта панель управления, ошибка показывает внутренности сервера | Кто и как проверяет настройки перед каждым выпуском |
| Устаревшие компоненты | В приложении библиотеки с известными дырами | Библиотека пятилетней давности, для которой давно опубликована уязвимость | Как узнаёте об уязвимостях в зависимостях и как быстро обновляете |
| Ошибки входа и аутентификации | Слабая проверка того, кто входит | Простые пароли разрешены, неудачные попытки не ограничены, сессия не заканчивается | Какая политика паролей, есть ли второй фактор и срок сессии |
| Нарушение целостности ПО и данных | Код или обновления можно подменить | Приложение берёт библиотеку из непроверенного источника или обновление без подписи | Откуда берутся зависимости и кто может выкладывать новую версию |
| Недостатки журналирования | Нападение не видно | Подбор паролей идёт неделю, и никто этого не заметил | Что попадает в журнал, кто его читает и сколько хранится |
| Подделка запросов со стороны сервера | Приложение обращается туда, куда ему подсказал пользователь | Функция загрузки по ссылке отдаёт внутренние адреса вашей сети | Какие адреса приложение может запрашивать и где это ограничено |
С каких категорий начинать заказчику
Все десять важны, но если времени и денег мало, начинайте с трёх: доступ, вход и настройки. Причины простые: ошибки в них легко допустить, их проще всего проверить руками, а цена ошибки высока — от показа чужих данных до полного захвата системы.
- Доступ. Права проверяются на сервере, а не скрытыми кнопками в интерфейсе. Если приложение многопользовательское, добавьте проверку «клиент А не видит данные клиента Б». Как это делается в SaaS, описано в статье про мультиарендность.
- Вход. Ограничение попыток, срок сессии, восстановление доступа и второй фактор для ролей с доступом к деньгам и персональным данным. Выбор способа разобран в статье «SSO и MFA: что выбрать».
- Настройки. Пароли по умолчанию, открытые панели управления, лишние службы наружу и подробные сообщения об ошибках. Это самый дешёвый класс ошибок для исправления.
Остальные категории (инъекции, зависимости, журналы) закрываются процессом разработки: проверки в конвейере, обновление библиотек по расписанию, журнал, который читают. Это работа команды, а не разовая проверка.
Пять проверок, которые заказчик сделает сам
Проверки делаются на тестовой копии или на системе, за которую вы отвечаете. На чужих системах и на боевой системе без согласования их не выполняют. Они не заменяют аудит, но быстро показывают, насколько серьёзно разработчики относились к безопасности.
- Подмена идентификатора. Войдите под обычным пользователем, откройте свой заказ или документ и измените номер в адресе. Если открылся чужой, это нарушение контроля доступа.
- Роль против роли. Войдите под ролью с минимальными правами и пройдите по адресам разделов администратора, которые вы знаете. Страница не должна открываться, даже если ссылки на неё нет в меню.
- Подбор и повтор. Введите неверный пароль десять раз подряд. Если вход не замедляется и не блокируется, ограничения нет.
- Вид ошибки. Вызовите ошибку, например, неверным адресом или неверным значением в форме. Страница не должна показывать пути на сервере, версии программ и тексты запросов.
- Внешняя поверхность. Спросите у администратора, какие порты и панели видны из интернета. Панель базы, панель управления и тестовые стенды наружу выставлять не нужно.
Результат каждой проверки записывайте: что делали, что увидели, на какой версии. Такая запись становится частью задания аудитору, а не спором «у нас всё хорошо».
Что находит автоматика, а что только человек
Автоматические сканеры дёшевы и нужны, но они видят только то, что можно распознать по шаблону. Остальное требует человека, который понимает ваше приложение.
| Класс проблемы | Автоматический сканер | Человек с доступом к коду и стенду |
|---|---|---|
| Устаревшие компоненты | Находит хорошо по списку зависимостей | Оценивает, достижима ли дыра в вашем приложении, и приоритет обновления |
| Ошибки конфигурации | Находит типовые: заголовки, открытые панели, пароли по умолчанию | Находит ошибки, специфичные для вашей среды и порядка выкладки |
| Инъекции | Находит типовые случаи на тестовом стенде | Читает код, находит места, куда ввод попадает нестандартным путём |
| Контроль доступа | Почти не находит: не знает, кто что должен видеть | Сравнивает права с матрицей ролей и пробует чужие данные из-под каждой роли |
| Бизнес-логика | Не находит | Проверяет сценарии: оплата, возврат, скидка, повтор заказа |
| Небезопасное проектирование | Не находит | Разбирает схему данных и потоки, оценивает угрозы |
Главный вывод: самая дорогая категория, контроль доступа, хуже всего ловится автоматикой. Если вам предлагают «проверку безопасности» только сканером, считайте это первой ступенью, а не аудитом.
Как читать отчёт об аудите
Хороший отчёт можно отдать разработчику и получить исправление, не задавая вопросов. Плохой выглядит солидно, но к действию не ведёт.
| Признак плохого отчёта | Что за ним стоит | Что потребовать |
|---|---|---|
| Только список страниц сканера без разбора | Не отделены ложные срабатывания от настоящих проблем | Для каждого замечания объяснение, почему это проблема именно у вас |
| Нет шагов воспроизведения | Разработчик не может проверить исправление | Последовательность действий, которая приводит к ошибке |
| Все замечания «критические» | Нет приоритета, исправлять придётся всё сразу | Оценка серьёзности и порядок исправления с учётом цены и риска |
| Нет указания, что проверено и что нет | Отсутствие замечаний выглядит как отсутствие проблем | Область, версия, срок и ограничения проверки |
| Нет рекомендаций | Дальше вы остаётесь с проблемой одни | Конкретный способ исправления для каждого замечания |
| Нет повторной проверки | Исправление не подтверждено | Предложение перепроверить исправленное и отметить закрытые замечания |
Принимайте отчёт по списку: область проверки, версия приложения, способ проверки, замечания с серьёзностью, шаги воспроизведения, способы исправления, список того, что не проверялось. Если чего-то нет, это повод вернуть отчёт.
Как вписать требования в задание и приёмку
Безопасность дешевле требовать до разработки, чем исправлять после. В задание достаточно нескольких строк, которые можно проверить:
- Права проверяются на сервере и описаны матрицей «роль, раздел, действие»; приёмка включает попытку открыть чужие данные из-под каждой роли.
- Пароли хранятся только в виде хешей, вход ограничивает число попыток, срок сессии указан в документации.
- Зависимости перечислены, и есть порядок их обновления по расписанию.
- Настройки боевой среды отделены от разработки: пароли по умолчанию отсутствуют, служебные панели закрыты от интернета.
- Журнал входов, смены прав и административных действий включён и читается.
- Перед запуском проводится проверка по выбранной редакции списка, и отчёт передаётся заказчику.
Общие правила составления задания собраны в статье «Как составить техническое задание на разработку». Если вы принимаете систему от прежнего подрядчика, до аудита безопасности полезен аудит кода и архитектуры.
Чего список не покрывает
OWASP Top 10 описывает типовые ошибки веб-приложений. За его пределами остаётся многое, о чём заказчик должен помнить:
- Логика вашей предметной области. Скидка, которая применяется дважды, возврат без заказа и оплата в обход шлюза в список не входят, но стоят денег.
- Люди и процессы. Фишинг, общие пароли и доступ уволенных сотрудников решаются регламентами и единым входом, а не проверкой кода.
- Инфраструктура. Защита сети, рабочих мест и устойчивость к атакам на доступность относятся к другим услугам и другим специалистам.
- Приложения с языковыми моделями. У них свои классы рисков, которые описывает отдельный перечень OWASP для приложений на больших языковых моделях: внедрение инструкций, утечки через ответы и избыточные права агента. Подробнее в статьях «Что такое prompt injection» и «Чек-лист безопасности LLM перед запуском», а услуга описана на странице аудита безопасности ИИ.
- Требования регуляторов. Соответствие вашей отрасли проверяют отдельно, и список OWASP его не подтверждает.
Что делаем мы и с чего начать
Мы проверяем веб-приложение по выбранной редакции списка: читаем код и конфигурацию, ищем типовые уязвимости на отдельном стенде и отдаём отчёт с шагами воспроизведения, серьёзностью и порядком исправления. Это ревью кода и конфигурации и проверка типовых уязвимостей. Мы не атакуем боевые системы, не проводим аттестацию и не имеем лицензии ФСТЭК. Цена лежит на шкале обследования: 200 000 ₽ и 2–3 недели за один-два процесса, 350 000 ₽ и 3–4 недели за несколько систем, 500 000 ₽ и 4–6 недель за контур или производство; сумма вычитается из первого этапа исправлений, если продолжаете с нами.
После отчёта можно остановиться: документ принадлежит вам, исправлять его может любой подрядчик. Если нужны исправления, они идут отдельными этапами с отдельной приёмкой, а исходники остаются в вашем репозитории. Описание услуги — на странице «Аудит безопасности веб-приложения», все цены и сроки — на странице «Тарифы».
Частые вопросы
Что такое OWASP Top 10 простыми словами?
Это список десяти групп ошибок, из-за которых чаще всего взламывают веб-приложения. Его составляет открытое сообщество OWASP. Список даёт общий язык заказчику, разработчику и аудитору, но не является стандартом или сертификатом.
Нужно ли соответствовать OWASP Top 10 по закону?
Нет, как отдельного обязательного требования такого списка нет. Заказчики и опросники по безопасности часто просят проверить приложение «по OWASP», поэтому на него ссылаются в договорах. Требования регуляторов вашей отрасли проверяют отдельно.
Достаточно ли автоматического сканера?
Для начала да, но он не заменяет аудит. Сканер плохо находит ошибки доступа и бизнес-логики, хотя именно они дороже всего. Разумный набор: сканер в конвейере разработки и аудит с чтением кода перед запуском и после крупных изменений.
Как часто проводить проверку?
Перед первым запуском, после крупных изменений в правах, входе или платежах и по расписанию, которое вы определяете сами. Между проверками помогают автоматические проверки зависимостей и настроек при каждой выкладке.
Можно ли проверять чужой сайт?
Нет. Проверки без согласия владельца системы недопустимы, а на боевой системе их проводят только по письменному согласованию и в оговорённое время. Мы проверяем на отдельном стенде заказчика и боевые системы не атакуем.
Что делать, если аудит нашёл много замечаний?
Не исправлять всё сразу. Идти по серьёзности и по цене исправления: сначала доступ, вход и настройки, затем зависимости и остальное. После исправления нужна повторная проверка, иначе нельзя сказать, что замечание закрыто.
Покрывает ли OWASP Top 10 приложения с ИИ?
Частично. Обычные ошибки веб-приложения остаются, но у приложений на языковых моделях есть собственные риски, для которых существует отдельный перечень OWASP. Их проверяют отдельно, см. статью про prompt injection.
Сколько стоит аудит безопасности?
Цена лежит на шкале обследования: 200 000 ₽ за один-два процесса (2–3 недели), 350 000 ₽ за несколько систем (3–4 недели), 500 000 ₽ за контур или производство (4–6 недель). Сумма вычитается из первого этапа, если продолжаете с нами. Работы дешевле 150 000 ₽ мы не берём.