Menu
I learned that for session-based authentication, the session id is normally stored in the browser's cookie and will be sent back to the server on each request.
And I guess there are multiple avenues for sending session IDs (cookies, headers, request bodies, URLs, etc) So what are the implications or tradeoffs for storing session ids in cookies or HTTP headers or request bodies or even URLs?
276
Session identifiers can be stored in cookies, localStorage, and sessionStorage. Session identifiers can be sent back to the server via cookies, URL params, hidden form fields or a custom header. Additionally, a server can accept session identifiers by multiple means.
An easy way to make sure that sessions continue to work properly is to store sessions in a central database that is common to all servers. The application needs to be able to run on a shared host, where there are significant security concerns associated with storing session data in the filesystem.
By storing a session ID you can identify different sessions of the same user, and you may want to handle them in any special way (e.g. just allow a single session, or have data that's associated with the session instead of to the user).
Session IDs are usually just a random (opaque) identifier that is passed between the client and the server. The server uses the identifier to look up state information (e.g. current cart content) in the database.
The server (with enabled session handling) checks whether a Cookie is attached to a request, and if not, returns a Set-Cookie header, typically containing a session ID. The browser picks this up and will now subsequently pass the session ID as a Cookie back to the server.
Session data itself is usually not any more sensitive than the rest of the contents of the database. Store them on the filesystem in plaintext. If your threat model suggests SQLi is more likely than filesystem access, this is an easy move.
There's no need for a separate ID token. Just hash the session token and pass the hash digest to the DB (e.g. SELECT * FROM Sessions WHERE hashed_token = ? ). You can, if you want faster lookups, create an index on the sessions table (though that makes creating and deleting sessions more expensive).
Assuming we are talking about a common web app, the server can just set a cookie itself, which is a very transparent process: your frontend code don't need to read this token when authenticating, store it locally, and forwarding to each request than needs it manually. All things that could go wrong. The server will set it, and the browser will send it back as part of the headers for all your subsequent requests.
Until too long ago, this was also an issue, with csrf attacks that had to mitigated in some way, to be sure that any requests sent with the appropriate session id was actually legit, and not the result of some random site maliciously crafting post requests. With the samesite option, cookie are sent by the browser only after verifying the origin of the request.
From a security lens, cookies set with httponly aren't accessible via javascript. The typical alternative of storing tokens is the local storage, but as soon as an xss vulnerability happens, that token may be compromised.
You also typically want to avoid sending tokens as part of the querystring in your requests. While urls aren't visible in a normal https request in transit, your webserver of choice may log those request, in a file, that will contain sensitive information that shouldn't be there. They may be shared by user accidentally by copy/pasting the url as well.
193
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
