OWASP Top 10 2017 RC



    Обновился список Топ-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 Недостаточное журналирование и мониторинг

    Изменения


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

    На 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 testing guide на русском
    • +20
    • 14,4k
    • 5
    Pentestit 58,11
    Информационная безопасность
    Поделиться публикацией
    Комментарии 5
    • 0
      Не совсем понятно про десятый пункт (Underprotected APIs).
      Что конкретно имеется в виду? (если можно на примере). Спасибо.
      • 0
        В принципе, все тоже самое что и остальные пункты вместе взятые, но упор делается на то, что api предназначено для использования программами (скрипты в браузере, другие серверы, мобильные приложения) а не человеком, плюс отсутствие UI и большой выбор форматов: swagger, rest, json, xml и т.д. усложняет тестирование.
        • +2
          По сути, то же самое, что остальные 9 пунктов, но применительно к API. Например:
          • Легко сделали веб-сервис, добавив аннотацию Resource к доменному классу, но забыв настроить права доступа к веб-сервису. Думали, что веб-сервис разрешает только чтение, а на самом деле он разрешает также изменение объекта
          • SQL инъекция в одном из полей JSON
          • На клиенте проверяют доступ, скрывая недоступные пункты меню, а на стороне API — не проверяют. Любой может послать API запрос к административной функции
          • При конвертации объекта в JSON также конвертируются лишние поля (или всё дерево объектов). Не только ИД и имя пользователя, а и пароль, адрес, номер паспорта и т. д.
          • 0
            Проверка значений, передающихся через API.

            Example Attack Scenarios

            Scenario #1: Imagine a mobile banking app that connects to an XML API at the bank for account information and
            performing transactions. The attacker reverse engineers the app and discovers that the user account number is passed as part of the authentication request to the server along with the username and password. The attacker sends legitimate
            credentials, but another user’s account number, gaining full access to the other user’s account.

            Scenario #2: Imagine a public API offered by an Internet startup for automatically sending text messages. The API
            accepts JSON messages that contain a “transactionid” field. The API parses out this “transactionid” value as a string and
            concatenates it into a SQL query, without escaping or parameterizing it. As you can see the API is just as susceptible
            to SQL injection as any other type of application. In either of these cases, the vendor may not provide a web UI to use these services, making security testing more difficult.
            • 0
              Всем спасибо за ответы.
              Я просто не понял, почему это в отдельный пункт вынесли.
              По сути то дублирует остальные, точнее может быть частным случаем других пунктов.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое