Session management used here: `go get github.com/alexedwards/scs/v2@v2`
Session ids should be meaningless. The server side stored information can typically include:
- the client IP address
- User-Agent
- e-mail
- username
- user ID
- role
- privilege level
- access rights
- language preferences
- account ID
- current state
- last login
- session timeouts
- and other internal session details.
The preferred session ID exchange mechanism should allow defining advanced token properties, such as the token expiration date and time, or granular usage constraints.
- Cookies foot the bill which is why they are used.
- the Secure cookie attribute must be used to ensure the session ID is only exchanged through an encrypted channel.
- Do not switch a given session from HTTP to HTTPS, or vice-versa, as this will disclose the session ID in the clear through the network.
- When redirecting to HTTPS, ensure that the cookie is set or regenerated after the redirect has occurred.
- Do not mix encrypted and unencrypted contents (HTML pages, images, CSS, JavaScript files, etc) in the same page, or from the same domain.
- HTTP Strict Transport Security (also named HSTS) can be used to enforce HTTPS connections. Can also https://www.leviathansecurity.com/blog/the-double-edged-sword-of-hsts-persistence-and-privacy result in user tracking even without cookies.
- It is important to emphasize that TLS does not protect against session ID prediction, brute force, client-side tampering or fixation; however, it does provide effective protection against an attacker intercepting or stealing session IDs through a man in the middle attack.
### Cookies
- `Secure`attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection.
- protects against man in the middle
- The `HttpOnly` cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object.
- This session ID protection is mandatory to prevent session ID stealing through XSS attacks.
- XSS + CSRF though could still leak the session id.
- `SameSite` defines a cookie attribute preventing browsers from sending a SameSite flagged cookie with cross-site requests
- The `Domain` cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains.
- THE DOMAIN ATTRIBUTE SHOULD NOT BE SET, which will restrict the cookie to the origin server.
- You don't want to mess with cross subdomain cookies. That can just be a mess.
- The `Path` cookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application
- `Path` attribute should be set as restrictive as possible to the web application path that makes use of the session ID.
- Session management mechanisms based on cookies can make use of two types of cookies, non-persistent (or session) cookies, and persistent cookies. If a cookie presents the `Max-Age` (that has preference over `Expires`) or `Expires` attributes, it will be considered a persistent cookie and will be stored on disk by the web browser based until the expiration time.
- Typically, session management capabilities to track users after authentication make use of non-persistent cookies. This forces the session to disappear from the client if the current web browser instance is closed.
- Therefore, it is highly recommended to use non-persistent cookies for session management purposes, so that the session ID does not remain on the web client cache for long periods of time, from where an attacker can obtain it.
- Depends on what the application does. An RSS reader doesn't need a short lived session.
If we look at reddit cookies we can find one called `token_v2`.
