You know, this is extremely old (and odd).

http://www.squarefree.com/archives/000134.html

And they do not correct that "hack" since these years ? :-S

Most of the big sites have the similar problem. For example you could make a page that automatically undig particular story on digg.com. Than just link this page from this story's digg comments page...

The irish example was already posted today in a slashdot comment earlier this morning.

http://it.slashdot.org/article.pl?sid=06/09/25/1440220&from=rss

Its the second comment on the page.

The comment:
I particularly like this example [dlitz.net].

Here's the spoiler [dlitz.net].

XSS hacks are here to stay, Vendors and Developers need to get their act together to negate risks. Right now, what we are seeing is just the whitehat stuff . Who is to know what is happening 'actually happening' – out there!!

FYI only.. the best XSS cheat sheet, right now is Rsnake's

http://ha.ckers.org/xss.html

i thought it was common practice in web security to check the http_referer server variable. guess not at google.

The trouble is the http_referer variable isn't always populated with the referrer, it can be blocked by some web browsers, anti-spyware software etc, so isn't as reliable as you'd first think in the fight against xss.

<< i thought it was common practice in web security to check the http_referer server variable. >>

Many security software packages block the http_referer header to protect the user's privacy, so that's not always the most user-friendly of ways to do things. Expecting a POST from the form would be better, although it would still be possible to script that too...

Is it obvious that Tony and I work together! ;o)

The http_referrer is not secure anyway, even if it was always present. But it's not hard to protect against this kind of request forgery.

For example, a form to change preferences can be served to include a hash of the user's cookie, and the change of preferences only actioned if the hash and the cookie match on the target page.

States should only be changed via POST. And POST should not be allowed via AJAX/ XMLHTTP by browsers. Wouldn't that be a solution?

I sometimes check the referrer and allow empty ones or ones from the same domain, at least for non-critical stuff, e.g. to avoid hotlinking on Gaxed.com (where hotlinking is a problem because the image URL changes when it moves to the cache). If someone hotlinks and publishes an image, it doesn't matter if 10% hide or distort the referrer, 90% of the visitors to his hotlinked image will complain to the hotlinker. Similarly you could prevent 90% of targets for an XSS worm etc., as a first step, right?

Good point Roger. It's very easy to spoof your HTTP_REFERER when running server-side scripts. It's not as easy to do this from cross-domain client-side scripts though (I think).

<< States should only be changed via POST. And POST should not be allowed via AJAX/ XMLHTTP by browsers. Wouldn't that be a solution? >>

Hmm. Kind of. You could still just use a form with a POST method and hidden fields, then use good old-fashioned JavaScript to do a form.submit() though.

I agree that checking HTTP_REFERER for the same domain or blank would probably be satisfactory for most purposes, 90% of the time at least.

I just published the elmer fud version on my companies intranet. Waiting to see if anyone notices. As this is a tech company, Firefox search bar is much more utilized, but maybe.... just maybe someone will see.

Heh. Keep us updated on this Travis...

LOL!!! That's great, travis.

Just got noticed! took the better part of the day, but all of a sudden I hear someone shout "What the heck?!" (3-4 second pause) "Did Elmer Fudd do something special today or something?"

I just started laughing.... see, hacking can be a great source of innocent humor!

MAN that is funny. Now people are staring at me laughing at my desk. Travis. that is BRILLIANT!!!!!!

[Moved from "Google XSRF vulnerability entry mentioned by SANS ISC" – Tony]

SANS Internet Storm Center has mentioned Google Cross-site Request Forgery entry published last Monday at their Diary page at
http://isc.sans.org/diary.php?storyid=1750

as one of example of this new type vulnerability.
SANS ISC is widely known in security community and several journalists use it as their source.

I'm putting the prank on Digg :)
http://www.digg.com/security/Prank_Switch_Your_Colleagues_Google_to_Elmer_Fudd