Сканеры для поиска уязвимостей в веб-приложениях помогают быстро определить уровни защищённости сайтов. Мы обобщили статистику сканера Qualys за год использования в сервисе DataLine и выделили чаще всего обнаруживаемые проблемы веб-приложений. О том, какие из них наиболее опасны и как избежать рисков, — в нашем обзоре.
- Введение
- Низкий уровень значимости
- 2.1. Используется смешанное содержимое (Active / Passive mixed content)
- 2.2. Файлы сookie не содержат атрибутов «HTTPOnly» и «secure»
- 2.3. Уязвимости пути (Path-based vulnerabilities)
- 2.4. Формы включают автозаполнение для конфиденциальной информации (Sensitive form field has not disabled autocomplete)
- 2.5. Не используется заголовок X-Frame-Options (X-Frame-Options header is not set)
- 2.6. Используются относительные ссылки для обращения к стилям сайта (Path-relative stylesheet import)
- Средний уровень значимости
- 3.1. Используются JavaScript-библиотеки с известными уязвимостями (Use of JavaScript library with known vulnerability)
- 3.2. Страница с полем для пароля передаётся с сервера по незащищённому каналу (HTML form containing password field(s) is served over HTTP)
- Высокий уровень значимости
- 4.1. Формы с логином и паролем отправляются по незащищённому каналу (Login form is not submitted via HTTPS)
- 4.2. Межсайтовые скрипты (Path-based / Reflected cross-site scripting (XSS))
- 4.3. SQL-инъекции
- Выводы
Введение
С прошлого года клиенты DataLine пользуются сервисом на базе облачного сканера уязвимостей Qualys. За год по запросам клиентов мы проанализировали 122 сайта и выделили наиболее распространённые угрозы в веб-приложениях. Многие из этих уязвимостей не воспринимаются всерьёз, так как на первый взгляд требуют от взломщиков изобретательности и удачи. Но несколько уязвимостей одновременно могут привести к опасным комбинациям, и с их помощью можно нанести ущерб пользователям приложений.
Уязвимости в отчётах Qualys распределяются по уровням значимости: низкий, средний и высокий. Большинство найденных проблем относят к низкому уровню значимости / опасности.
Рисунок 1. Распределение найденных нами угроз по уровню значимости
«Низкий» — не всегда безобидный. Рассмотрим подробнее, какие уязвимости часто встречаются в каждой категории, какие опасности это несёт и как защитить свой сайт.
Низкий уровень значимости
1. Используется смешанное содержимое (Active / Passive mixed content)
Предупреждения о смешанном контенте появляются, если часть содержимого передаётся через незащищённый HTTP. Разработчик сайта узнаёт об этом в консоли браузера. Новые браузеры сразу блокируют такой контент, но пользователи старых версий могут подвергаться риску.
Рисунок 2. Пример предупреждения о блокировке смешанного содержимого в консоли разработчика Mozilla Firefox
Уязвимости возникают в двух случаях. Во-первых, если по HTTP передаётся пассивное содержимое: изображения и стили сайта. Недоброжелатель может перехватить эту информацию и узнать больше о посетителе. Также перехваченный контент можно подменить, например показать пользователю непристойные фотографии.
Во-вторых, некоторые сайты передают по HTTP и активное содержимое, то есть скрипты. Такая уязвимость позволяет с помощью специального ПО анализировать ответы с сервера и подменять JavaScript. После такой модификации сайт может функционировать не так, как задумано. В итоге посетители не застрахованы от выуживания данных мошенническими способами, то есть фишинга.
Мошенник может создать сайт, похожий на оригинал, и подставить свой скрипт на исходную страницу для перенаправления посетителей. Если пользователь не заподозрит подмены, он сам заполнит форму на мошенническом сайте.
Что можно сделать:
- Убедиться, что уязвимость не возникает из-за человеческого фактора. Например, такое случается, когда в коде сайта ставят абсолютные ссылки с HTTP и при этом не настраивают автоматические редиректы на HTTPS.
- Проверить исходный код на смешанный контент. Если ручная проверка в браузере занимает много времени, есть сервисы для автоматического анализа: SSL Check, свободно распространяемое ПО Lighthouse или платный Screaming Frog SEO Spider.
- Если сайт старый — проверить, не используются ли для страниц старые шаблоны. В этом случае ссылки с HTTP могут генерироваться автоматически.
2. Файлы сookie не содержат атрибутов «HTTPOnly» и «secure»
Идентификационные файлы браузера (cookies) c атрибутами «HTTPOnly» и «secure» позволяют защитить данные пользователей от кражи. Атрибуты задают в свойствах:
Set-Cookie: Secure; HttpOnly
Таким способом можно запретить передачу файлов cookie по небезопасному протоколу и защитить файлы от сторонних скриптов. Без этих атрибутов пользовательские данные могут оказаться в руках мошенников. Например, можно «угнать» пользовательскую сессию, если cookies применяются для авторизации и аутентификации.
Что можно сделать:
- Использовать популярные фреймворки, где эти атрибуты прописываются автоматически.
- Проверить, не отключены ли эти атрибуты сознательно. В частности, если файлы cookie обрабатываются скриптами самого сайта, «HTTPOnly» приходится отключать. Здесь нужно оценить баланс между безопасностью и функциональностью.
3. Уязвимости пути (Path-based vulnerabilities)
Сообщение об этой уязвимости появляется, если сканер находит в публичном доступе файлы с предположительно конфиденциальными данными. Например, подозрения вызывают имена публичных файлов типа «config». Такой симптом может означать, что на сайте неверно настроены права доступа.
В худшем случае недоброжелатель может воспользоваться некорректными настройками, чтобы найти папки с пользовательскими логинами и паролями, или попытается добраться до управляющего интерфейса сайта, повысить свои привилегии и проникнуть вглубь инфраструктуры.
Что можно сделать: Конфигурировать платформу, веб-сервер, веб-приложение таким образом, чтобы нельзя было выйти за пределы разрешённых директорий.
4. Формы включают автозаполнение для конфиденциальной информации (Sensitive form field has not disabled autocomplete)
Посетители интернет-магазинов ценят автозаполнение форм за скорость оформления заказов. Например, с помощью этой функции браузер запоминает адрес доставки, чтобы клиенту не приходилось вводить данные каждый раз.
Пользователь может сам управлять этими возможностями в браузере и решать, какую информацию и для каких сайтов хранить. Однако специалисты по безопасности рекомендуют разработчикам явно отключить автозаполнение для полей с паролями, платёжными реквизитами и другой конфиденциальной информацией. Это снизит риск кражи пользовательских данных с помощью фишинга.
Что можно сделать:
- Для всех браузеров, кроме Chrome, отключить автозаполнение конфиденциальных данных с помощью параметра «autocomplete="off"»:
<body><form action="/form/submit" method="get" autocomplete="off">
<div>
<input type="text" placeholder="First Name">
</div>
<div>
<input type="text" id="lname" placeholder="Last Name" autocomplete="on">
</div>
<div>
<input type="number" placeholder="Credit card number">
</div>
<input type="submit">
</form>
</body>
- Для Chrome использовать JavaScript — например, как здесь.
5. Не используется заголовок X-Frame-Options (X-Frame-Options header is not set)
X-Frame Options влияет на теги <frame>, <iframe>, <embed> и <object>. Значение «deny» запрещает встраивать сайт внутрь фрейма. «X-Frame-Options: sameorigin» разрешит встраивание во фрейм только на том же домене, где находится сайт. Если заголовок не задан, мошенники могут разместить прозрачный фрейм с кнопкой чужого приложения поверх своего сайта, чтобы обмануть посетителей. Такая атака известна как «кликджекинг» (clickjacking). При нажатии на кнопку щелчок перехватывается, и от имени пользователя действия совершаются на оригинальном сайте. Например, так мошенники могут накручивать «клики» в реферальной программе.
Что можно сделать:
- Убедиться, что в настройках сервера и балансировщика нагрузки не задан X-Frame Options с конфликтующим значением. Иначе заголовок просто перепишется.
- Чтобы X-Frame Options не мешал работе вебвизора «Яндекса», нужно создать отдельное правило. К примеру, такие настройки можно задать для nginx:
http{ ...
map $http_referer $frame_options {
"~webvisor.com" "ALLOW-FROM webvisor.com";
default "SAMEORIGIN";
}
add_header X-Frame-Options $frame_options;
...
}
6. спользуются относительные ссылки для обращения к стилям сайта (Path-relative stylesheet import)
Подгрузка файлов CSS в виде относительных ссылок типа «href="/somefolder/styles.css/"» в отдельных случаях позволяет совершать вредоносные действия под видом обращения к стилям. Для этого мошенник находит способ перевести пользователя на свой сайт. Вредоносная страница подставит относительную ссылку в свой URL и сформирует запрос вида «badsite.ru/.../somefolder/styles.css/». Под видом обращения к стилям могут украсть токены или пользовательские файлы cookie.
Что можно сделать: Прописать в заголовке «X-Content-Type-Options: nosniff». Браузер будет проверять, какой тип контента используется для стилей, и блокировать запросы для подозрительных случаев.
Средний уровень значимости
1. Используются JavaScript-библиотеки с известными уязвимостями (Use of JavaScript library with known vulnerability)
За время сканирования Qualys чаще всего обнаруживал библиотеки jQuery с одной или несколькими уязвимостями. Проблема заключается в том, что для известных уязвимостей есть эксплойты — готовые фрагменты кода для эксплуатации «дыр» в безопасности.
Рисунок 3. Пример эксплойта для уязвимости jQuery
Что можно сделать:
- Проверить, какие проблемы безопасности уже обсуждались для используемой библиотеки.
- Найти локальные решения для устранения уязвимостей.
2. Страница с полем для пароля передаётся с сервера по незащищённому каналу (HTML form containing password field(s) is served over HTTP)
Если ответ от сервера передаётся по нешифрованному каналу, то возможна MITM-атака, или «атака посредника» (Man-in-the-Middle). Мошенник может вклиниться между сервером и клиентом и подменить страницу, которую получит пользователь.
Что можно сделать: проверить настройки SSL- / TLS-сертификата.
Высокий уровень значимости
1. Формы с логином и паролем отправляются по незащищённому каналу (Login form is not submitted via HTTPS)
В отличие от предыдущей уязвимости, в этом случае по нешифрованному каналу отправляется форма с данными для входа в учётную запись. Мошеннику оказывается ещё проще перехватить пользовательские данные.
Что можно сделать: проверить настройки SSL- / TLS-сертификата.
2. Межсайтовые скрипты (Path-based / Reflected cross-site scripting (XSS))
Если в код веб-приложения можно внедрить вредоносный JS-скрипт, то сканер уязвимостей предупреждает об угрозе межсайтового исполнения сценариев. Встречаются два вида XSS:
- Хранимые — внедряются на сервер и выполняются при каждом обращении клиента к атакованной странице.
- Отражённые — внедряются в HTTP-запрос. Злоумышленник перехватывает трафик и вставляет скрипт типа
<script>/*+что+то+плохое+*/</script>
В этом случае от имени клиента уйдёт вредоносный запрос.
Что можно сделать:
- Добавить атрибут «script-src» в заголовке «Content-Security-Policy». В этом случае браузер пользователя будет выполнять код только из доверенных источников. Можно оставить в белом списке только собственный сайт с помощью «script-src 'self' www.example.com».
- Протоколировать действия с помощью «report-uri» и отслеживать попытки внедрения в сайт.
3. SQL-инъекции
Инъекции возможны в том случае, если злоумышленник способен прямо с сайта отправить SQL-запрос и обратиться к базе данных. Например, так бывает, если в формах на сайте данные от пользователя не экранируются — не проверяются на правильность до отправки запроса на сервер.
Что можно сделать:
- В первую очередь — защититься на стороне сервера. Рекомендуется использовать параметризованные запросы к базам данных. Также лучше придерживаться популярных фреймворков, где уже есть встроенные функции для экранирования подозрительных символов.
- На стороне клиента написать проверки данных с помощью JavaScript.
Выводы
Общие рекомендации для защиты от уязвимостей:
- Использовать для разработки проверенные фреймворки. Для .NET это — ASP.NET MVC и ASP.NET Core, для Python — Django или Flask, для Ruby — Ruby on Rails, для PHP — Symfony, Laravel, Yii, для JavaScript — Node.js и Express.js, для Java — Spring MVC.
- Следить за обновлениями. Подписка на обновления до стабильных версий от вендора ПО может спасти от атак с помощью эксплойтов.
- Проверять права доступа на сервере.
- Использовать клоны и тестовые площадки для поиска уязвимостей. Проверку функциональности и поиск новых уязвимостей рекомендуется проводить в тестовой среде.
- Защищать приложения с помощью сетевого экрана веб-приложений (Web Application Firewall, WAF). Дополнительно можно интегрировать отчёты сканера уязвимостей. Например, в DataLine в качестве связки сервисов используются Qualys и FortiWeb.
