Что такое веб уязвимость
Типы уязвимостей сайтов
Сайты в интернете, как и другое программное обеспечение, подвержены различным уязвимостям, что позволяет злоумышленникам получать доступ к секретным и важным данным или выполнять другие незаконные действия. Некоторые уязвимости очень опасны и встречаются чаще, чем хотелось бы, другие же менее опасны и встречаются редко. Важно знать какие уязвимости бывают, проверять свой ресурс на их присутствие и вовремя их исправлять.
Типы уязвимостей сайтов
А теперь давайте перейдем к нашему списку.
1. Инъекции/Injection
Если три последние вам ни о чем не говорят, то про SQL инъекции вы однозначно слышали. С помощью них злоумышленник может получить доступ к базе данных, прочитать из нее секретные данные или даже записать свои значения. Инъекции возникают, когда данные, передаваемые интерпретатору не проверяются на наличие управляющих последовательностей и команд, таких, как кавычки в SQL.
2. Проблемы аутентификации и проверки сессий
Многим приложениям необходимо идентифицировать пользователей для работы с ними. Часто функции для проверки подлинности и управления сессиями реализуются неверно, что позволяет злоумышленникам получать доступ к учетным записям пользователей в обход паролей. Злоумышленники могут каким-либо образом перехватить ключи или токены сеанса, которые выступают в качестве идентификаторов пользователей и использовать их временно или постоянно.
3. XSS
Первые две уязвимости представляли больше опасности для сайта и его сервера. XSS не так опасна для сервера, но опасна для пользователя. Она работает в браузере пользователя, и поэтому позволяет только украсть его данные. XSS или Cross-Site Scripting работает в JavaScript. Принцип тот же, что и в инъекциях. Злоумышленник передает специальную строку в каком-либо поле, в строке содержится JS код, далее браузер думает, что этот код отправлен сайтом и выполняет его, а код может быть любым. Для противодействия таким атакам нужно экранировать все специальные символы с помощью функции htmlspecialchars или аналогов.
4. Проблемы контроля доступа
Также под проблемой контроля доступа можно понимать ошибки в коде вашего приложения, которые открывают доступ к секретным данным для не авторизованных пользователей.
5. Неверная конфигурация
Для хорошей безопасности приложению требуется безопасная конфигурация не только спланированная и разработанная на уровне приложения и фреймворка, но и правильно настроенные сервера. Настройки безопасности должны разрабатываться, реализовываться и постоянно поддерживаться. Конфигурация многих сервисов по умолчанию не безопасна. Кроме того, программное обеспечение должно быть всегда в актуальном состоянии.
6. Незащищенные конфиденциальные данные
Многие веб-приложения, сайты и API не защищают конфиденциальные данные пользователя и передают их в открытом виде. К таким данным могут относиться не только пароли, токены и ключи, но и медицинская, финансовая информация. Злоумышленники могут похитить или даже модифицировать важные данные с помощью атаки «Человек посередине». Конфиденциальные данные должны быть защищены, например, с помощью шифрования https или других методов.
7. Недостаточная защита от атак
8. Уязвимости CSRF
Атака CSRF или Cross-Site Request Forgery позволяет злоумышленнику заставить браузер жертвы отправить определенный HTTP запрос, включая куки, файлы сеанса и любую другую, автоматически включаемую информацию в уязвимое веб-приложение.
Таким образом, злоумышленник получает возможность генерировать запросы из браузера жертвы, которые приложение считает правильными и отправленными самой жертвой. Например, вы просто открываете ссылку, а сайт уже отправляет вашим друзьям сообщение с рекламным содержанием без вашего ведома или удаляет ваш аккаунт.
9. Использование компонентов с уязвимостями
Компоненты, такие как библиотеки, фреймворки и другие программные модули работают с теми же полномочиями, что и приложение. Если в одном из компонентов есть уязвимость, то в результате атаки на нее злоумышленник может украсть важные данные или даже получить управление над сервером. Приложения и API, использующие компоненты с известными уязвимостями могут подорвать защиту приложений и сделать возможными различные атаки. Там могут быть разные типы уязвимостей сайтов, и они могут открыть доступ к разным данным.
10. Незащищенные API
Большинство современных приложений часто включают в себя клиентские приложение и богатые API интерфейсы, доступные через JavaScript в браузере или из мобильных приложений. Они могут работать по протоколам SOAP/XML, REST/JSON, RPC, GWT и так далее. Эти API очень часто не защищены и тоже содержат множество ошибок, которые приводят к уязвимостям.
Выводы
В этой статье мы рассмотрели виды уязвимостей сайта, которые встречаются чаще всего по версии ресурса owasp. Как видите, среди чисто программных проблем, таких, как SQL инъекции, XSS или СSRF есть и проблемы в настройке серверов, которые тоже часто причиняют проблемы. Во всяком случае, теперь вы знаете какие уязвимости веб-сайтов бывают, и можете сделать ваш ресурс более безопасным.
Безопасность веб-приложений: от уязвимостей до мониторинга
Уязвимости веб-приложений возникают тогда, когда разработчики добавляют небезопасный код в веб-приложение. Это может происходить как на этапе разработки, так и на этапе доработки или исправления найденных ранее уязвимостей. Недостатки часто классифицируются по степени критичности и их распространенности. Объективной и наиболее популярной классификацией уязвимостей считается OWASP Top 10. Рейтинг составляется специалистами OWASP Project и актуализируется каждые 3-4 года. Текущий релиз выпущен в 2017 году, а следующий ожидается в 2020-2021.
Распространенные уязвимости
Для начала рассмотрим типовые уязвимости, которым подвержены многие веб-приложения.
Инъекции
Как и полагается, атаки класса «Инъекции» занимают лидирующую строчку рейтинга OWASP Top 10, встречаясь практически повсеместно и являясь крайне разнообразными в реализации. Уязвимости подобного класса начинаются SQL-инъекциями, в различных его вариациях, и заканчивая RCE — удаленным выполнением кода.
Межсайтовый скриптинг — уязвимость, встречающаяся на данный момент куда реже, чем раньше, если верить рейтингу OWASP Top 10, но несмотря на это не стала менее опасной для веб-приложений и пользователей. Особенно для пользователей, ведь атака XSS нацелена именно на них. В общем случае злоумышленник внедряет скрипт в веб-приложение, который срабатывает для каждого пользователя, посетившего вредоносную страницу.
LFI/RFI
Уязвимости данного класса позволяют злоумышленникам через браузер включать локальные и удаленные файлы на сервере в ответ от веб-приложения. Эта брешь присутствует там, где отсутствует корректная обработка входных данных, которой может манипулировать злоумышленник, инжектировать символы типа path traversal и включать другие файлы с веб-сервера.
Атаки через JSON и XML
Веб-приложения и API, обрабатывающие запросы в формате JSON или XML, также подвержены атакам, поскольку такие форматы имеют свои недостатки.
JSON (JavaScript Object Notation) — это облегченный формат обмена данными, используемый для связи между приложениями. Он похож на XML, но проще и лучше подходит для обработки с помощью JavaScript. Многие веб-приложения используют этот формат для обмена данными между собой и сериализации/десериализации данных. Некоторые веб-приложения также используют JSON для хранения важной информации, например, данных пользователя. Обычно используется в RESTful API и приложениях AJAX.
JSON чаще всего ассоциируется с API, тем не менее, часто используется даже в обычных и хорошо известных веб-приложениях. Например, редактирование материалов в WordPress производится именно через отправку запросов в формате JSON:
JSON Injection
Простая инъекция JSON на стороне сервера может быть выполнена в PHP следующим образом:
Простая инъекция JSON на стороне клиента может быть выполнена следующим образом:
JSON Hijacking
Захват JSON — атака, в некотором смысле похожая на подделку межсайтовых запросов (CSRF), при которой злоумышленник старается перехватить данные JSON, отправленные веб-приложению с веб-сервера:
XML External Entity
Атака внешней сущности XML (XXE) — это тип атаки, в котором используется широко доступная, но редко используемая функция синтаксических анализаторов XML. Используя XXE, злоумышленник может вызвать отказ в обслуживании (DoS), а также получить доступ к локальному и удаленному контенту и службам. XXE может использоваться для выполнения подделки запросов на стороне сервера (SSRF), заставляя веб-приложение выполнять запросы к другим приложениям. В некоторых случаях c помощью XXE может даже выполнить сканирование портов и удаленное выполнение кода.
XML (Extensible Markup Language) — очень популярный формат данных. Он используется во всем: от веб-сервисов (XML-RPC, SOAP, REST) до документов (XML, HTML, DOCX) и файлов изображений (данные SVG, EXIF). Для интерпретации данных XML приложению требуется анализатор XML, известный как XML-процессор. XML можно использовать не только для объявления элементов, атрибутов и текста. XML-документы могут быть определенного типа. Тип указывается в самом документе, объявляя определение типа. Анализатор XML проверяет, соответствует ли XML-документ указанному типу, прежде чем обрабатывать документ. Вы можете использовать два варианта определений типов: определение схемы XML (XSD) или определение типа документа (DTD). Уязвимости XXE встречаются в последнем варианте. Хотя DTD можно считать устаревшими, но он все еще широко используются.
Фактически, объекты XML могут поступать практически откуда угодно, включая внешние источники (отсюда и название XML External Entity). При этом, XXE может стать разновидностью атаки подделки запросов на стороне сервера (SSRF). Злоумышленник может создать запрос, используя URI (известный в XML как системный идентификатор). Если синтаксический анализатор XML настроен для обработки внешних сущностей, а по умолчанию многие популярные анализаторы XML на это настроены, веб-сервер вернет содержимое файла в системе, потенциально содержащего конфиденциальные данные.
Злоумышленник, разумеется, не ограничивается системными файлами. Можно легко заполучить и другие локальные файлы, включая исходный код, если известно расположение файлов на сервере или структура веб-приложения. Атаки на внешние объекты XML могут позволить злоумышленнику выполнять HTTP-запросы к файлам в локальной сети т.е. доступным только из-за брандмауэра.
Популярные уязвимости сайтов: чем опасны и как их избежать
Для любого, кто управляет веб-сайтом, на первом месте должен стоять вопрос безопасности. Критические угрозы и уязвимости могут сильно ударить как по репутации, так и по кошельку. Вместе со специалистами команды безопасности REG.RU Артёмом Мышенковым и Георгием Шутяевым рассказываем о популярных уязвимостях и способах их устранения.
В этом материале мы выделим пять популярных типов уязвимостей, с которыми может столкнуться любой веб-сайт, и поделимся способами, которые сами применяем для поиска «дыр» в безопасности, проверки сайта на уязвимости и защиты от атак.
IDOR: простая и очень опасная уязвимость
IDOR (Insecure Direct Object Reference, небезопасные прямые ссылки на объекты) — уязвимость, которая позволяет получить несанкционированный доступ к веб-страницам или файлам. Самый распространенный случай IDOR — когда злоумышленник перебирает предсказуемый идентификатор и получает доступ к чужим данным.
Лучше рассмотреть на примере. Допустим, вы зарегистрировались на сайте крупного интернет-магазина. Заполняя свои контактные данные, вы видите в строке браузера похожую ссылку:
onlinestore.ru/user/details/edit?id=39082330
Здесь главную роль играет ваш личный идентификатор (id=39082330). Эксперимента ради вы решили заменить последнюю цифру, и вдруг — попали на страницу с чужими контактными данными, которые можете редактировать.
Таким образом, просто перебирая id в URL, вы можете читать и изменять контактную информацию всех зарегистрированных пользователей. Проблема заключается в том, что при запросах к сайту он не проверяет принадлежность данных конкретному посетителю.
К чему может привести
— Разглашение конфиденциальной информации. Получив доступ к аккаунтам пользователей, злоумышленники увидят их личные данные.
— Обход аутентификации: можно получить доступ сразу к сотням или тысячам учётных записей с этой уязвимостью.
— Изменение данных: редактируя вашу контактную информацию, злоумышленник может использовать её в своих целях. Например, направить все ваши заказы в интернет-магазине к себе домой.
— Захват учётной записи. В некоторых случаях таким способом можно увести аккаунты пользователей, похитить деньги с их баланса и наделать много других неприятностей.
Как защититься
Всегда стоит помнить, что данные, поступающие в HTTP-запросе, являются недоверенными. Если ваш сайт должен отображать определённые страницы в зависимости от каких-то значений из входящих запросов, то такие запросы нужно обязательно валидировать. А именно:
— проверять, есть ли права на указанную страницу или действие;
— проверять принадлежность аккаунта или услуги авторизованному пользователю;
— использовать идентификаторы, которые невозможно предугадать или перебрать;
— использовать подпись идентификатора.
XSS: плохой сценарий
XSS — Cross Site Scripting (межсайтовое выполнение сценариев). Строго говоря, XSS — не уязвимость, а атака. Но условимся, что под XSS мы понимаем уязвимости, позволяющие проводить атаку XSS.
Когда происходит XSS-атака, в веб-страницу встраивается вредоносный код. И как только посетитель сайта откроет эту страницу, начнёт выполняться какой-либо неприятный сценарий. Чаще всего под вредоносным кодом подразумевается внедрение html-тегов или скриптов на JavaScript.
XSS бывают нескольких разновидностей:
1. Хранимые (stored). Код, который позволяет проводить атаку, постоянно находится на сервере и выполняется автоматически.
2. Отражённые (reflected). В этом случае вредоносного кода нет на самом сайте, но он содержится в заранее созданной злоумышленником веб-ссылке. Обрабатывая этот «плохой» кусок кода, сайт может ненамеренно запустить в браузере пользователя скрипт, который перехватит данные или выполнит другую «полезную нагрузку», если имеется ввиду сама нагрузка XSS.
3. DOM-based. Вариант отражённых, когда вредоносный код не отправляется на сервер, а выполняется сразу в браузере.
К чему может привести
— Перехват сессии пользователя (файлы cookies).
— Подмена страницы (например, формы ввода логина/пароля), чтобы похитить конфиденциальные данные.
— Внедрение скриптов на сайты с высокой посещаемостью (с целью рекламы, накрутки просмотров, DDoS-атак и прочего).
— Внедрение вредоносных программ на внешне безопасных сайтах.
Как защититься
— Выполняйте кодирование данных, вводимых пользователем, при выводе их на страницу.
— Если какие-то данные нельзя закодировать, защитите их дополнительной валидацией.
— Обеспечьте безопасную обработку данных, причём не только на стороне сервера, но и на стороне клиента.
SQL-инъекции
SQL-инъекция — это атака, направленная на сайт или веб-приложение, в ходе которой пользователь может обходным путём получить информацию из базы данных с помощью SQL-запросов. В случае успешной атаки пользовательские данные интерпретируются как часть SQL-кода запроса, и таким образом изменяется его логика. Как и прочие атаки, SQL-инъекция эксплуатирует уязвимости и недоработки в коде, и нужно проводить анализ сайта, чтобы найти «слабые» места.
Попробуем пояснить, что такое SQL-инъекция, на простом примере.
Как известно, большинство сайтов и веб-приложений состоят из трёх компонентов: бэкенд (код, который выполняется на сервере), фронтенд (код, который выполняется на стороне клиента, например в браузере) и база данных. Базы данных обычно состоят из множества таблиц. Скажем, если вы владеете интернет-магазином, у вас должно быть как минимум две таблицы: характеристики товаров и информация о зарегистрированных покупателях. Чтобы получать из базы информацию, например, о конкретном товаре, используется язык SQL-запросов.
Представим, что вы пришли в отдел бытовой техники (базу данных). У вас собой есть список покупок, где написано: «Один чайник за 1000 рублей». Вы даёте список продавцу, прося его принести то, что в нём указано (SQL-запрос).
В ответ на вашу просьбу продавец принесёт вам чайник — переходя к реальной жизни, отправив запрос, вы получите информацию из базы данных.
SQL-инъекция возникает, когда злоумышленник может изменить запрос к базе данных.
В примере выше SQL-инъекция бы возникла, если бы кто-то посторонний исправил ваш список покупок, например дописал в конец: «Чайник за 1000 рублей или смартфон за 30 000 рублей». Получив от вас такой запрос, продавец, видя, что смартфоны лежат гораздо ближе, чем чайники, дал бы вам смартфон — то есть то, что нужно злоумышленнику.
SQL-инъекция возможна при отсутствии фильтраций входящих параметров — хакеры могут менять их, чтобы получать нужные им данные. Уязвимыми местами в этом случае служат поля пользовательского ввода и URL-адреса, взаимодействующие с базой данных.
К чему может привести
— Утечка конфиденциальных данных (паролей, данных банковских карт и прочего).
— Внедрение вредоносного контента в уязвимые поля.
— Изменение базы данных.
— Доступ к операциям администрирования.
Как защититься
— При составлении запросов используйте плейсхолдеры (параметризированные запросы).
— Настройте белый список полей ввода.
— Отделите базу данных от логики веб-приложения.
— Используйте экранирование запросов.
Обход директорий
Обход директорий (Path traversal или Directory traversal) заключается в том, что хакер получает доступ к директориям или файлам на сервере с помощью манипуляций переменных, ссылающиеся на эти файлы. Например, для скачивания файла с сервера указывается его имя:
www.site.ru/download?file=file.pdf
С помощью символа, обозначающего директории (../), можно получить доступ к другим файлам, просто добавив его в строку:
www.site.ru/download?file=../../../etc/passwd
Если имя файла никак не валидируется, то злоумышленник сможет увидеть все файлы системы. И это очень опасно, так как важная информация (файлы конфигурации, логи и прочее) находится в заранее известных местах. Кроме того, можно читать исходный код приложения.
Уязвимость становится ещё опаснее, если помимо чтения файлов есть ещё и возможность загружать их в произвольные директории.
К чему может привести
— Несанкционированный доступ и изменение системных файлов, а также исходного кода сайта или веб-приложения.
— Удалённое выполнение вредоносного кода
— Подмена страниц сайта.
Как защититься
— Старайтесь не использовать вызовы файловой системы при пользовательском вводе.
— Если же без вызовов файловой системы не обойтись, проверяйте вводимые пользователем данные перед их обработкой. После проверки входных данных используйте API файловой системы платформы для канонизации пути. Следует убедиться, что канонизированный путь начинается с ожидаемого базового каталога.
Уязвимости при загрузке файлов
На многих сайтах пользователи могут подгружать разные файлы: например менять свою фотографию профиля или прикреплять изображения к комментариям. Если на вашем сайте доступна загрузка файлов пользователями, то нужно тщательно подойти к вопросу безопасности.
Тип файла обычно проверяется по заголовку, но такая проверка опасна, так как заголовок можно подменить. Проверки на стороне клиента тоже иногда можно обойти. И даже использование чёрного/белого списка расширений может быть неэффективным, поскольку иногда вредоносный код встраивается прямо в файл с «правильным» расширением.
К чему может привести
Злоумышленник подгрузит на сайт вредоносные скрипты, сможет «сломать» его или извлечь какие-либо данные.
Как защититься
Исчерпывающие рекомендации о том, как обезопасить загрузку файлов, есть на StackOverflow. Чек-лист посвящен PHP, однако некоторые пункты будут актуальны и для других языков:
1. запретить выполнение файлов в директории, куда они сохраняются;
2. переименовывать пользовательские файлы так, чтобы пользователь не мог повлиять на них;
3. заново сохранять картинки с помощью библиотек по редактированию изображений, чтобы удалить лишние meta-данные и возможный внедрённый в них вредоносный код.
Итак, мы рассмотрели несколько популярных уязвимостей и рассказали, как их избежать. Пишите в комментариях, хотите ли вы больше узнать о веб-безопасности и какие темы были бы наиболее интересны. Мы всегда готовы поделиться полезным опытом.
Также рекомендуем ознакомиться со статьями про безопасность сайта в нашей Базе знаний.
Уязвимости веб-приложений: под ударом пользователи
В 70% веб-сайтов есть критически опасные уязвимости, позволяющие злоумышленникам получать доступ к сайту и причинять серьёзные неприятности не только его владельцу, но и многочисленным пользователям. По средствам разработки самыми дырявыми оказались в 2015 году приложения на Java, значительно возросла доля ресурсов с уязвимостями высокой степени риска на базе серверов Microsoft IIS. При этом использование автоматизированного анализатора исходного кода позволяет выявить в 3 раза больше опасных уязвимостей, чем ручные методы анализа.
Такие выводы содержатся в исследовании компании Positive Technologies на основе статистики, собранной в ходе работ по анализу защищенности веб-приложений в 2015 году. Сравнение с данными аналогичных исследований 2014 и 2013 годов дает возможность оценить динамику развития современных веб-приложений с точки зрения ИБ. В данной статье представлены основные результаты исследования.
Источники и методика
Ежегодно специалисты Positive Technologies изучают около 250—300 веб-приложений в рамках различных работ, начиная от инструментального сканирования и заканчивая анализом исходного кода. По итогам выполненных проектов в 2015 году было выделено 30 веб-приложений, для которых проводился углубленный анализ с наиболее полным покрытием проверок. При этом учитывались только те уязвимости, которые были подтверждены путем проведения проверок на тестовом стенде.
Оценка защищенности проводилась методами черного, серого и белого ящиков — как вручную (с использованием вспомогательных автоматизированных средств), так и с помощью автоматизированного анализатора кода. Метод черного ящика означает исследование сайта от лица внешнего атакующего без дополнительной информации о системе со стороны владельца. Метод серого ящика аналогичен методу черного ящика, но в качестве нарушителя рассматривается пользователь, обладающий определенными привилегиями в системе. Метод белого ящика использует все необходимые данные о системе, включая исходный код приложений.
В настоящей статистике приведены только уязвимости, связанные с ошибками в коде и конфигурации веб-приложений. Уязвимости классифицировались согласно угрозам по WASC TC v. 2, за исключением категорий Improper Input Handling и Improper Output Handling, поскольку они реализуются в рамках множества других атак. Степень риска уязвимостей оценивалась согласно CVSS v. 2.
Исследованные приложения принадлежали компаниям, представляющим телекомы (23%), промышленность (20%), СМИ (17%), IT-компании (17%), финансы (13%) и государственные организации (10%).
Большинство веб-приложений, вошедших в выборку, разработаны на Java (43%) и PHP (30%), также встречались приложения, созданные с использованием технологий ASP.NET, Perl, ABAP, 1С и других. Приложения работали под управлением серверов Nginx (34%), Microsoft IIS (19%), Apache Tomcat (14%) и WebLogic (14%), а также под Apache и SAP NetWeaver Application Server. Примерно половина исследованных ресурсов (53%) представляли собой продуктивные системы, уже доступные пользователям через интернет, вторую половину составляли тестовые площадки, находящиеся в процессе разработки или приемки в эксплуатацию.
Самые популярные уязвимости
Недостатки как минимум среднего уровня риска были обнаружены во всех исследованных приложениях. При этом в 70% рассмотренных систем были обнаружены критически опасные уязвимости. В течение последних трех лет доля таких систем растет: в 2014 году их было 68%, в 2013 – только 61%.
Большинство исследованных приложений позволяют атаковать пользователей. В коде 80% ресурсов обнаружена уязвимость среднего уровня риска «Межсайтовое выполнение сценариев» (Cross-Site Scripting, XSS). В результате эксплуатации данной уязвимости злоумышленник может внедрить в браузер пользователя произвольные HTML-теги, включая сценарии на языке JavaScript и других языках, и таким образом получить значение идентификатора сессии атакуемого и совершить иные неправомерные действия, например фишинговые атаки.
На втором месте — утечка информации (Information Leakage): уязвимость обнаружена в каждом втором веб-приложении. 47% веб-сайтов также содержат уязвимости, связанные с отсутствием защиты от подбора учетных данных (Brute Force). Наиболее распространенным недостатком высокого уровня риска в 2015 году стала уязвимость «Внедрение внешних сущностей XML» (XML External Entities). Уязвимость позволяет злоумышленнику получить содержимое файлов, расположенных на атакуемом сервере, либо совершать запросы в локальную сеть от имени атакуемого сервера.
Средства разработки: Java не лучше PHP
В исследованиях прошлых лет PHP-приложения как правило были более уязвимы, чем системы, разработанные с помощью ASP.NET и Java. Однако на сегодняшний день картина изменилась: 69% Java-приложений подвержены критически опасным уязвимостям, а для PHP-систем данный показатель составил 56%, что ниже уровня 2013 года на 20%.
Каждое веб-приложение на PHP в среднем содержит 9,1 критически опасных уязвимостей, приложение на Java — 10,5. Для всех других языков программирования и средств разработки в среднем на каждую систему приходится лишь 2 критически опасные уязвимости.
Уязвимость «Межсайтовое выполнение сценариев» оказалась наиболее распространенной для всех языков программирования. Доля приложений, подверженных уязвимости «Внедрение операторов SQL», сократилась по сравнению с 2014 годом: тогда уязвимость была выявлена в 67% веб-ресурсов, разработанных на PHP, а сейчас встречается только в 22%.
Дырявые сервера на Microsoft IIS
Доля ресурсов с уязвимостями высокой степени риска на базе Microsoft IIS значительно возросла по сравнению с предыдущими годами и достигла максимального значения. Зато доля уязвимых сайтов под управлением Nginx снизилась (с 86% до 57%), тоже самое с Apache Tomcat (с 60 до 33%).
Веб-приложения с уязвимостями высокой степени риска (по типу веб-сервера)
Для большинства веб-серверов самой распространенной ошибкой администрирования является утечка информации. Данный недостаток был обнаружен во всех исследованных приложениях под управлением серверов Microsoft IIS. На втором месте — отсутствие защиты от подбора учетных данных.
Сайты банков и IT-компаний под угрозой
Как и в пошлом году, на всех банковских сайтах обнаружены критически опасные уязвимости. Аналогичная ситуация наблюдается в сфере IT. Положительная динамика отмечена лишь для приложений промышленных и телекоммуникационных компаний.
Доли приложений с уязвимостями высокого уровня риска для различных отраслей экономики
Рабочие системы защищены ненамного лучше тестовых
Доля уязвимых приложений, уже находящихся в эксплуатации, очень велика: более половины (63%) подвержены критически опасным уязвимостям. Такие недостатки могут позволить нарушителю получить полный контроль над системой (например, в случае загрузки произвольных файлов или выполнения команд), а также получать чувствительную информацию (например, в результате эксплуатации уязвимостей «Внедрение операторов SQL», «Внедрение внешних сущностей XML» и других). Также нарушитель может проводить успешные атаки типа «отказ в обслуживании».
Максимальный уровень риска обнаруженных уязвимостей для тестовых и продуктивных систем (доли уязвимых систем)
Анализ исходного кода лучше выявляет опасные уязвимости
Доля систем, подверженных критически опасным уязвимостям, которые были обнаружены методом черного ящика, существенно ниже, чем аналогичный показатель для сайтов, где анализировали исходные коды приложения. Однако даже для метода черного и серого ящика доля систем с опасными уязвимостями довольно велика (59%). Таким образом, отсутствие у атакующего доступа к исходным кодам не делает веб-приложения защищенными.
Доли систем с уязвимостями разной степени риска по методу тестирования
При этом среднее количество уязвимостей различного уровня риска на одну систему, выявленных методом белого ящика, существенно выше, чем при тестировании методами черного и серого ящиков.
Среднее количество обнаруженных уязвимостей на одну систему
В рамках исследования было также проведено сравнение результатов работ, осуществленных методом белого ящика вручную либо с использованием автоматизированного сканера. В среднем в каждой системе выявлено около 15 критически опасных уязвимостей в случае использования анализатора кода (учитывались только подтвержденные уязвимости), и всего 4 уязвимости — ручными методами.
Среднее количество выявленных уязвимостей определенного уровня риска на одну систему разными методами
Таким образом, анализ защищенности методом белого ящика существенно эффективнее других методов, при которых не анализируется исходный код приложения. При этом автоматизированный анализ кода оказывается достаточно эффективным, особенно если учесть объемы кода современных приложений, где используется множество библиотек.
В целом полученные данные свидетельствуют о необходимости регулярно проводить работы по анализу защищенности веб-приложений. Важно осуществлять такой анализ на всех стадиях разработки, а также регулярно (например, дважды в год) в процессе эксплуатации систем. Кроме того, приложения, уже находящихся в эксплуатации, нуждаются в эффективной защите от атак: более половины таких ресурсов (63%) оказались подвержены критически опасным уязвимостям. Эти недостатки могут привести не только к разглашению важных данных, но и к полной компрометации системы, либо выводу ее из строя. Для защиты от таких атак рекомендуется применять межсетевые экраны уровня приложений.