About the Author

Chris Shiflett

Hi, I'm Chris, a web developer and a founding member of Analog. I live and work in Brooklyn, NY.


Using CSRF for Browser Hijacking

Something the Myspace worm taught us is that traditional safeguards against CSRF (cross-site request forgeries) are rendered ineffective when XSS (cross-site scripting) vulnerabilities exist in a web application. This is because malicious content injected into a web site can do a number of things, such as send HTTP requests and receive HTTP responses with Ajax, or even attack servers on your local network.

The result is that an attacker can perfectly mimic your actions using your own browser. It's something I've labeled browser hijacking, and it's one of the most dangerous examples of CSRF to date. It's also basically the same attack that I've been discussing in recent posts such as Cross-Domain Ajax Insecurity and The Dangers of Cross-Domain Ajax with Flash, except that XSS is an easy way around the same-domain restriction (without requiring an open crossdomain.xml policy).

Think XSS doesn't matter? Think again. As Johann from ThinkPHP puts it:

Buy one XSS, get a CSRF for free.

I've been speaking at conferences about CSRF for years, and one of the most alarming things I've noted during that time is that very few developers are aware of it, even conceptually. Jeremiah Grossman has noticed this, too, and he likens CSRF to a sleeping giant. RSnake calls it "the attack of the future." SANS is doing their part by trying to raise awareness.

Hopefully good guys will learn about it before too many bad guys do.

About This Post

Using CSRF for Browser Hijacking was posted on Wed, 11 Oct 2006 at 03:56:45 GMT.

8 Comments

1. Andrew van der Stock's GravatarAndrew van der Stock said:

CSRF is mentioned in the first paragraph of the #1 item in the OWASP Top 10 2007.

Hopefully we will get more light shed on it soon!

Andrew

Wed, 11 Oct 2006 at 08:34:43 GMT Link


2. Ivan Markovic's GravatarIvan Markovic said:

Very interesting and dangerous security hole. Alredy I see new types of phising attacks with bypased messages on boards and forums.

Wed, 11 Oct 2006 at 09:25:32 GMT Link


3. mock's Gravatarmock said:

Well I think people in the perl community are starting to get it after I used it to demo taking over someone's CPAN account during my talk at YAPC::Europe. This is a rather amusing image if you know who wrote plagger.

Thu, 12 Oct 2006 at 06:59:42 GMT Link


4. Chris Shiflett's GravatarChris Shiflett said:

Mock, that's good to hear. :-)

Let me know if I can help in any way, or if you'd like to share ideas for slides or anything like that.

Thu, 12 Oct 2006 at 15:16:44 GMT Link


5. mock's Gravatarmock said:

Cool. I'm working on something nasty with crossdomain.xml right now, so I might be dropping you an email assuming I can get the basics to work.

Thu, 12 Oct 2006 at 21:13:28 GMT Link


6. gilberto melendez's Gravatargilberto melendez said:

Excuse me, I have been " reading " and I dont know if solutions like modsecurity at www.modsecurity.org can help to deal whit this attack.

Tue, 17 Oct 2006 at 05:28:21 GMT Link


7. doctorrock's Gravatardoctorrock said:

Well, I think even with modsecurity activated, you can't do anything against XSS attacks using XHR, as XHR works from the user web navigator like if it was a normal request.

XSS are very powerfull attacks, because they act exactly as users used to, and are that way diffcult to detect.

Fri, 20 Oct 2006 at 20:33:15 GMT Link


8. Dev-G's GravatarDev-G said:

Hi,

I am confused about one thing, we are passing the token as a hidden field and storing it in the Session. What will happen in case the hacker/attacker can see this hidden field using the view source.

Now, lets say a valid session for the user A is running on the website and user B(hacker) finds out the token value, by sniffing the network or lets just say get to know all the form params (It is my assumption, I don't know how it is possible to do it, may be view source).

Then the CSRF protection will fail right away, is that correct?

Shouldn't we do some thing else regarding the token like pass it in someway else other than the hidden field in the form?

Mon, 09 Mar 2009 at 23:07:46 GMT Link


Post A Comment

Personal Details and Comment

Style Guide

Line breaks are converted to paragraphs. Also use:

  • <a href="" title="">text</a>1
  • <em>text</em>
  • <blockquote><p>text</p></blockquote>
  • <code>2  <?php  if ($foo) {      $foo = TRUE;  }  ?></code>
  1. Note: <code> can be used inline (e.g. in paragraphs) or in a block as shown. Include whitespace and newlines in blocks.

Please enter Chris (my first name) below. This is a primitive spam prevention technique, and I apologize for the inconvenience.

Preview and Submit

Upcoming Talks

ConFoo

10 - 12 Mar 2010

At Hilton Montréal Bonaventure, Montréal, Canada.

South by Southwest

12 - 16 Mar 2010

At Austin Convention Center, Austin, Texas.

Dutch PHP Conference

10 - 12 Jun 2010

At TBD, Amsterdam, Netherlands.

O'Reilly Open Source Convention

19 - 23 Jul 2010

At Oregon Convention Center, Portland, Oregon.

New Comments

RyanTheGreat wrote:

Well, I'm not Chris, but I will do my best to address the questions raised in the comments by Ian...

Posted in Security Corner: Cross-Site Request Forgeries
Chris Shiflett wrote:

Thanks for the kind words, Simon. I'm glad you liked the tutorial. In case it's helpful, here'...

Posted in Webstock
Chris Shiflett wrote:

Hi Robin, I plan to post something about it, but it's going to be hard to express everything i...

Posted in Webstock
Simon Mahony wrote:

Hi Chris, I really enjoyed your workshop on the Evolution of Security at Webstock. I think I g...

Posted in Webstock
Robin Gorry wrote:

Hi Chris, I was wondering if you were going to post how Webstock went for you this year. I li...

Posted in Webstock

Browse Comments


Work and Books

Analog Essential PHP Security HTTP Developer's Handbook