开发者

csrf protection

开发者 https://www.devze.com 2023-03-17 18:42 出处:网络
There are quite a lot writt开发者_高级运维en about preventing CSRF. But I just don\'t get it: why I can\'t just parse the csrf token in the target page form and submit it with my forge request?If you

There are quite a lot writt开发者_高级运维en about preventing CSRF.

But I just don't get it: why I can't just parse the csrf token in the target page form and submit it with my forge request?


If you are able to inject script code into the target page (XSS) then yes, you can do that thus rendering the CSRF prevention useless.

The CSRF token has to be stored in the page the end-user receives (or he won't know it either).

In fact, in security assessments, XSS usually evaluated not for its own damage potential but for its use in just such attacks.


CSRF attacks are blind. They do session riding and the attacker has no direct control unless he can extract the token via an XSS vulnerability. Normally a session wide token can be used. Rotating tokens per request might be an overkill and could lead to false alarms. I prefer to use tokens per resource with a master session token.


The CSRF token should be everytime for every user and for every request a totally different token, so it can never be guessed from an attacker.

For php, .net and javascript have a look in the OWASP CSRFGuard Project - if you are working with java and jsf 2.x its already save against CSRF (as long as you use POST and not GET - for this you will have to wait for JSF 2.2) else if you work without JSF the HTTPUtillities Interface from the OWASP ESAPI could be also very helpful!


Because the value of the CSRF token isn't known in advance.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号