Обновился список Топ-10 уязвимостей от OWASP — наиболее критичных рисков безопасности веб-приложений.
На проект OWASP Топ-10 ссылается множество стандартов, инструментов и организаций, включая MITRE, PCI DSS, DISA, FTC, и множество других. OWASP Топ-10 является признанной методологией оценки уязвимостей веб-приложений во всем мире.
Open Web Application Security Project (OWASP) — это открытый проект обеспечения безопасности веб-приложений. Сообщество OWASP включает в себя корпорации, образовательные организации и частных лиц со всего мира. Сообщество работает над созданием статей, учебных пособий, документации, инструментов и технологий, находящихся в свободном доступе.
Версия стандарта обновляется приблизительно раз в три года и отражает современные тренды безопасности веб-приложений.
OWASP Top 10 2013
Список самых опасных рисков (уязвимостей) веб-приложений от 2013 года:
- A1 Внедрение кода
- A2 Некорректная аутентификация и управление сессией
- A3 Межсайтовый скриптинг
- A4 Небезопасные прямые ссылки на объекты
- A5 Небезопасная конфигурация
- A6 Утечка чувствительных данных
- A7 Отсутствие контроля доступа к функциональному уровню
- A8 Подделка межсайтовых запросов
- A9 Использование компонентов с известными уязвимостями
- A10 Невалидированные редиректы
OWASP Top 10 2017 RC
Список самых опасных рисков (уязвимостей) веб-приложений от 2017 года:
- A1 Внедрение кода
- A2 Некорректная аутентификация и управление сессией
- A3 Межсайтовый скриптинг
- A4 Нарушение контроля доступа
- A5 Небезопасная конфигурация
- A6 Утечка чувствительных данных
- A7 Недостаточная защита от атак (NEW)
- A8 Подделка межсайтовых запросов
- A9 Использование компонентов с известными уязвимостями
- A10 Незащищенный API (NEW)
Изменения
Первая тройка — инъекции кода, недостатки управления и хранения сессия и межсайтовый скриптинг остались без изменений, это свидетельствует о том, что несмотря на большое количество лучших практик по написанию безопасного кода, средств очистки данных, внедрения разнообразных токенов и прочего — безопаснее веб-приложения не становятся.
На 4 место вернулась старая категория — Broken Access Control, которая в новой редакции состоит из слияния А4 и А7 из редакции 2013 года.
7 место теперь занимает новая категория — Insufficient Attack Protection. В большинстве веб-приложений и окружения отсутствует возможность обнаруживать, предотвращать и реагировать на современные атаки — как автоматические, так и выполняемые вручную. Выявлении и защита от атак выходит далеко за рамки проверки базового ввода (обычно это валидация входных значаний) и должна включать в себя автоматическое обнаружение, журналирование, реагирование и даже блокировку попыток эксплуатации. Владельцы приложений также должны иметь возможность быстро развертывать исправления для защиты от атак. Другими словами — это прямая рекомендация использовать web application firewall для защиты веб-приложения.
С 10 места пропали невалидированные редиректы, а их место заняли незащищенные средства API классов, таких как JavaScript, SOAP/XML, REST/JSON, RPC, GWT, и так далее. Эти классы часто являются незащищенными и содержат множество уязвимостей.
Участники проекта Open Web Application Security Project (OWASP) уже более 13 лет составляют список Топ-10 самых опасных уязвимостей в веб-приложениях, стараясь привлечь внимание веб-разработчиков. На сайте OWASP каждая из уязвимостей разбирается подробно.
Ссылки
> Проект OWASP
> OWASP Топ-10 2017 RC
> OWASP testing guide на русском
Поделиться с друзьями
IlyaMS
Не совсем понятно про десятый пункт (Underprotected APIs).
Что конкретно имеется в виду? (если можно на примере). Спасибо.
Lyazar
В принципе, все тоже самое что и остальные пункты вместе взятые, но упор делается на то, что api предназначено для использования программами (скрипты в браузере, другие серверы, мобильные приложения) а не человеком, плюс отсутствие UI и большой выбор форматов: swagger, rest, json, xml и т.д. усложняет тестирование.
elegorod
По сути, то же самое, что остальные 9 пунктов, но применительно к API. Например:
LukaSafonov
Проверка значений, передающихся через API.
IlyaMS
Всем спасибо за ответы.
Я просто не понял, почему это в отдельный пункт вынесли.
По сути то дублирует остальные, точнее может быть частным случаем других пунктов.