Топ-10 уязвимостей безопасности OWASP, часть 1

Топ-10 уязвимостей OWASP в 2021 году:

• Инъекция
• Сломанная аутентификация
• Раскрытие конфиденциальных данных
• Внешние объекты XML (XXE)
• Сломанный контроль доступа
• Неправильная конфигурация безопасности
• Межсайтовый скриптинг (XSS)
• Небезопасная десериализация
• Использование компонентов с известными уязвимостями
• Недостаточное ведение журнала и мониторинг

A1 Injection

Внедрение кода происходит, когда злоумышленник отправляет недопустимые данные в веб-приложение с намерением заставить его сделать что-то, для чего приложение не было разработано / запрограммировано.

Возможно, наиболее распространенным примером этой уязвимости системы безопасности является запрос SQL, использующий ненадежные данные . Вы можете увидеть один из примеров OWASP ниже:

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

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

Как предотвратить уязвимости, связанные с внедрением кода?

Предотвращение SQL-инъекций требует хранения данных отдельно от команд и запросов.

• Предпочтительным вариантом является использование безопасного API, который полностью избегает использования интерпретатора или предоставляет параметризованный интерфейс, или переход на использование инструментов объектно-реляционного сопоставления (ORM). Примечание. Даже при параметризации хранимые процедуры могут вводить SQL-инъекцию, если PL / SQL или T-SQL объединяют запросы и данные или выполняют враждебные данные с помощью EXECUTE IMMEDIATE или exec ().
• Используйте положительную или «разрешенную» проверку входных данных на стороне сервера. Это не полная защита, поскольку многим приложениям требуются специальные символы, например текстовые области или API для мобильных приложений.
• Для любых остаточных динамических запросов экранируйте специальные символы, используя специальный синтаксис экранирования для этого интерпретатора. Примечание. Структуры SQL, такие как имена таблиц, имена столбцов и т. Д., Не могут быть экранированы, и поэтому имена структур, задаваемые пользователем, опасны. Это обычная проблема в программах для написания отчетов.
• Используйте LIMIT и другие элементы управления SQL в запросах, чтобы предотвратить массовое раскрытие записей в случае внедрения SQL.

A2 Broken Authentication and Session Management

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

В этом разделе мы рассмотрим некоторые из наиболее распространенных механизмов аутентификации, используемых веб-сайтами, и обсудим потенциальные уязвимости в них. Мы выделим как внутренние уязвимости в различных механизмах аутентификации, так и некоторые типичные уязвимости, возникающие в результате их неправильной реализации. Наконец, мы дадим некоторые базовые рекомендации о том, как обеспечить максимальную надежность ваших собственных механизмов аутентификации.

Что такое аутентификация?

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

Существует три фактора аутентификации, по которым можно разделить различные типы аутентификации:

• Что-то, что вы знаете , например пароль или ответ на секретный вопрос. Их иногда называют «факторами знания».
• Что-то , что у вас есть , то есть физический объект, например мобильный телефон или токен безопасности. Их иногда называют «факторами владения».
• Что-то, чем вы являетесь или делаете, например, ваши биометрические данные или модели поведения. Иногда их называют «факторами принадлежности».

Механизмы аутентификации полагаются на ряд технологий для проверки одного или нескольких из этих факторов.

Типы уязвимостей неработающей аутентификации

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

• Разрешает автоматические атаки, такие как заполнение учетных данных, когда у злоумышленника есть список действительных имен пользователей и паролей .
• Разрешает грубую силу или другие автоматические атаки.
• Разрешает стандартные, слабые или общеизвестные пароли, такие как Password1 или admin / admin.
• Использует слабые или неэффективные процессы восстановления учетных данных и забытого пароля, такие как «ответы на основе знаний», которые нельзя сделать безопасными.
• Использует простой текст, зашифрованные пароли или пароли со слабым хешем.
• Отсутствует или не работает многофакторная аутентификация.
• Предоставляет идентификаторы сеанса в URL-адресе (например, перезапись URL-адреса).
• Не меняет идентификаторы сеанса после успешного входа в систему.
• Не делает недействительными идентификаторы сеанса. Пользовательские сеансы или токены аутентификации (особенно токены единого входа (SSO)) не аннулируются должным образом во время выхода из системы или периода бездействия.

Как предотвратить уязвимости с нарушенной аутентификацией?

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

Технические рекомендации OWASP следующие:

• По возможности внедряйте многофакторную аутентификацию, чтобы предотвратить автоматические атаки с заполнением учетных данных, перебором и повторным использованием украденных учетных данных.
• Не отправляйте и не развертывайте учетные данные по умолчанию, особенно для администраторов.
• Внедрите проверку ненадежных паролей, например проверку новых или измененных паролей по списку из 10 000 самых плохих паролей.
• Согласуйте политику длины, сложности и ротации паролей с рекомендациями NIST 800-63 B в разделе 5.1.1 для запомненных секретов или другими современными политиками паролей, основанными на фактах.
• Убедитесь, что пути регистрации, восстановления учетных данных и API защищены от атак перечисления учетных записей, используя одни и те же сообщения для всех результатов.
• Ограничивайте количество неудачных попыток входа в систему или все чаще откладывайте их. Регистрируйте все сбои и предупреждайте администраторов при обнаружении заполнения учетных данных, перебора или других атак.
• Используйте безопасный встроенный диспетчер сеансов на стороне сервера, который генерирует новый случайный идентификатор сеанса с высокой энтропией после входа в систему. Идентификаторы сеанса не должны быть в URL-адресе. Идентификаторы также должны быть надежно сохранены и аннулированы после выхода из системы, простоя и абсолютного тайм-аута.

