CRSF in Google
This is probably more amusing than anything. Click here to change your language preference from whatever it is now to Irish Gaelic. Highly useful language, I might add - but this was blogged by Philipp Lenssen describing the pretty innocuous setting change through a cross site request forgery.
While I don’t think this particular setting change is particularly devious, it is amusing and could have some unintended side effects on high volume websites where it was embedded in an image or a hidden iframe. Cross site request forgeries are really a fairly nasty attack, using the person’s own browser against itself. I have a feeling many more websites will be found to be vulnerable to this - in fact I’m sitting on a pretty nasty disclosure at the moment, that I’ll be vetting sometime this week after some testing.
September 25th, 2006 at 6:20 pm
Have you considered collecting all of the various CSRF cases you’ve encountered? I imagine a CSRF cheatsheet could be very useful, illustrating various techniques:
1. Embedded resources, where the src attribute points to the URL that you want victims to request.
2. Hidden IFrames that submit a form using a method of POST.
3. Regular JavaScript to submit a POST, not using IFrames. (Not generally as useful as using an IFrame, but sometimes useful to have the target URL rendered and not hidden.)
4. Using XSS as a platform, so that Ajax techniques can be used to gather any one-time token being used to protect against CSRF.
I’m sure we could think of a dozen more with a bit of brainstorming.
September 25th, 2006 at 6:22 pm
5. http://shiflett.org/archive/263
September 26th, 2006 at 2:21 am
Is that really a CSRF ? I mean there’s no headers injection, its just a HTTP 302 redirection, it can be done with a simple html link.
I believe a CSRF is more like a vulnerable script allowing headers injection
and an exploitation like
vuln.php?foo=www.google.com%0aAccept-Language:%20ga
September 26th, 2006 at 7:15 am
It is an example of something vulnerable to CSRF.
The point isn’t the link or the redirection. A typical exploit would use that URL as the target of an image tag or something. Redirection is more benign, because you can see what has happened. This is just proving the concept in a polite way.
Clicking the link here shouldn’t count against the exploit. Imagine that I demonstrate a CSRF exploit on my web site, and RSnake links to it. Although you’d have to click the link to see it, it’s not part of the exploit. The same principle applies here.
By the way, what you’re describing is called HTTP Response Splitting. (Most exploits simply inject headers rather than split responses, but the vulnerability is the same.)
March 19th, 2008 at 3:35 pm
This has been fixed. Does anyone know exactly WHEN this was fixed?