Operation n

[Hotlinking] is the placing of a linked object, often an image, from one site into a web page belonging to a second site. The second site is said to have an inline link to the site where the object is located. Inline linking is also known as hotlinking, leeching, direct linking or bandwidth theft - wikipedia

Hotlinking has been around for ages, and the attack vector shown in this paper is not new either; I merely take two known attacks and merge them to create a super dangerous client side attack that is persistent!

I released the Web Hacking 2.0 mindmap at the beginning of this year (2007). Someone from the Phoenix OWASP chapter liked the idea and posted it on owasp.org. I have no problem with this, although an email saying how and where my work was to be used would have been nice. Enough of that, the point here is to demonstrate the concept of exploiting hotlink trust relationships. This is the primary problem with hotlinking. Site 1 is creating bandwidth problems for Site 2, however, Site 2 is now in a position of trust (persistent).

Two possible attacks are as follows:

• Attack 1: We deface the page with a lovely picture of stallowned
• Attack 2: We setup a 302 or 304 redirect on my web server with the image filename used on the site who’s trust we are exploiting. The redirect exploits a CSRF vulnerability. Everytime the page is loaded, the CSRF attack is executed. This is now persistent! Everytime a user loads the Site 1, our CSRF attack is executed.

Lets take this concept a little further. If the site is hotlinking an object or iframe type, it is now possible to turn a reflective XSS attack into a persistent XSS attack. For this attack we require both a reflective XSS vulnerability and a hotlink. What’s really neat and tidy is that an attacker can display the correct object after exploitation, remaining completely invisible to the user.

Our malicious redirects are as follows:

Redirect 302 /a.jpg http://www.owasp.org/index.php?title=Special:Userlogout
&returnto=http://michaeldaw.org
OR
Redirect 302 ^/flashobj.swf$ http://site/trusted.html?<script>alert(1)
</script>

This attack concept is a security catastrophe especially when taking Web 2.0 which is designed around this form of trust.

In summary, don’t hotlink. Rather download the file onto your local server, although with Web 2.0, this will become increasingly difficult.

Web servers can enable hotlinking protection to prevent this; however, since alot of browsers now restrict the referrer field, this security method will not really help.

Thanks to pdp (architect) for allowing me to bounce ideas off him.

References:

• XSS IMG CSRF_2