CSRF prevention
Posted: Sun Oct 25, 2009 3:34 pm
I familiarized myself with this exploit a long time ago but didn't really sit down to think about what the problem is and how it's solved.
I believe that many solutions revolve around generating a unique token and storing it in a hidden form field. This value is persisted in a SESSION or similar server side. When the form is submitted, the value POST'ed with the form is compared to the value in the SESSION and if they match, allow the action to continue, if not, it's a exploit attempt?
Do I understand the basic philosophy here?
It's to prevent people faking requests from other domains? Can you give me a few examples? As I understand, something like this might be an example:
1. User logs into real site/blog/etc.
2. User reads comments in forums
3. User sees interesting link and clicks
4. User redirected to hacker site with interesting blog
5. User sees another interesting link and clicks
6. This link is crafted to delete a record on the 'real' site in step 1
Because user redirected to hacker site without logging out first, the hacker site can issue delete, update, create requests and they will be executed as the original SESSION token is still valid
Is this the gist of the idea...how do you prevent deletion from occuring if executed via a simple GET link (user/delete/PKID) as opposed to a FORM submittion. Would you simply generate the token ID and inject it into the GET request as well similar to SESSION.
Cheers,
Alex
I believe that many solutions revolve around generating a unique token and storing it in a hidden form field. This value is persisted in a SESSION or similar server side. When the form is submitted, the value POST'ed with the form is compared to the value in the SESSION and if they match, allow the action to continue, if not, it's a exploit attempt?
Do I understand the basic philosophy here?
It's to prevent people faking requests from other domains? Can you give me a few examples? As I understand, something like this might be an example:
1. User logs into real site/blog/etc.
2. User reads comments in forums
3. User sees interesting link and clicks
4. User redirected to hacker site with interesting blog
5. User sees another interesting link and clicks
6. This link is crafted to delete a record on the 'real' site in step 1
Because user redirected to hacker site without logging out first, the hacker site can issue delete, update, create requests and they will be executed as the original SESSION token is still valid
Is this the gist of the idea...how do you prevent deletion from occuring if executed via a simple GET link (user/delete/PKID) as opposed to a FORM submittion. Would you simply generate the token ID and inject it into the GET request as well similar to SESSION.
Cheers,
Alex