Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CsrfProtection weakness #36

Closed
foowie opened this issue Sep 2, 2014 · 5 comments
Closed

CsrfProtection weakness #36

foowie opened this issue Sep 2, 2014 · 5 comments

Comments

@foowie
Copy link

foowie commented Sep 2, 2014

After security review done by external company one weakness has been found. Since base token is stored in session and session can have expiration days, there is possibility to store some tokens and use them for attacks (mainly on public computers - internet cafe).
Token should get regenerated after user login and logout. This can avoid most of illegal uses.

@Majkl578
Copy link
Contributor

Majkl578 commented Sep 2, 2014

There should be probably expiration in CSRF session section, like 10/30 minutes or something like that.
Regeneration after login/logout should be imho done in user-land though.

@xificurk
Copy link
Contributor

xificurk commented Sep 2, 2014

Well, there used to be optional parameter with timeout value, but it was removed (not sure why).

@dg
Copy link
Member

dg commented Sep 2, 2014

Timeout is not proper solution.

@mishak87
Copy link
Contributor

mishak87 commented Sep 3, 2014

@dg Readme should reflect this issue and mention implementation details along with reasoning behind it. Apparently users assume it is implemented as Synchronizer Token Pattern but difference is that unique token is generated for whole session not per request.

@foowie Could you publish the that part of security review for future referrence?

TL;DR

CSRF implementation in Nette is only lightweight. If you are concerned with security you must implement your own CSRF token policy using Nette\Security\User::onLogin/onLogout and probably after receiving form.


Forms generate token only once for whole session. That prevents attacks on server that could lead to full memory or disk. Other solutions have more caveats either being complicated (out of scope for nette(/forms)), hard to implement along with AJAX or can open doors for DoS.

If you are concerned by people accessing your app from internet cafe I would suggest using HTTPS everywhere and reminding your users to logout along with using two level verification for critical actions.

Internet cafe argument is no longer valid it is 2014 not 1995. Anything with USB port that is not a extension cord cannot be trusted. That includes even cars that use same bus for control and media etc.

@foowie
Copy link
Author

foowie commented Sep 3, 2014

@mishak87 Short description of vulnerability sent in review

CSRF tokens do not appear to be revoked on logout. This means that a user who accesses their
account on an untrusted computer should consider their account permanently compromised; while
they can revoke their session token by logging out, they cannot prevent CSRF attacks from an
attacker who recovers a CSRF token from the untrusted computer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants