defaultCsrfMiddleware not working with Yesod.Auth.Hardcoded #1159
Assignees
Comments
MaxGabriel
added a commit
to MaxGabriel/yesod
that referenced
this issue
Feb 15, 2016
Closes yesodweb#1159 Based on reading this [StackOverflow Post](http://stackoverflow.com/questions/6412813/do-login-forms-need-tokens-against-csrf-attacks), using CSRF protection on login forms makes sense for typical username/password signup flows. I don't think the vulnerability discussed there applies to the hardcoded login, because the attacker couldn't create an account of their own. However: * If I understand the example in Yesod.Auth.Harcoded, one use case is to share have one login form that works for both the Hardcoded plugin as well as normal database-backed username/password login, in which case having a CSRF token makes sense * I don't see a downside to having the CSRF token there * It makes the Hardcoded plugin work with the CSRF middleware Does this sound like the right solution?
MaxGabriel
added a commit
to MaxGabriel/yesod
that referenced
this issue
Feb 15, 2016
Closes yesodweb#1159 Based on reading this [StackOverflow Post](http://stackoverflow.com/questions/6412813/do-login-forms-need-tokens-against-csrf-attacks) and skimming [this paper](http://seclab.stanford.edu/websec/csrf/csrf.pdf), using CSRF protection on login forms protects against a vulnerability where an attacker submits their own username/password in the login form. Later, the user uses the real site, but doesn't realize they're logged into the attacker. This creates vulnerabilities like: 1. If the site logs the user's activity for them (e.g. recently watched videos on YouTube, previous searches on Google), the attacker can see this information by logging in. 2. The user adds sensitive information to the account, like credit card information, the attacker can login and potentially steal that information or use it on the site. I don't think this vulnerability applies to the hardcoded login plugin because the attacker couldn't create an account of their own. However: * If I understand the example in `Yesod.Auth.Hardcoded`, one use case is to share have one login form that works for both the Hardcoded plugin as well as normal database-backed username/password login, in which case having a CSRF token makes sense * I don't see a downside to having the CSRF token there * It makes the Hardcoded plugin work with the CSRF middleware Does this sound like the right solution?
MaxGabriel
added a commit
to MaxGabriel/yesod
that referenced
this issue
Feb 15, 2016
Closes yesodweb#1159 Based on reading this [StackOverflow Post](http://stackoverflow.com/questions/6412813/do-login-forms-need-tokens-against-csrf-attacks) and skimming [this paper](http://seclab.stanford.edu/websec/csrf/csrf.pdf), using CSRF protection on login forms protects against a vulnerability where an attacker submits their own username/password in the login form. Later, the user uses the real site, but doesn't realize they're logged in as the attacker. This creates vulnerabilities like: 1. If the site logs the user's activity for them (e.g. recently watched videos on YouTube, previous searches on Google), the attacker can see this information by logging in. 2. The user adds sensitive information to the account, like credit card information, the attacker can login and potentially steal that information or use it on the site. I don't think this vulnerability applies to the `Yesod.Auth.Hardcoded` plugin because the attacker couldn't create an account of their own. However: * If I understand the example in `Yesod.Auth.Hardcoded`, one use case is to share one login form that works for both the Hardcoded plugin as well as normal database-backed username/password login, in which case having a CSRF token makes sense * I don't see a downside to having the CSRF token there * It makes the Hardcoded plugin work with the CSRF middleware Does this sound like the right solution?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
this might be realted with this issue
Although the cookie is set (and set) the handler will reject the hardcoded login (POST at
./auth/page/hardcoded/login):The text was updated successfully, but these errors were encountered: