This might be obvious to those most familiar with CSRF and Clickjacking, but for those just getting a handle on it, here’s a short explanation of a fundamental difference between the two issues.

–

CSRF is your browser doing things on your behalf, without you clicking on something directly. A good example of this is your browser loading every image on a hostile website, and having one of those images be an “action” rather than an image. The point is that with CSRF you didn’t really do anything except load the page, and the browser then takes over from there to manifest the vulnerability.

With Clickjacking the user actually does actively interact with something, but the action itself can be “hijacked” by placing a layer between the user and the legitimate action. So imagine that you in a room with an apple on a pedestal, and as you reach for the apple you break an infrared laser beam and open a trap door.

You really did go for the apple with your own hand (unlike CSRF), but in the process you transparently triggered another action that you may not like. The trick for the attacker (using that analogy) is rigging up different types of triggers (infrared lasers) and actions (trapdoor).

Links

http://ha.ckers.org/blog/20081007/clickjacking-details/

[ Edit: Disregard this post. It was written by an evil, stupid man impersonating me. No, not really. It's just wrong. The focus of REST is HTTP verbs, not actions within URLs. I knew that, but mentally pooped myself while writing this. ]

I just realized something while on the Twitter site. Shouldn’t sites built using REST principles be more susceptible to CSRF attacks? I’ve only studied REST concepts for a few minutes when building a little sample Rails app, so I could be totally off here, but follow me for a second.

REST

The concept here is for URLs to both indicate functionality to users, as well as provide that functionality. So a URL like:

http://acme.com/products/cart/display

…would display the contents of your cart. Nice, right?

And a URl like:

http://acme.com/account/delete

…would nuke your account. Again, as you would expect from reading the URL.

CSRF

Cross Site Request Forgery (Sea Surf) works by getting people to follow links, via a number of methods such as embedding links in IMG tags or just plain getting them to click them via social engineering.

The trick is that if you can get someone’s browser (or them) to follow a URL, while they’re logged into a given site, the “action” associated with that URL will be executed using their credentials. By credentials I usually mean a valid cookie. When your browser sends requests (even for images) to remote websites, and you happen to have a cookie for that site on your system, that cookie will be sent with ALL requests to that site. It’s kind of scary, really.

I did a proof of concept on this over at DSLR recently, where just by visiting a page I could log you out of your account there. I did that via the IMG tag trick. An image on the page pointed to the logout URL, so if you had a cookie for DSLR and loaded the fake image (which the browse does for you without your knowledge), you were logged out.

How It Would Work

So that’s the thing — RESTful URLs are associated with actions, and CSRF is based on getting you to visit URLs that have actions associated with them. Imagine a CSRF campaign against ACME company where tons of links are emailed out to ACME users with the following URLs in them:

http://somesite.com/product/1234/purchase http://somecause.com/campaign/donate http://favoritesite.com/account/terminate

Remember that if any of the people following those links have valid cookies for those sites, they could automatically have those things happen. And if the attacker uses the IMG trick like I demonstrated, the user wouldn’t even know anything took place because it would have been their browser that performed the action, not them.

Anyway, just a thought. Maybe something to think about when working with RESTful designs.: