Наиболее распространённые уязвимости сайтов: обзор отчётов Qualys

Наиболее распространённые уязвимости сайтов: обзор отчётов Qualys

Сканеры для поиска уязвимостей в веб-приложениях помогают быстро определить уровни защищённости сайтов. Мы обобщили статистику сканера Qualys за год использования в сервисе DataLine и выделили чаще всего обнаруживаемые проблемы веб-приложений. О том, какие из них наиболее опасны и как избежать рисков, — в нашем обзоре.

 

 

 

 

 

  1. Введение
  2. Низкий уровень значимости
    1. 2.1. Используется смешанное содержимое (Active / Passive mixed content)
    2. 2.2. Файлы сookie не содержат атрибутов «HTTPOnly» и «secure»
    3. 2.3. Уязвимости пути (Path-based vulnerabilities)
    4. 2.4. Формы включают автозаполнение для конфиденциальной информации (Sensitive form field has not disabled autocomplete)
    5. 2.5. Не используется заголовок X-Frame-Options (X-Frame-Options header is not set)
    6. 2.6. Используются относительные ссылки для обращения к стилям сайта (Path-relative stylesheet import)
  3. Средний уровень значимости
    1. 3.1. Используются JavaScript-библиотеки с известными уязвимостями (Use of JavaScript library with known vulnerability)
    2. 3.2. Страница с полем для пароля передаётся с сервера по незащищённому каналу (HTML form containing password field(s) is served over HTTP)
  4. Высокий уровень значимости
    1. 4.1. Формы с логином и паролем отправляются по незащищённому каналу (Login form is not submitted via HTTPS)
    2. 4.2. Межсайтовые скрипты (Path-based / Reflected cross-site scripting (XSS))
    3. 4.3. SQL-инъекции
  5. Выводы

 

Введение

С прошлого года клиенты DataLine пользуются сервисом на базе облачного сканера уязвимостей Qualys. За год по запросам клиентов мы проанализировали 122 сайта и выделили наиболее распространённые угрозы в веб-приложениях. Многие из этих уязвимостей не воспринимаются всерьёз, так как на первый взгляд требуют от взломщиков изобретательности и удачи. Но несколько уязвимостей одновременно могут привести к опасным комбинациям, и с их помощью можно нанести ущерб пользователям приложений.

Уязвимости в отчётах Qualys распределяются по уровням значимости: низкий, средний и высокий. Большинство найденных проблем относят к низкому уровню значимости / опасности.

 

Рисунок 1. Распределение найденных нами угроз по уровню значимости

 Распределение найденных нами угроз по уровню значимости

 

«Низкий» — не всегда безобидный. Рассмотрим подробнее, какие уязвимости часто встречаются в каждой категории, какие опасности это несёт и как защитить свой сайт.

 

Низкий уровень значимости

1. Используется смешанное содержимое (Active / Passive mixed content)

Предупреждения о смешанном контенте появляются, если часть содержимого передаётся через незащищённый HTTP. Разработчик сайта узнаёт об этом в консоли браузера. Новые браузеры сразу блокируют такой контент, но пользователи старых версий могут подвергаться риску.

 

Рисунок 2. Пример предупреждения о блокировке смешанного содержимого в консоли разработчика Mozilla Firefox

 Пример предупреждения о блокировке смешанного содержимого в консоли разработчика Mozilla Firefox

 

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

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

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

Что можно сделать:

  1. Убедиться, что уязвимость не возникает из-за человеческого фактора. Например, такое случается, когда в коде сайта ставят абсолютные ссылки с HTTP и при этом не настраивают автоматические редиректы на HTTPS.
  2. Проверить исходный код на смешанный контент. Если ручная проверка в браузере занимает много времени, есть сервисы для автоматического анализа: SSL Check, свободно распространяемое ПО Lighthouse или платный Screaming Frog SEO Spider.
  3. Если сайт старый — проверить, не используются ли для страниц старые шаблоны. В этом случае ссылки с HTTP могут генерироваться автоматически.

 

2. Файлы сookie не содержат атрибутов «HTTPOnly» и «secure»

Идентификационные файлы браузера (cookies) c атрибутами «HTTPOnly» и «secure» позволяют защитить данные пользователей от кражи. Атрибуты задают в свойствах:

Set-Cookie: Secure; HttpOnly

Таким способом можно запретить передачу файлов cookie по небезопасному протоколу и защитить файлы от сторонних скриптов. Без этих атрибутов пользовательские данные могут оказаться в руках мошенников. Например, можно «угнать» пользовательскую сессию, если cookies применяются для авторизации и аутентификации.

Что можно сделать:

  1. Использовать популярные фреймворки, где эти атрибуты прописываются автоматически.
  2. Проверить, не отключены ли эти атрибуты сознательно. В частности, если файлы cookie обрабатываются скриптами самого сайта, «HTTPOnly» приходится отключать. Здесь нужно оценить баланс между безопасностью и функциональностью.

 

3. Уязвимости пути (Path-based vulnerabilities)

Сообщение об этой уязвимости появляется, если сканер находит в публичном доступе файлы с предположительно конфиденциальными данными. Например, подозрения вызывают имена публичных файлов типа «config». Такой симптом может означать, что на сайте неверно настроены права доступа.

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

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

 

4. Формы включают автозаполнение для конфиденциальной информации (Sensitive form field has not disabled autocomplete)

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

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

Что можно сделать:

  1. Для всех браузеров, кроме 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>
  1. Для 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). При нажатии на кнопку щелчок перехватывается, и от имени пользователя действия совершаются на оригинальном сайте. Например, так мошенники могут накручивать «клики» в реферальной программе.

Что можно сделать:

  1. Убедиться, что в настройках сервера и балансировщика нагрузки не задан X-Frame Options с конфликтующим значением. Иначе заголовок просто перепишется.
  2. Чтобы 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

 Пример эксплойта для уязвимости jQuery

 

Что можно сделать:

  1. Проверить, какие проблемы безопасности уже обсуждались для используемой библиотеки.
  2. Найти локальные решения для устранения уязвимостей.

 

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:

  1. Хранимые — внедряются на сервер и выполняются при каждом обращении клиента к атакованной странице.
  2. Отражённые — внедряются в HTTP-запрос. Злоумышленник перехватывает трафик и вставляет скрипт типа
<script>/*+что+то+плохое+*/</script>

В этом случае от имени клиента уйдёт вредоносный запрос.

Что можно сделать:

  1. Добавить атрибут «script-src» в заголовке «Content-Security-Policy». В этом случае браузер пользователя будет выполнять код только из доверенных источников. Можно оставить в белом списке только собственный сайт с помощью «script-src 'self' www.example.com».
  2. Протоколировать действия с помощью «report-uri» и отслеживать попытки внедрения в сайт.

 

3. SQL-инъекции

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

Что можно сделать:

  1. В первую очередь — защититься на стороне сервера. Рекомендуется использовать параметризованные запросы к базам данных. Также лучше придерживаться популярных фреймворков, где уже есть встроенные функции для экранирования подозрительных символов.
  2. На стороне клиента написать проверки данных с помощью 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.
Полезные ссылки: 
Anti-Malware TelegramПодписывайтесь на канал "Anti-Malware" в Telegram, чтобы первыми узнавать о новостях и наших эксклюзивных материалах по информационной безопасности.

RSS: Новые статьи на Anti-Malware.ru