Чтобы помочь компаниям ориентироваться в мире уязвимостей веб-приложений и способах защиты от них, онлайн сообщество Open Web Application Security Project (OWASP) создало рейтинг
.
Мы следим за этим рейтингом, и в какой-то момент заметили, что наше распределение наиболее значимых уязвимостей отличается от того, который отражается в нем. Нам стало интересно узнать, насколько велика разница, поэтому мы подготовили собственный рейтинг, в котором отразили свой взгляд на уязвимости через призму нашего многолетнего опыта в деле анализа защищенности веб-приложений.
Почти половина веб-приложений (44%) была написана на языке Java; на втором и третьем месте находятся NodeJS (17%) и PHP (12%). Больше трети анализируемых приложений (39%) использовали микросервисную архитектуру.
Данные для исследования были получены в результате анализа веб-приложений тремя распространенными методами: черного, серого и белого ящиков. Так как почти все приложения, тестируемые методом серого ящика, были также проанализированы методом черного ящика, в нашей статистике мы объединили результаты по данным подходам. Таким образом, подавляющее большинство проектов по анализу защищенности веб-приложений (83%) было выполнено методом черного и серого ящиков.
Различия, вызванные разными подходами анализа веб-приложений
Так как анализ приложений методами черного, серого и белого ящиков предполагает разный уровень доступа к приложению, то и типы уязвимостей, которые с наибольшей вероятностью будут обнаружены, тоже отличаются. Мы сравнили уязвимости, найденные с доступом к исходному коду приложения и без него, и заметили, что четыре из пяти наиболее распространенных типов уязвимостей совпадают, хотя есть и различия.
Наиболее распространенные уязвимости, обнаруженные при различных подходах к анализу защищенности приложений
Кроме того, статистика показывает, что в среднем анализ методом белого ящика позволяет находить в одном приложении больше уязвимостей, в том числе критических (например, SQL Injection). В среднем при анализе методом черного и серого ящиков было найдено 23 уязвимости, а при анализе методом белого — 30.
Доля уязвимостей различного уровня риска в одном приложении (средние значения), найденных при анализе методом белого ящика, 2021–2023 ( )
Несмотря на то что метод белого ящика позволяет найти больше уязвимостей в приложении, анализ методом черного и серого ящиков помогает посмотреть на приложение с точки зрения злоумышленника и выявить наиболее приоритетные для устранения уязвимости.
Почти половина всех обнаруженных уязвимостей была среднего уровня риска, еще 37% — высокого уровня. Последние могли привести к ошибкам в работе приложения и негативно повлиять на бизнес заказчиков. Так, в одном из приложений недостаточная проверка предоставляемых данных позволила нам получить доступ к внутренним сервисам и потенциально проводить атаки, ведущие к финансовым потерям.
Рекомендация: реализовать аутентификацию и авторизацию на уровне приложения в соответствии с установленной ролевой моделью. Если ресурс не должен быть общедоступным, по умолчанию запрещать доступ.
Среди чувствительных данных, выявленных при анализе веб-приложений, были: значения одноразовых паролей (One-Time-Password), учетные данные в открытом виде, полные пути веб-директорий приложений и другая внутренняя информация, которая помогает лучше понять архитектуру приложения.
Рекомендация: не оставлять файлы с конфиденциальными данными (пароли пользователей, резервные копии) в веб-директории приложений. Исключить разглашение конфиденциальных данных при обращении к функциям приложения (если данная функция не используется для получения доступа к конфиденциальным данным).
В частности, злоумышленник может использовать подделку межсерверных запросов в цепочке с другими уязвимостями для развития атаки на веб-сервер или чтения исходного кода приложения.
Рекомендация: по возможности создать белый список ресурсов, на которые разрешено отправлять запросы из приложения. Блокировать запросы к любым ресурсам, не включенным в этот список. Блокировать запросы, содержащие полные URL-адреса. Подобные ограничения рекомендуется установить как на уровне приложения, так и на уровне межсетевого экрана.
Уязвимости внедрения операторов SQL могут привести к получению конфиденциальных данных или выполнению произвольного кода. Например, на одном из проектов в приложении, в котором может зарегистрироваться любой пользователь сети интернет, была обнаружена уязвимость SQL Injection, которая позволила нам получить учетные данные администратора одной из внутренних систем.
Рекомендация: использовать параметризированные SQL-запросы в коде приложения вместо простого объединения с шаблоном запроса. При невозможности их использования убедиться, что все данные, поступающие от пользователя и использующиеся в формировании SQL-запросов, не могут быть использованы для изменения логики запроса.
Больше половины всех обнаруженных уязвимостей XSS относилось к приложениям ИТ-компаний (55%), на втором месте по наличию данной уязвимости — приложения государственных учреждений (39%).
Злоумышленник может использовать уязвимость типа «межсайтовое выполнение сценариев» для получения аутентификационных данных пользователей (например, cookie), проведения фишинговых атак и распространения вредоносного ПО. Например, на одном из проектов использование XSS в цепочке с другими уязвимостями позволило изменить пароль пользователя на значение, известное нам, что в итоге позволяло получить доступ к приложению с привилегиями атакуемого пользователя.
Рекомендация: экранировать служебные символы, которые могут быть использованы для форматирования HTML-страниц, в зависимости от контекста, в который вставляются данные путем их замены на аналоги, которые не являются символами форматирования. Экранирование должно быть реализовано для любых данных, получаемых из внешних источников (включая заголовки HTTP, такие как User-Agent и Referer).
Например, в одном из приложений не проверялась подпись JWT (JSON Web Token), что позволяло злоумышленнику изменить собственный JWT (указав ID другого пользователя) и использовать полученный токен для выполнения различных действий в личном кабинете соответствующего пользователя.
Рекомендация: реализовать корректную проверку аутентификационных данных для доступа к приложению. При использовании токенов и идентификаторов сессий проверять их подпись. Секреты, используемые при аутентификации (ключи для шифрования, подписи и т. д.) должны быть уникальными и с высокой степенью энтропии. Хранить секреты необходимо отдельно, не в коде приложения.
Например, в одном из анализируемых приложений настройки сервера Nginx позволяли получить доступ к файлам, хранящимся в родительской директории (относительно директории, указанной в директиве alias). Это могло быть использовано для получения доступа к файлам с чувствительными данными.
Рекомендации: следовать лучшим практикам информационной безопасности при настройке систем, которые используются в ИТ-инфраструктуре. Автоматизировать процесс настройки, чтобы исключить возможные ошибки при настройке новых систем. Использовать разные учетные данные для тестовых систем и систем, введенных в эксплуатацию. Отключить неиспользуемые компоненты.
В частности, ошибки в реализации OTP могут позволить подобрать значение одноразового пароля, что приведет к обходу второго фактора аутентификации и упростит получение несанкционированного доступа к приложению.
Рекомендация: чтобы усложнить для атакующего процесс подбора учетных данных, стоит использовать CAPTCHA. Также следует применять превентивные средства защиты (WAF, IPS), чтобы оперативно блокировать попытки подбора учетных данных. Блокирование должно осуществляться не только в случае множественных неудачных попыток аутентификации для одной учетной записи, но и для множественных неудачных попыток входа для разных учетных записей из одного источника.
Стоит отметить, что невысокое количество уязвимостей данного типа обуславливается в том числе тем, что для анализа приложений часто предоставляется тестовый стенд, а не введенное в эксплуатацию приложение.
Несмотря на то что количество уязвимых приложений не так велико, последствия от использования слабых учетных данных могут быть значительными. В зависимости от типа учетной записи атакующий может получить доступ как к базовым функциям приложения, так и к административным сценариям, что уже может повлиять на бизнес-процессы.
Рекомендация: внедрить проверку слабости паролей, например сравнение новых или измененных паролей со списком из 10 тысяч наиболее слабых паролей. Установить парольные политики относительно минимальной длины, сложности и частоты смены пароля, а также другие современные парольные политики (например, требование не использовать имя пользователя в значении пароля).
( )
Среди уязвимых компонентов были обнаружены фреймворки и различные зависимости (библиотеки, модули и т. д.). Некоторые из них позволили нашей команде получить доступ к серверам веб-приложений и, соответственно, доступ к внутренней сети заказчика.
Рекомендация: проводить регулярные проверки версий используемых программных компонентов и при необходимости обновлять их. Использовать только доверенные компоненты, которые успешно прошли тестирования безопасности. Отключить неиспользуемые компоненты.
Мы следим за этим рейтингом, и в какой-то момент заметили, что наше распределение наиболее значимых уязвимостей отличается от того, который отражается в нем. Нам стало интересно узнать, насколько велика разница, поэтому мы подготовили собственный рейтинг, в котором отразили свой взгляд на уязвимости через призму нашего многолетнего опыта в деле анализа защищенности веб-приложений.
Портрет участников исследования и приложений
Мы собрали данные из выборки проектов по анализу защищенности веб-приложений, проведенных нашей командой в 2021–2023 годах. География анализируемых приложений — это преимущественно Россия, Китай и страны Ближнего Востока.Почти половина веб-приложений (44%) была написана на языке Java; на втором и третьем месте находятся NodeJS (17%) и PHP (12%). Больше трети анализируемых приложений (39%) использовали микросервисную архитектуру.
Данные для исследования были получены в результате анализа веб-приложений тремя распространенными методами: черного, серого и белого ящиков. Так как почти все приложения, тестируемые методом серого ящика, были также проанализированы методом черного ящика, в нашей статистике мы объединили результаты по данным подходам. Таким образом, подавляющее большинство проектов по анализу защищенности веб-приложений (83%) было выполнено методом черного и серого ящиков.
Различия, вызванные разными подходами анализа веб-приложений
Так как анализ приложений методами черного, серого и белого ящиков предполагает разный уровень доступа к приложению, то и типы уязвимостей, которые с наибольшей вероятностью будут обнаружены, тоже отличаются. Мы сравнили уязвимости, найденные с доступом к исходному коду приложения и без него, и заметили, что четыре из пяти наиболее распространенных типов уязвимостей совпадают, хотя есть и различия.
| Черный и серый ящики | Белый ящик | |
| 1. Раскрытие чувствительной информации | VS | 1. Недостатки контроля доступа |
| 2. Недостатки контроля доступа | 2. Внедрение операторов SQL | |
| 3. Межсайтовое выполнение сценариев | 3. Раскрытие чувствительной информации | |
| 4. Подделка межсерверных запросов | 4. Недостатки аутентификации | |
| 5. Недостатки аутентификации | 5. Межсайтовое выполнение сценариев |
Кроме того, статистика показывает, что в среднем анализ методом белого ящика позволяет находить в одном приложении больше уязвимостей, в том числе критических (например, SQL Injection). В среднем при анализе методом черного и серого ящиков было найдено 23 уязвимости, а при анализе методом белого — 30.
Доля уязвимостей различного уровня риска в одном приложении (средние значения), найденных при анализе методом белого ящика, 2021–2023 ( )
Несмотря на то что метод белого ящика позволяет найти больше уязвимостей в приложении, анализ методом черного и серого ящиков помогает посмотреть на приложение с точки зрения злоумышленника и выявить наиболее приоритетные для устранения уязвимости.
ТОР 10 уязвимостей в веб-приложениях
Чтобы определить наиболее распространенные и критические уязвимости, мы проанализировали результаты проектов по анализу защищенности веб-приложений за последние три года.| Рейтинг является экспертным заключением, основанным на том, как много приложений содержит конкретную уязвимость и насколько критично влияние этой уязвимости на приложение. Предоставленные в рейтинге рекомендации являются обобщенными и основаны на стандартах и руководствах лучших практик информационной безопасности (таких как OWASP и NIST). |
| Место в нашем ТОР 10 | Место в OWASP |
| 1. Недостатки контроля доступа | |
| 2. Раскрытие чувствительной информации | |
| 3. Подделка межсерверных запросов (SSRF) | |
| 4. Внедрение операторов SQL | |
| 5. Межсайтовое выполнение сценариев (XSS) | |
| 6. Недостатки аутентификации | |
| 7. Недостатки конфигурации | |
| 8. Недостаточная защита от перебора пароля | |
| 9. Слабый пароль пользователя | |
| 10. Использование компонентов с известными уязвимостями |
1. Недостатки контроля доступа
70% всех проанализированных нами приложений содержали уязвимости, связанные с недостатками контроля доступа.Почти половина всех обнаруженных уязвимостей была среднего уровня риска, еще 37% — высокого уровня. Последние могли привести к ошибкам в работе приложения и негативно повлиять на бизнес заказчиков. Так, в одном из приложений недостаточная проверка предоставляемых данных позволила нам получить доступ к внутренним сервисам и потенциально проводить атаки, ведущие к финансовым потерям.
Рекомендация: реализовать аутентификацию и авторизацию на уровне приложения в соответствии с установленной ролевой моделью. Если ресурс не должен быть общедоступным, по умолчанию запрещать доступ.
2. Раскрытие чувствительной информации
Данный тип уязвимостей также часто встречается в веб-приложениях. По сравнению с «Недостатками контроля доступа» категория «Раскрытие чувствительной информации» содержит больше уязвимостей низкого уровня риска.Среди чувствительных данных, выявленных при анализе веб-приложений, были: значения одноразовых паролей (One-Time-Password), учетные данные в открытом виде, полные пути веб-директорий приложений и другая внутренняя информация, которая помогает лучше понять архитектуру приложения.
Рекомендация: не оставлять файлы с конфиденциальными данными (пароли пользователей, резервные копии) в веб-директории приложений. Исключить разглашение конфиденциальных данных при обращении к функциям приложения (если данная функция не используется для получения доступа к конфиденциальным данным).
3. Подделка межсерверных запросов (SSRF)
Популярность облачной и микросервисной архитектуры постоянно растет. Это, в свою очередь, увеличивает поверхность для атак типа «Подделка межсерверных запросов», так как сервисов, взаимодействующих через протокол HTTP (или другие легковесные протоколы) больше, чем в обычной архитектуре. Более половины проанализированных приложений (57%) содержали уязвимость, которая позволяла злоумышленнику взаимодействовать с внутренними сервисами в обход логики приложения.В частности, злоумышленник может использовать подделку межсерверных запросов в цепочке с другими уязвимостями для развития атаки на веб-сервер или чтения исходного кода приложения.
Рекомендация: по возможности создать белый список ресурсов, на которые разрешено отправлять запросы из приложения. Блокировать запросы к любым ресурсам, не включенным в этот список. Блокировать запросы, содержащие полные URL-адреса. Подобные ограничения рекомендуется установить как на уровне приложения, так и на уровне межсетевого экрана.
4. Внедрение операторов SQL
За 2021–2023 годы наибольшее количество уязвимостей высокого уровня риска относились к уязвимостям внедрения операторов SQL. Несмотря на это, мы поместили данную категорию на 4-е место, потому что только 43% всех проанализированных веб-приложений содержали уязвимость данного типа.Уязвимости внедрения операторов SQL могут привести к получению конфиденциальных данных или выполнению произвольного кода. Например, на одном из проектов в приложении, в котором может зарегистрироваться любой пользователь сети интернет, была обнаружена уязвимость SQL Injection, которая позволила нам получить учетные данные администратора одной из внутренних систем.
Рекомендация: использовать параметризированные SQL-запросы в коде приложения вместо простого объединения с шаблоном запроса. При невозможности их использования убедиться, что все данные, поступающие от пользователя и использующиеся в формировании SQL-запросов, не могут быть использованы для изменения логики запроса.
5. Межсайтовое выполнение сценариев (XSS)
Уязвимости типа «Межсайтовое выполнение сценариев» были обнаружены в 61% всех проанализированных веб-приложений. Так как в большинстве случаев данная уязвимость имела средний уровень риска, мы разместили ее на 5-м месте, несмотря на то, что она так распространена.Больше половины всех обнаруженных уязвимостей XSS относилось к приложениям ИТ-компаний (55%), на втором месте по наличию данной уязвимости — приложения государственных учреждений (39%).
Злоумышленник может использовать уязвимость типа «межсайтовое выполнение сценариев» для получения аутентификационных данных пользователей (например, cookie), проведения фишинговых атак и распространения вредоносного ПО. Например, на одном из проектов использование XSS в цепочке с другими уязвимостями позволило изменить пароль пользователя на значение, известное нам, что в итоге позволяло получить доступ к приложению с привилегиями атакуемого пользователя.
Рекомендация: экранировать служебные символы, которые могут быть использованы для форматирования HTML-страниц, в зависимости от контекста, в который вставляются данные путем их замены на аналоги, которые не являются символами форматирования. Экранирование должно быть реализовано для любых данных, получаемых из внешних источников (включая заголовки HTTP, такие как User-Agent и Referer).
6. Недостатки аутентификации
Несмотря на то что почти половина обнаруженных уязвимостей типа «Недостатки аутентификации» была среднего уровня риска (47%), также были обнаружены уязвимости высокого уровня риска, которые, например, позволяли получить доступ к веб-приложению от имени клиента заказчика.Например, в одном из приложений не проверялась подпись JWT (JSON Web Token), что позволяло злоумышленнику изменить собственный JWT (указав ID другого пользователя) и использовать полученный токен для выполнения различных действий в личном кабинете соответствующего пользователя.
Рекомендация: реализовать корректную проверку аутентификационных данных для доступа к приложению. При использовании токенов и идентификаторов сессий проверять их подпись. Секреты, используемые при аутентификации (ключи для шифрования, подписи и т. д.) должны быть уникальными и с высокой степенью энтропии. Хранить секреты необходимо отдельно, не в коде приложения.
7. Небезопасная конфигурация
Чуть меньше половины проанализированных приложений имело небезопасные настройки конфигурации. В категорию «Небезопасная конфигурация» попадают уязвимости разного типа, от включенного режима отладки до не включенной аутентификации.Например, в одном из анализируемых приложений настройки сервера Nginx позволяли получить доступ к файлам, хранящимся в родительской директории (относительно директории, указанной в директиве alias). Это могло быть использовано для получения доступа к файлам с чувствительными данными.
Рекомендации: следовать лучшим практикам информационной безопасности при настройке систем, которые используются в ИТ-инфраструктуре. Автоматизировать процесс настройки, чтобы исключить возможные ошибки при настройке новых систем. Использовать разные учетные данные для тестовых систем и систем, введенных в эксплуатацию. Отключить неиспользуемые компоненты.
8. Недостаточная защита от перебора пароля
Более трети всех проанализированных приложений позволяли проводить атаки, направленные на подбор учетных данных. Среди уязвимых механизмов мы видели реализации механизма одноразовых паролей (One-Time-Password, OTP) и аутентификации для доступа к различным ресурсам (личным кабинетам, файловым системам и т. д.).В частности, ошибки в реализации OTP могут позволить подобрать значение одноразового пароля, что приведет к обходу второго фактора аутентификации и упростит получение несанкционированного доступа к приложению.
Рекомендация: чтобы усложнить для атакующего процесс подбора учетных данных, стоит использовать CAPTCHA. Также следует применять превентивные средства защиты (WAF, IPS), чтобы оперативно блокировать попытки подбора учетных данных. Блокирование должно осуществляться не только в случае множественных неудачных попыток аутентификации для одной учетной записи, но и для множественных неудачных попыток входа для разных учетных записей из одного источника.
9. Слабый пароль пользователя
22% проанализированных приложений позволяли пользователям устанавливать слабые пароли.Стоит отметить, что невысокое количество уязвимостей данного типа обуславливается в том числе тем, что для анализа приложений часто предоставляется тестовый стенд, а не введенное в эксплуатацию приложение.
Несмотря на то что количество уязвимых приложений не так велико, последствия от использования слабых учетных данных могут быть значительными. В зависимости от типа учетной записи атакующий может получить доступ как к базовым функциям приложения, так и к административным сценариям, что уже может повлиять на бизнес-процессы.
Рекомендация: внедрить проверку слабости паролей, например сравнение новых или измененных паролей со списком из 10 тысяч наиболее слабых паролей. Установить парольные политики относительно минимальной длины, сложности и частоты смены пароля, а также другие современные парольные политики (например, требование не использовать имя пользователя в значении пароля).
10. Использование компонентов с известными уязвимостями
Последняя, но не менее важная категория распространенных уязвимостей — использование компонентов с известными уязвимостями.( )
Среди уязвимых компонентов были обнаружены фреймворки и различные зависимости (библиотеки, модули и т. д.). Некоторые из них позволили нашей команде получить доступ к серверам веб-приложений и, соответственно, доступ к внутренней сети заказчика.
Рекомендация: проводить регулярные проверки версий используемых программных компонентов и при необходимости обновлять их. Использовать только доверенные компоненты, которые успешно прошли тестирования безопасности. Отключить неиспользуемые компоненты.
Заключение
Исправление наиболее распространенных уязвимостей в веб-приложениях, описанных в нашем исследовании, позволит защитить ваши конфиденциальные данные и избежать компрометации веб-приложений и смежных систем. Для повышения безопасности веб-приложений и своевременного детектирования возможных атак на них мы рекомендуем:- использовать подход Secure Software Development Lifecycle (SSDLC) при разработке ПО;
- проводить регулярный анализ защищенности веб-приложений, особенно при добавлении новых функций или перед его релизом;
- использовать механизмы логирования и отслеживания работы приложения.
