Т.е. базовый XSS-фильтр обрабатывает исходящий запрос, сначала проверяя, где был сгенерирован запрос. Я имею в виду, что для отражающего XSS запрос может генерироваться из системы злоумышленников, чтобы поставить вредоносный скрипт. Так по расширению
не должно быть смысла смотреть на запросы, исходящие из того же домена, так как это будет пустой тратой ресурсов.
Однако IE делает неверное предположение, XSS может прийти откуда угодно и для любого
отражающая XSS уязвимость может стать эксплуатируемой из-за этого неверного предположения. IE принял во внимание перенаправления заголовка HTTP «location:», а также
мета-обновление HTML-тегов. Однако есть и другие способы перенаправления, которые можно использовать при атаке.
Теперь давайте предположим, что в нашем целевом приложении, обнаруженном в
Файл xss.php:
<?php
//xss.php
print $_GET['var'];
?>
Предположим, что в файле redir.php обнаружено нарушение OWASP a10.
<?php
//redir.php
print “<script>”;
print “document.location='”.htmlspecialchars($_GET['redir'],ENT_QUOTES).”'”;
print “</script>”;
?>
Эксплойт Proof of Concept для такого приложения выглядит следующим образом:
http://abc.com/redir.php?redir=http%3A%2F%2Fabc.com%2Fxss.php%3Fvar%3D%253Cscript
%253Ealert%2528%2Fxss%2F%2529%253C%2Fscript%253E
Указанная выше ссылка может исходить из любого места, включая службы сокращения URL-адресов. Полезная нагрузка XSS - это переменная GET «var». Эта часть PoC была закодирована с двойным URL. Там для угловой скобки «>» становится «% 253E». Это кодирует дураков как htmlspecialchars () на сервере, так и фильтр IE. Эта кодированная полезная нагрузка не зависит от вызова htmlspecialchars () и будет вести себя так же, как и при его отсутствии.