A3 Cross-Site Scripting (XSS)

Межсайтовый скриптинг (также известный как XSS) - это уязвимость веб-безопасности, которая позволяет злоумышленнику нарушить взаимодействие пользователей с уязвимым приложением. Это позволяет злоумышленнику обойти одну и ту же политику происхождения, которая предназначена для отделения разных веб-сайтов друг от друга. Уязвимости межсайтового сценария обычно позволяют злоумышленнику маскироваться под пользователя-жертву, выполнять любые действия, которые пользователь может выполнить, и получать доступ к любым данным пользователя. Если пользователь-жертва имеет привилегированный доступ к приложению, злоумышленник может получить полный контроль над всеми функциями и данными приложения.

Как работает XSS?

Межсайтовый скриптинг работает, манипулируя уязвимым веб-сайтом, чтобы он возвращал пользователям вредоносный код JavaScript. Когда вредоносный код выполняется в браузере жертвы, злоумышленник может полностью скомпрометировать свое взаимодействие с приложением.

Как проверить XSS

Вы можете подтвердить большинство видов XSS-уязвимостей, внедрив полезную нагрузку, которая заставляет ваш собственный браузер выполнять произвольный JavaScript. Долгое время эта alert()функция использовалась для этой цели, потому что она короткая, безвредная, и ее довольно сложно пропустить при успешном вызове. Фактически, вы решаете большинство наших XSS-лабораторий, вызывая alert()смоделированный браузер жертвы.

К сожалению, при использовании Chrome есть небольшая загвоздка. Начиная с версии 92 (20 июля 2021 г.) вызовы iframe из разных источников запрещены alert(). Поскольку они используются для создания некоторых из более сложных XSS-атак, вам иногда потребуется использовать альтернативные полезные данные PoC.

Какие бывают типы XSS-атак?

Существует три основных типа XSS-атак. Эти:

• Отраженный XSS , где вредоносный скрипт исходит из текущего HTTP-запроса.
• Сохраненный XSS , где вредоносный скрипт исходит из базы данных сайта.
• XSS на основе DOM , где уязвимость существует в коде на стороне клиента, а не на стороне сервера.

Отраженный межсайтовый скриптинг

Reflected XSS - это простейшая разновидность межсайтового скриптинга. Он возникает, когда приложение получает данные в HTTP-запросе и включает эти данные в немедленный ответ небезопасным способом.

Вот простой пример отраженной уязвимости XSS:

https://insecure-website.com/status?message=All+is+well.

<p>Status: All is well.</p>

Приложение не выполняет никакой другой обработки данных, поэтому злоумышленник может легко построить такую ​​атаку:

https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>

<p>Status: <script>/* Bad stuff here... */</script></p>

Если пользователь посещает URL-адрес, созданный злоумышленником, сценарий злоумышленника выполняется в браузере пользователя в контексте сеанса пользователя с приложением. В этот момент скрипт может выполнить любое действие и получить любые данные, к которым у пользователя есть доступ.

Сохраненные межсайтовые сценарии

Сохраненный XSS (также известный как постоянный XSS или XSS второго порядка) возникает, когда приложение получает данные из ненадежного источника и небезопасным образом включает эти данные в свои последующие HTTP-ответы.

Рассматриваемые данные могут быть отправлены в приложение через HTTP-запросы; например, комментарии к сообщению в блоге, псевдонимы пользователей в чате или контактные данные в заказе клиента. В других случаях данные могут поступать из других ненадежных источников; например, приложение веб-почты, отображающее сообщения, полученные через SMTP, маркетинговое приложение, отображающее сообщения в социальных сетях, или приложение для мониторинга сети, отображающее пакетные данные из сетевого трафика.

Вот простой пример сохраненной уязвимости XSS . Приложение доски объявлений позволяет пользователям отправлять сообщения, которые отображаются для других пользователей:

<p>Hello, this is my message!</p>

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

<p><script>/* Bad stuff here... */</script></p>

Межсайтовый скриптинг на основе DOM

XSS на основе DOM (также известный как DOM XSS ) возникает, когда приложение содержит некоторый клиентский JavaScript, который обрабатывает данные из ненадежного источника небезопасным способом, обычно путем записи данных обратно в DOM.

В следующем примере приложение использует некоторый JavaScript для чтения значения из поля ввода и записи этого значения в элемент внутри HTML:

var search = document.getElementById('search').value;
var results = document.getElementById('results');
results.innerHTML = 'You searched for: ' + search;

Если злоумышленник может контролировать значение поля ввода, он может легко создать вредоносное значение, которое приведет к выполнению их собственного сценария:

You searched for: <img src=1 onerror='/* Bad stuff here... */'>

В типичном случае поле ввода заполняется из части HTTP-запроса, такой как параметр строки запроса URL-адреса, что позволяет злоумышленнику осуществить атаку с использованием вредоносного URL-адреса таким же образом, как и отраженный XSS.