Accept Header Might Help CSRF If Expanded Upon
This morning I got into a fairly long winded offline conversation with Huib about how to protect against CSRF in homegrown BBCode. I’ve always thought of BBcode as obfuscation and not an actual security measure. But anyway, we got onto the topic of cross site request forgeries and how they could be used in context of an image to force users to perform actions upon viewing a bulletin board.
He confused me by saying he could detect CSRF through headers. After several exchanges I finally figured out what he was saying, and it’s interesting, although has serious issues. Here is what he was seeing. In Firefox what he was able to detect was that a user had tried to request a .php file while inside of an IMG tag:
GET /img.jpg HTTP/1.0
Host: ha.ckers.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Accept: image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://whatever.com/webboard/
Pragma: no-cache
However, if the image is located on my server all I need to do is throw up a 301 redirect back to his function like so:
Redirect 301 /img.jpg http://yourserver/yourfunction.php?malicious
Now, after the redirection the header looks like:
GET /yourfunction.php?malicious HTTP/1.0
Host: yourserver
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Accept: application/x-shockwave-flash,text/xml,application/xml,
application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,
*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://whatever.com/webboard/
Pragma: no-cache
So, as we can see, you can’t make a prediction upon the intent of the browser (to load an image) by the headers. Internet Explorer is even worse by always requesting the same thing, however, there is an interesting point here. Although this didn’t actually work, there’s no reason the browser couldn’t handle this properly. As the Referer header stays the same, there’s no reason you couldn’t require the same of the redirection. Why would an image be redirected as a HTML file legitimately (aside from perhaps an error condition)? And even so that shouldn’t change the server output unless the function is intented to be secured.
In this way, you could perhaps change a browser to accurately identify certain conditions where CSRF was not allowed. Of course things like Flash header spoofing and XMLHttpRequest throw a wrench into the mix, but both of those actually require full HTML injection as opposed to a simple image link which is highly prevolant on websites. Obviously I haven’t put enough thought into this but it’s an interesting possible enhancement to handle a problem for which I’ve seen very few mitigation efforts identified.
October 1st, 2006 at 10:54 am
One of my readers just sent me an email with another option… simply by requiring a post method you can do this same thing without the same limitations. Good idea… it has the same issues as the above example does if full XSS is allowed or you can get someone to visit another website using CSRF, but it will slow the attacker down considerably.