New answers tagged csrf
My recommendation: Never. You should only have one CSRF token per session. If the session times out, then the CSRF token expires at this point. As there is no way for an attacker to read the CSRF token (at least there's no more of a risk of an attacker reading a CSRF token as the Session ID cookie), there is no need to generate a new one unless you have a ...
In this case, I'm using it for a set of login/registration forms, so there's no information leakage The existence of a getCSRFToken JSONP API with no other limitation on caller site is effectively a complete bypass for all CSRF protection. If you think that is not a problem, you should just get rid of the CSRF protection system instead, as it is doing ...
Well you should study your personal stats. You should ask yourself the following questions: How much time does an user spend in your system? What is the usability impact not changing it in a session? What is your expiring session time? ... Nobody here can answer those questions (among others) better than yourself.
The reason for CSRF tokens is to ensure that an attacker cannot force you to submit something without you knowing it. If an attacker would create a form on his/her site, say evil.com, he/she can easily fill in the CSRF token by doing the same JSONP request. Another, although perhaps difficult to implement, is to for having siteA create a token, submit it ...
If you add limited validity period (like 20minutes) for these keys (csrf, email confirmation) then I would say it is sufficient. Also this is assuming you do not keep any history of the keys.
Is including the SessionID even necessary if you are using encrypted ViewState? How could a malicious user generate a valid encrypted ViewState? A malicious user could generate a valid, encrypted ViewState by visiting the page in question themselves and extracting the value. If the Session ID is not part of the ViewState value then this value will be ...
Correct, your token needs to kept secret, or an attacker can duplicate the token. It's harder than borrowing the session cookie, but the basic principle is the same. If you generate a unique CSRF token for every request & require it be used only once and on ever request, you can then ensure the token is not replayed. Even then it's still possible for ...
If an attacker can sniff the CSRF token, then he can also sniff the session cookie and there would be no reason for him to launch a CSRF attack. Or am I missing something?
First, CSRF protection is not a part of the problem or solution here, you're just overloading the term to be synonymous with session. As I pointed out in my comment, CSRF protection is primarily to protect against an attacker performing an action on behalf of an authenticated victim. Account creation (in most cases) is an action performed by an ...
Disclaimer: I'm the gem author. I wrote Codesake::Dawn, a security source code scanner for ruby code. I'm close to release version 1.1.0 with 171 security checks (CVE bulletins and Owasp ROR cheatsheet) included. It works with Sinatra, Padrino and Rails web application out of the box. It doesn't detect xss introduced in your code... yet :-)
Top 50 recent answers are included