This blog is all about Cyber Security and IT

Showing posts with label HTTP Cache Poisoning. Show all posts
Showing posts with label HTTP Cache Poisoning. Show all posts

Wednesday, April 22, 2020

XSS found using host header injection


This vulnerability arise when you give any input to the host parameter and it may reflect back .

 Impact

An attacker can use the vulnerability to construct a request that, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.

Real World Example:

Path : /billing-admin/profile/subscription/?l=de
Payload : c5obc'+alert(1)+'p7yd5
Steps to reproduce :
Request Header :
GET /billing-admin/profile/subscription/?l=de HTTP/1.1
Host: www.semrush.com
Accept: /
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Referer: http://www.google.com/search?hl=en&q=c5obc'+alert(1)+'p7yd5
Overview :
The payload c5obc'+alert(1)+'p7yd5 was submitted in the Referer HTTP header. Payload is copied from a request and echoed into the application's immediate response in an unsafe way.


In the above example the payload reflect back in the response causing the rise of the vulnerability.

HTTP Cache Poisoning via Host Header Injection



Vulnerability:

Rewriting of links and URLs in cached pages to arbitrary strings by unauthenticated HTTP clients.When the application reflects HTTP Header value back in it's response and it may be possible to poison the server cache. The X-Forwarded-Host is directly reflected as a hyperlink. Than Host Header Attack - Cache Poisoning vulnerability may be there like:

Affected software: ANY site that does not validate HTTP Host: headers.

It is common practice for web programmers and web frameworks to rely on the value of the HTTP Host header to write links. This is for convenience, so that the same software will run on localhost, various testing servers, subdomains, secondary domains, etc, without modification. For example:

<a href="<?=$_SERVER['HTTP_HOST']?>/login">Login</a>

This turns out to be a very, very bad idea in any language. The HTTP Host header is arbitrary text controlled by the client, but common practice treats it as though it were a safe environment variable.

HTTP Request

GET / HTTP/1.1
Host: davindertutorials.com
X-Forwarded-Host: test.com
...
....

HTTP Response

HTTP/1.1 200 OK
....
....
....
<li class="SL_hide" title="Get New Relic on your iPad, iPhone, or Android phone"><a href="http://test.com/mobility">New Relic for iOS & Android</a></li>
....

Now as you see we are able to see test.com in the response.

Mitigation: DO NOT use the value of the Host header for anything. If you must, apply very strict filters to only allow valid FQDNs, and then whitelist the FQDNs you allow. Treat it as you would any arbitrary data coming from the outside. If your webserver is configured to output the value of the Host header (as in the example, and as by default in many webservers), disable that configuration.