-
Notifications
You must be signed in to change notification settings - Fork 28
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
portal-api: Bypass CSRF protection for login route #340
Conversation
Allowing login from simple HTML form Also allow to pass username/password as two params instead of a combined "credentials"
@@ -272,13 +272,14 @@ def setup(self, app): | |||
name="login", | |||
method="POST", | |||
callback=self.login, | |||
skip=["actionsmap"], | |||
skip=[filter_csrf, "actionsmap"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm kinda confused ... I understand that basic, "raw" HTML form won't include the special X-Requested-With header ... but it looks like disabling this checks opens up the very security issue that this CSRF is supposed to prevent ... or would a CSRF token help fix the "raw" HTML form support, rather than relying only on X-Requested-With ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding: CSRF is a problem where you steal credentials from an authenticated user from another webpage. On the login/logout route, it should not have any security implications.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alrighty:
Definition. Cross-Site Request Forgery (CSRF) is an attack that forces authenticated users to submit a request to a Web application against which they are currently authenticated.
About CSRF in general, it's desirable to protect from such attacks. However, a header token is not the only approach. For actions where the user should be logged in, we can:
About the cookie policy, is it lax only because SSOWat needs to handle different domains? If so maybe we could workaround by having a cookie per SSOWat domain? |
Allowing login from simple HTML form
Also allow to pass username/password as two params instead of a combined "credentials"
Demo using my_webapp: