Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Anti-CSRF

Steven | Last updated: Feb 05, 2016 09:25PM UTC

Hello, I have three related questions; 1)) Can Anti-CSRF tokens be present in publicly accessible forms (for unauthenticated users), or are they should only be present under authenticated user forms? 2)) If burp reports a CSRF vulnerability on a public, non-private form, should it be directly assumed that it is a false-positive? 3)) Are anti-CSRF tokens different from tokens used for website authentication forms? How so? Thank you for your support.

PortSwigger Agent | Last updated: Feb 08, 2016 10:21AM UTC

1. Yes, they can be used on any form. 2. No. Burp attempts to detect whether the resource in question is session-dependent, and adjusts the severity accordingly, but CSRF bugs are just as real on unauthenticated functionality. 3. They are different from session tokens (if that is what you mean by tokens on authentication forms).

Burp User | Last updated: Feb 10, 2016 05:45PM UTC

Hi, Thank you for the answers. I am still wondering why would CSRF exist or be relevant on unauthenticated forms. By nature, CSRF would be used to try and convince an authenticated user to perform actions under his/her privileges. In that sense, why would Burp verify unauthenticated forms for CSRF? Correct, I meant tokens on authentication forms. So in a ideal form, there would be two types of tokens: anti-CSRF and authentication tokens (or cookies).

PortSwigger Agent | Last updated: Feb 11, 2016 09:52AM UTC

Unauthenticated functionality often needs to be protected from CSRF. There are trust/state boundaries within an application's logic that aren't just about whether you are logged in - various multi-step processes give rise to this. One common issue is that the login form itself (by definition accessed when unauthenticated) needs to be protected, to prevent CSRF attacks from performing a forced login request to cause a victim user to log in to an application using attacker-provided credentials. This technique can be used for various purposes, including triggering a stored XSS bug that only affects the user context in which the payload was submitted (e.g. a stored user display name).

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.