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.
1 Answer
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. Commented Dec 26, 2015 at 22:17
-
1That 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.– MatthewCommented Dec 26, 2015 at 22:19
-
Right but how does one do request based tokens with pages with dozens of ajax calls? Commented Dec 28, 2015 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– MatthewCommented Jan 12, 2016 at 10:17