RESTful Programming and CSRF

By Daniel Miessler on March 29th, 2008: Tagged as CSRF | Information Security | Programming | Web Security

digital_hacking

[ 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.:

  • Joe Schmoe

    Actions are still actions regardless of whether they are performed via RESTful URLs or not.

    Your example: http://somesite.com/product/1234/purchase

    is no easier/harder to abuse with CSRF than something like:

    http://somesite.com/cgi-bin/purchase.cgi?product=1234

    When dealing with CSRF, you just need to remember that any major actions need to be verified by making the user re-login (or equivalent). Use of timeouts can also be helpful: “Hey, this user last visited 5 days ago and now the first page he/she is hitting is a checkout page?”

  • Joe Schmoe

    Actions are still actions regardless of whether they are performed via RESTful URLs or not.

    Your example: http://somesite.com/product/1234/purchase

    is no easier/harder to abuse with CSRF than something like:

    http://somesite.com/cgi-bin/purchase.cgi?product=1234

    When dealing with CSRF, you just need to remember that any major actions need to be verified by making the user re-login (or equivalent). Use of timeouts can also be helpful: “Hey, this user last visited 5 days ago and now the first page he/she is hitting is a checkout page?”

  • http://andrewingram.net/ Andrew Ingram

    Your examples don’t look like REST to me.

    My understanding as as follows:

    http://acme.com/products/cart/display isn’t RESTful but http://acme.com/products/cart/ with a action of GET is

    http://acme.com/account/delete isn’t RESTful but http://acme.com/account/ with an action of DELETE is

    Your other examples seem wrong too

    You wouldn’t have http://somesite.com/product/1234/purchase You’d have http://somesite.com/basket/ and to purchase a product you’d access it with POST and the product id

    http://somecause.com/campaign/donate is the same deal, you’d do a POST on http://somecause.com/campaign/ to update it with a new donation

    Any RESTful URL should be completely harmless when accessed via GET.

  • http://andrewingram.net Andrew Ingram

    Your examples don’t look like REST to me.

    My understanding as as follows:

    http://acme.com/products/cart/display isn’t RESTful but http://acme.com/products/cart/ with a action of GET is

    http://acme.com/account/delete isn’t RESTful but http://acme.com/account/ with an action of DELETE is

    Your other examples seem wrong too

    You wouldn’t have http://somesite.com/product/1234/purchase You’d have http://somesite.com/basket/ and to purchase a product you’d access it with POST and the product id

    http://somecause.com/campaign/donate is the same deal, you’d do a POST on http://somecause.com/campaign/ to update it with a new donation

    Any RESTful URL should be completely harmless when accessed via GET.

  • http://steve.vinoski.net/blog Steve Vinoski

    RESTful URIs are associated with resources, not actions. URIs specifying actions are not RESTful. For RESTful web applications, HTTP verbs — GET, PUT, POST, DELETE — provide the actions.

  • http://steve.vinoski.net/blog Steve Vinoski

    RESTful URIs are associated with resources, not actions. URIs specifying actions are not RESTful. For RESTful web applications, HTTP verbs — GET, PUT, POST, DELETE — provide the actions.

  • http://dmiessler.com/ Daniel Miessler

    Ah, yes, I remember this now. Well, as I said, I wasn’t claiming expertise, and I did in fact get a crucial piece wrong in this flash of “insight”. The URLs were right, up until the action piece – the point of REST is to have the HTTP verb be the action. Not for the URL to indicate the action.

    Right.

    Thanks for the reminder, guys. That’ll teach me to make 5 minute posts on a whim.

  • http://dmiessler.com Daniel Miessler

    Ah, yes, I remember this now. Well, as I said, I wasn’t claiming expertise, and I did in fact get a crucial piece wrong in this flash of “insight”. The URLs were right, up until the action piece – the point of REST is to have the HTTP verb be the action. Not for the URL to indicate the action.

    Right.

    Thanks for the reminder, guys. That’ll teach me to make 5 minute posts on a whim.

  • http://blog.caboo.se/ court3nay

    It’s a dirty little secret of rails apps that many of them are susceptible to csrf attacks. However, if you designed your rails app correctly (i.e. GET actions only show data, to delete you have to post with DELETE) it makes it a little more difficult, because you need a POST to change any data.

    There was a twitter ‘virus’ a few months that we discovered and destroyed that essentially created a form which created a tweet and POSTed the form automatically with javascript.

    My colleague Rick Olson wrote CSRF_killer plugin which automatically puts some hidden form variables into all of your forms, and effectively squashes any such attacks.

  • http://blog.caboo.se court3nay

    It’s a dirty little secret of rails apps that many of them are susceptible to csrf attacks. However, if you designed your rails app correctly (i.e. GET actions only show data, to delete you have to post with DELETE) it makes it a little more difficult, because you need a POST to change any data.

    There was a twitter ‘virus’ a few months that we discovered and destroyed that essentially created a form which created a tweet and POSTed the form automatically with javascript.

    My colleague Rick Olson wrote CSRF_killer plugin which automatically puts some hidden form variables into all of your forms, and effectively squashes any such attacks.

  • http://pulse.yahoo.com/_KHHXAEEDVDRCJGAMR2WZAQNN3A Gomee Zheng

    disappears here>>>>>>>>>>>>>>>

    http://www.pumafootwearsale.co…

    Read more: http://www.timberlandseller.com


Top

Popular

Information Security / Technology

Politics

Philosophy & Religion

Technology & Science

Culture & Society

Miscellaneous

Arguments

Projects

Collections

Twitter

What I'm Reading

Favorite Books and Essays

Top Blog Categories

Inputs