Storing previous URL as session data

[eluser]crikey[/eluser]
I think the point, Jondolar, (is your username from the Jean M. Auel books?) really is that the (legitimate) user should only delete if: 1) they're logged in, 2) they have permission to delete the item *and* 3) they're knowingly deleting the item using the application/website.

CSRF attacks can occur if 1 and 2 are true but not necessarily 3.

From what I've been reading, using tokens in forms that uniquely relate to the user's session, and checking the existence/matching of the tokens, is a way to help secure a site against CSRF.

Edited for grammar.

[eluser]n0xie[/eluser]
[quote author="Jondolar" date="1271231452"]
The key is to validate that the user is logged in AND has authority to delete the requested record. If the user does not own the record, don't let them delete it.[/quote]
You are missing the point.

1. If I as a user can delete any record simply by changing a number in the URL, you have much bigger problems than CSRF
2. If you had a 'userlevel' higher than the user in question, you'd still be able to delete it. In a role based system, this is quite common. For day to day websites, usually the site administrator has FULL access to everything and the only check that is done is:

Code:

$this->auth->is_admin()

3. There is nothing preventing me redirecting you to a page where I have 100.000 different id's for you to delete. If you hit that page, you will delete all the rows you have access to:

Code:

<img src='yoursite.tld/somepage/delete/1' />
<img src='yoursite.tld/somepage/delete/2' />
<img src='yoursite.tld/somepage/delete/3' />
// etc...

There’s nothing wrong with doing destructive actions using get,

Yes there is. It's in direct conflict with the HTTP spec. A GET request should only be used for idempotent requests (i.e. when requesting a resource which does not change state). The prime example being when Google implemented prefetch caching (i.e. they loaded all the links on a page in the background so you would have an instantaneous loaded page when you clicked on a link). Guess what happened when this was used on url's like 'yoursite.tld/somepage/delete/{id}.

- Save the code to a cookie AND put it in either a post variable or in the URL which deletes the entry (example: mysite.com/thing/delete/25/1f3870be274f6c49b3e31a0c6728957f)

POST, yes, URL, no. Putting an arbitrary hash in the URL is just another way of saying; please brute force me.

From what I’ve been reading, using tokens in forms that uniquely relate to the user’s session, and checking the existence/matching of the tokens, is a way to help secure a site against CSRF.

Bingo.

[eluser]Jelmer[/eluser]

POST, yes, URL, no. Putting an arbitrary hash in the URL is just another way of saying; please brute force me.

POST can be done unseen through unsave SWF and some other tricks, so while attacks using post are less common you can't really consider it more save then URL.
Also the token can't be valid for too long and needs to be refreshed every time another page is loaded - which is why you should enable CSRF site-wide and not through a quick fix like I posted before.

And brute-force is a bit unlikely by the way. In an MD5 hash there's 16 different characters on 32 different positions which is 3.40e38 different possibilities. If you got a very quick website your page can be loaded about 250 times per second - it would take up to 44252284503867361561508349905,297 years to break this brute force. If you make your cookie expire after 30 minutes that gives someone a 1 in 7.56e32 chance of breaking it.

[eluser]n0xie[/eluser]
That's all assuming the MD5 seed is random. Since you use time() as basis, the possible MD5 outcome is reduced incredibly. That and the fact that you're not trying to break MD5, just try to accomplish a collision, makes the chance a lot more likely.

For example. Time gives the current timestamp. This 'simply' generates 60 hashes per second which are predefined. That's a lot less 'probability' than what you are proposing.

But the point wasn't that MD5 is insecure, or that brute-forcing MD5 isn't that hard these days. The point is that if you don't use GET but a simple POST request (including a nonce), all these problems go away. Not only that, but you are implementing the HTTP specs as it was intended.

[eluser]Jelmer[/eluser]

That’s all assuming the MD5 seed is random. Since you use time() as basis, the possible MD5 outcome is reduced incredibly. That and the fact that you’re not trying to break MD5, just try to accomplish a collision, makes the chance a lot more likely.

For example. Time gives the current timestamp. This ‘simply’ generates 60 hashes per second which are predefined. That’s a lot less ‘probability’ than what you are proposing.

As I mentioned, what I posted was a quick fix and in no way a good way to go (I edited my previous post to point that out). You should of course create a far more secure token then the one I posted.

But the point wasn’t that MD5 is insecure, or that brute-forcing MD5 isn’t that hard these days. The point is that if you don’t use GET but a simple POST request (including a nonce), all these problems go away. Not only that, but you are implementing the HTTP specs as it was intended.

POST is probably twice as secure as GET, but that doesn't really matter as it's still possible to unknowingly post stuff to a system. And while I agree with you that POST is the better way to go, it is wrong to think that makes it a lot more secure and if someone prefers to do it using the URL it's not the security concern that should keep him/her from that. Brute force is just as much possible with POST as it is with GET.
To suggest that using post makes "all these problems go away" is a wrong statement as POST isn't a protection against CSRF in any way. Attacks using post maybe more rare and harder, but they're not impossible and should be taken seriously.

Brute-forcing MD5 is still pretty implousable by the way, it's a bit more complex to break but indeed not impossible. As long as you generate your hashes using multiple non-public variables there's no chance of someone breaking it within a plausible timeframe, so MD5 is secure enough as long as you implement it right.

[eluser]n0xie[/eluser]
[quote author="Jelmer" date="1271275932"]
POST isn't a protection against CSRF in any way. [/quote]
Hence my statement 'POST including a nonce'...

[eluser]Jelmer[/eluser]
As we basicly agree this discussion is getting a bit useless. This'll be the last time I write a quick&dirty;example for something this complex

The point I was trying to make is that it doesn't make a significant difference in security if you implement it using POST or GET. What matters is how you implement your tokens, implementing them as a nonce is of course the prefered way to go.
What I took issue with in your last post was that it looked like the POST part was the most important point of the difference in the sentense you quoted, but the most important difference was the nonce. When comparing post with a nonce and get with a nonce there's no significant security diffence, only differnce is in style & best practice.