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

Cookies: stricter settings and conflicts with other apps #116

Open
unixerius opened this issue Jun 12, 2024 · 0 comments
Open

Cookies: stricter settings and conflicts with other apps #116

unixerius opened this issue Jun 12, 2024 · 0 comments

Comments

@unixerius
Copy link

unixerius commented Jun 12, 2024

Good day!

I'm running a PoC with both WriteHat and SysReptor, to compare their feature sets, user friendliness, etc. They are both hosted on the same Docker host for the duration of this PoC. In testing I noticed that logging in to one of these would automatically invalidate my current session in the other tool, and vice versa.

After some messing around with BurpSuite and some web searches I'm reminded that this happens in accordance with RFC6265 (HTTP state management).

  • Both WriteHat and SysReptor share the same FQDN.
  • Both tools use cookies with the names "csrftoken" and "sessionid".
  • Due to RFC6265, these cookies are treated as one and the same.

I realise this is a "me" problem, not a "you" problem. Your code operates according to the RFC and your Docker deployment process means the code won't even be aware of the actual FQDN and Origin (proto://fqdn:port) it will be reached upon.

For me, my solution should be to ensure that the NGinx proxy is set up with a separate virtualhost / FQDN for each of the ingresses towards these two tools.

That being said, there is a feature request I have for you. :)

Would you potentially consider setting the following flags for both your CSRFtoken and your SessionID cookies?

  • SameSite: Strict because both pieces of information are only relevant for your app.
  • HttpOnly because they will only be altered by server side responses.
  • Secure so the are only transferred/accepted across HTTPS.
  • Path: ${yourpath}, potentially set based upon a new configuration parameter, defaults to /.
  • Domain: ${fqdn}, set based upon an existing configuration parameter.
  • Expires: ${desiredtime}, so the session persists even if a tab is closed, but it's also not without limitations. Ideally max 4-8h unless renewed during the session.
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

1 participant