REG : Absence of Anti-CSRF Tokens

[Dharini n]

Hai everyone,

Anti CSRF implemented in all pages. But In Owasp Zap tool getting errors.

Any solution for this please suggest me.

[psiinon]

Absolutely no idea, because you havnt really told us anything.

Have a look at the alert details including the related request and response.

If you strill dont understand then you will need to share those details here, obfuscating any sensitive information of course.

Cheers,

Simon

[Dharini n]

Security related issue. for your references screenshot attached.

[psiinon]

OK, so we can see that your form does not contain an anti CSRF token, which is why ZAP is reporting it.

However it also looks like its a login form, which doesnt really need them.

So you can ignore it / flag it as a false positive.

Cheers,

Simon

[Kevin W. Wall]

There is a such thing known as "Login CSRF".

Google for it. We generally require CSRF defenses for login pages because of it.

-kevin

--
You received this message because you are subscribed to the Google Groups "OWASP ZAP Developer Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zaproxy-devel...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/zaproxy-develop/e430a60e-e1f7-4e19-a72c-9b571254eb28n%40googlegroups.com.

[Dharini n]

Thanks for your reply.

Already CSRF implemented in all pages. But still getting errors

[kingthorin+owaspzap]

The screenshot you provided clearly illustrates that isn't the case.

[Kevin W. Wall]

Rick, because this is for a login page, I have seen a few different approaches in the past where the CSRF tokens are treated differently for them than for the rest of the site. (E.g., if it's written Java, you likely will [or, at least should, to prevent session fixation attacks] replace the pre-authenticated HttpSession with a new HttpSession so whereas you might normally place a CSRF token in a generated hidden form parameter and then compare it to the one stored in the HttpSession object, since the session object is going to be destroyed upon successful login, often times it might be sent in a different manner for login pages. For example, the POST could be done though AJAX and it might be passed via a custom request header that ZAP might not recognize.)

That said, Dharini, you need to provide a lot more detail if you want the ZAP team (or anyone else for that matter) to help. Ideally, if I were debugging this, I would want to see full HTTP request / response pairs as well as a brief overview of how you are providing the CSRF tokens (e.g., OWASP CSRFGuard, OWASP CSRF Protector, Spring, etc.). More details are better than none.

Note that if you show HTTP responses, unless your username/password is just a temporary throwaway account, you should redact that and any other sensitive data from your HTTP requests and responses.

Hope that helps.

-kevin

To view this discussion on the web, visit https://groups.google.com/d/msgid/zaproxy-develop/fc93b8b2-4dac-4fe9-a397-2d57933af607n%40googlegroups.com.

--

Blog: https://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall | OWASP ESAPI Project co-lead
NSA: All your crypto bit are belong to us.

[psiinon]

There is a such thing known as "Login CSRF".

Google for it. We generally require CSRF defenses for login pages because of it.

Good point - I'd forgotten about that.

Thanks Kevin!