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.
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).
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: Strictbecause both pieces of information are only relevant for your app.HttpOnlybecause they will only be altered by server side responses.Secureso 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.