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

Login flow should know about session cookie #146

Closed
chvp opened this issue Oct 1, 2021 · 3 comments · Fixed by #155
Closed

Login flow should know about session cookie #146

chvp opened this issue Oct 1, 2021 · 3 comments · Fixed by #155
Assignees
Labels
bug Something isn't working

Comments

@chvp
Copy link
Member

chvp commented Oct 1, 2021

Due to the SameSite=strict modifier on the session cookie, zauth doesn't know that the user is logged in when the user is redirected from another site. The easy fix is to change the SameSite modifier to Lax. To be more secure, we should land the flow on a confirm page ("Are you sure you want to log in to Haldis?"). A yes click on this confirm page make the second request a samesite request, so zauth should pick up that the user is logged in at that point, so the user is not required to login again.

@chvp chvp added the bug Something isn't working label Oct 1, 2021
@chvp chvp self-assigned this Oct 1, 2021
@redfast00
Copy link
Member

I quite liked one-click login, and for our usecase, I think it would be acceptable to have Lax SameSite.

Another solution is to make the sessions of client applications longer, but this will have to be done for every application individually.

@rien
Copy link
Collaborator

rien commented Oct 3, 2021

I think having an extra click doesn't do much harm (this is what most providers do). While you are correct that the possibility something bad can be done this way, I prefer to stay on the safe side here. Defense in depth and all.

I have tried to come up with scenario's where someone would be able to do harm. The best I can currently come up with, is that you can log someone in to a certain application without interaction.

E.g. suppose Tab has a XSS vulnerability where someone would be able to craft a transaction which would instruct your browser to send the contents of your wallet to the attacker (crazy example which could never happen cough).

  • The attacker could link or redirect your directly to Tab. But if the user does not have an active session on Tab, they would have to interact with the site and click "log in" before the XSS would be triggered after logging in.
  • The attacker could link or redirect you to https://adams.ugent.be/oauth/authorize?client_id=tab&redirect_uri=https://tab.zeus.gent/callback. With lax cookies, this would immediately pick up your Zauth session, redirect you back to Tab with an authorization code, log you into Tab and trigger the XSS. All without interaction.

@chvp
Copy link
Member Author

chvp commented Oct 7, 2021

Conclusion after an in-person discussion was to add the extra page. I'll try to do so this weekend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants