If you don’t believe me keep reading. I already made you search Google for something a little embarrassing. And no, this is not something anti-virus scanners can do anything about.
The technical term for this type of attack is Cross-Site Request Forgery (CSRF) and years back I called it the sleeping giant. If you happen to be one of the legions of Web developers who have never heard of CSRF then chances are every feature of every website you’ve ever built is vulnerable. Millions of other websites out there are suffering the same problem. With same technology (HTML and JavaScript) that Web pages use to include images, audio, video, banners, trackers, counters etc from all over the internet, any website owner can instruct a victim’s browser to send arbitrary HTTP requests to any website of their choosing.
Generally, Web browsers generate two different types of HTTP requests, GET and POST. For the sake of demonstration here we’ll be focusing only on GET. POSTs require a tiny bit more code. To have someones browser send a particular GET request, like a Google Search for example, is extremely simple.
1) Search Google something like “Justin Bieber fan club” and copy the URL in the location bar.
2) Paste the Google search URL into an HTML IMG tag and zero out the height, width, and border to make it invisible.
<* IMG SRC="http://www.google.com/search?hl=en&q=Justin+Bieber+fan+club&btnG=Search&aq=f&aqi=&aql=&oq=&gs_rfai=" WIDTH="0" HEIGHT="0" BORDER="0" *>
3) Load this code into a Web page, like this one, and voila! When the a Web surfer arrives their browser will execute the code and perform the exact same search (see HTTP request screen shot).
Obviously then any website owner can make your browser search for anything on Google, anything at all. Keep in mind that if the victim is logged-in, their session cookies will be automatically be sent as well. This is a key point about CSRF attacks. Forged HTTP requests are authenticated if the user had previously logged-in to the target website.If you happen to be logged-in to Google right now, go check your Web search history. Maybe you’ll see something in there you didn’t search for. It might look something like this... :)
17 comments:
Nice POC to drive home the point. This is certainly a frustrating issue addressed on a site by site basis. In the meantime, you can take control into your hands with an addon like request policy. (https://www.requestpolicy.com/)
But, it isn't easy and only for those really intent on taking control. Clearly, this is not the right approach across the board for all users.
@Michael: thank you. obviously we'll need solutions so that the website can protect itself, but we'll also need something for the user to protect themselves. That latter being a much tougher problem to solve.
The one thing we can do is separate the authenticated and un-authenticated functionality of a website. With some clever browser security innovation, I believe we can handle the auth, but not the other without really breaking the Web. RequestPolicy, while still presently unworkable, does teach us things though.
Nice read! Thanks for sharing your concerns.
CSRF is even more of an issue nowdays, than it was few years back, with the rise of social networking sites and AJAX technology.
I bet most of us browse the web while we're logged-in in our mail, social networking and other accounts, putting our personal data at risk one click at a time.
I guess there are some request filtering plugins out there, but most of us would find annoying the authorization of each request our browser makes in our day-to-day browsing. In addition to this, the average internet user doesn't have the knowledge to tell a legit request from a spoofed one.
Cheers!
I wrote about this topic here: http://jbyte-security.blogspot.com/2009/05/importancia-de-la-etiqueta-en-la.html
Interesting angle on the Google Search history hack is I'm sure many law enforcement agencies when confiscating PC's when investigating certain crimes.
Hacking, Paedophilia, Online Fraud; in fact any crime which can be perpetrated via electronic means, will look at search histories to build their case against a potential defendant.
Attack 1 - send victim a link to your site he visits and gets his history set to many undesirable things. combine that with an Iframed Ifeellucky search see (http://www.thetestmanager.com/?s=i+feel+lucky&search=Search)
Then contact local law enforcement to tell them that someone has been doing something illegal with their pc and that if they looked at his search logs they could get proof.
Delete the code from your page.
Police visit confiscate PC and check logs. Find bad search terms. and bingo prosecution starts. Chances are case would get dropped however it would cause considerable pain the the victim involved.
nice read and cool demonstration, especially for unaware web developers. except that voting for julian assange as times person of the year is actually a quite good thing to do. it's just like with web (in)security issues: the truth must be spread.
Would be cool if search engines improved search history to also show the referrer.
@paranoid: referers can be scrubbed by using META refresh tags or hosting the CSRF code on a SSL website.
@thetestmanager: just to make that scenario you describe more real:
http://ha.ckers.org/blog/20080320/click-a-link-go-to-jail/
I went to check my google history before loading this blog post, and the search for justin bieber was already there, just from the reader. Dang.
I've had some fun with websites that used GET for actions and allowed posting of images.
@Dan: whoa, that's troubling. What RSS reader browser combo are you using? Clearly they are sharing session cookies and HTTP connection libs.
google's reader, so it's probably not too surprising they share session data with google
@dan: yep, that would make sense!
I like and dislike this article. It's good from the standpoint it educated me on a real problem. But as a typical web user and webmaster, I don't like it. I get the sense there is not much I can do to prevent or detect it other than keeping my CMS fully patched. And I'm not sure how many people would install add-ons that may interfere with the browsing experience.
@Anne: While I didn't go into depth in the post, there are very effective things a website owner can do to protect their websites. See here for more details: http://www.whitehatsec.com/home/resource/whitepapers/csrf_cross_site_request_forgery.html
On the user side its a bit trickier, but it comes down to NOT being logged-in.
Hello Jeremiah,
Nice article, thank you. It seems Firefox NoScript addon has protection against this type of attacks, because this search trick is not working despite having Blogspot and related sites as trusted. Check http://noscript.net/abe/ Only disadvantage of NoScript is that you have to learn how to live with it.
Post a Comment