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://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.
Steve Vinoski
· 1 year ago
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.
Daniel Miessler
· 1 year ago
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.
court3nay
· 1 year ago
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.
All Comments
Actions are still actions regardless of whether they are performed via RESTful URLs or not.
Your example:
http://somesite.com/product/1234/purchase</p>
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?"
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.
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.
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.
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.