5

I know I can use the the Generate CSRF PoC feature to test whether I have a CSRF vulnerability but once I mitigate this, how will Burp recognize this fix on the next scan? I need to be able to demonstrate to the client that the vulnerability is no longer present by running a Burp scan.

4

For any CSRF issue, the general demonstration of prevention is showing that repeating the same request with the same preventative token, or with no preventative token, doesn't result in any data on the server changing.

Therefore, perform a legitimate request, send it to repeater, and try performing it again. If it works, the CSRF protection isn't working.

Then remove the CSRF token and send it again. If it works, the protection isn't working.

  • OK I see. But we would use a session based token. Not a request based token. – sproketboy Dec 26 '15 at 22:17
  • 1
    That doesn't solve the problem. With a session based token, replay attacks are still possible, since the token doesn't change on each request. It's harder to abuse, but still possible. – Matthew Dec 26 '15 at 22:19
  • Right but how does one do request based tokens with pages with dozens of ajax calls? – sproketboy Dec 28 '15 at 0:27
  • I have seen systems where each call returns a token, and later calls use the previous response. It tends to be a bit of a nightmare of nested calls though. I'd suggest limiting the validity time of each token and refreshing it every minute or so, and combining it with a check on suspicious behaviour (depending on your app, might be possible to do lots of bad things in a minute!) - the specific solution would be app specific though – Matthew Jan 12 '16 at 10:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.