I've been reading about sessions, both client and server side as well as few attacks possible on them. I'd like to know what are the practical solutions to the following problems related to sessions
Race condition between two request trying to change the session variables
When session ids are regenerated, what happens to the slow requests that reach the server with older session id
For your first question, see here for how ASP.NET handles this - "Synchronizing Access to the Session State":
What if other pages attempt to concurrently access the session state?
In that case, the current request might end up working on inconsistent
data, or data that isn't up to date. Just to avoid this, the session
state module implements a reader/writer locking mechanism and queues
the access to state values. A page that has session-state write access
will hold a writer lock on the session until the request terminates.
For your second question this would be down to your code regenerating the session identifier at a suitable point. For example, to avoid session fixation it is good to regenerate the session identifier upon login. At this point there should not be other, slow requests being made to the server, so therefore this is an optimal time to issue a new identifier.
In other situations it may be appropriate for your application to recognise expired session identifiers for a short time, and associate them to the new identifier until all connections have been closed.
Related
I am currently running into an issue of concurrent requests, NodeJS, with access points to a cookie that holds information that I attain from a server. The thing is the requests being made are asynchronous, and need to remain that way, but I am in charge of asking for the new data sets when the cookie is about to become stale. How do i keep updating the cookie without bogging the server down with requests for a new cookie, if multiple concurrent requests all assume that they are the ones that should be in charge of refreshing the cookie's value.
I.e. Req1->Req30 are fired off. In the process of handling Req17 the cookies time to live is caught so it sends out the refresh command. The thing is Req18->Req30 all assume that they should be the ones to refresh the cookies value, because they also do the staleness checks and fail in that respect.
I have limited ability to actively change the server side code, and due to the sensitive nature of the data cannot readily decide to place it in a DB because at that point, I become charged with ensuring that the data is again secured.
Should I just store multiple key/values in the cookie, and iterate through them, this could become an expensive operation. Also could overwrite the cookie with invalid data on some request, since to update the cookie and append the new key value pairs requires creating a new one, due to immutability with the cookies themselves.
To handle concurrent access on the cookie :
Use of timestamp; only perform the change if the data is more recent
To handle cookie data renewal :
Instead of having workers to perform the check of new data concurrently. Ask one specific worker to handle data update, meanwhile others workers use the data in read only mode.
Scenario:
We are using azure redis session provider. When page first loads, retrieves the data from external API and stores them in redish session.
The same session data is retrieved via different pages and components with in user session. The question is:
Does application gets the session data only once and stores locally http current context? Or everytime it goes to redis store?
What if we are encrypting the data on set and decrypt the data on Get operations?
Thanks.
Application gets the session-data from Redis everytime you ask for it... for the writing part, you'll have to wait until the dictionary key is unlocked. See https://msdn.microsoft.com/en-us/library/aa479041.aspx#aspnetsessionstate_topic3 assuming you are using asp.net for this
A page claims write access to the session state by setting the EnableSessionState attribute on the #Page directive to true. (This is the default setting.) A page, though, can also have read-only permissions on the session state, for example, when the EnableSessionState attribute is set to ReadOnly. In this case, the module will hold a reader lock on the session until the request for that page finishes. As a result, concurrent readings can occur.
If a page request sets a reader lock, other concurrently processed requests in the same session cannot update the session state but are at least allowed to read. This means that when a session read-only request is being served, awaiting read-only requests are given higher priority than requests needing a full access. If a page request sets a writer lock on the session state, all other pages are blocked, regardless of whether they have to read or write. For example, if two frames attempt to write to Session, one of them has to wait until the other finishes.
StackExchange.Redis is just a wrapper (or a abstraction) for the HttpSessionState Module
I have the following scenario:
A user logs in, a session entry via connect-redis which is valid for 2 weeks. The user can now access certain parts of the app using the session id that is stored in the app.
Now, if 1. the user deletes that cookie in the browser (with the session) and 2. logs in again - there are now 2 session entries in Redis associated with the same user, with the older one being obsolete.
What is the best way to deal with such old/obsolete sessions? Should I use a client library for redis, search through all sessions to find the ones that match the info of the currently logging in user (after she potentially manually removed the cookie), and purge these obsolete session; or is there a better way?
Gracias,
nik
That depends whether this (user deletes the cookie) is a common scenario and, if it is, whether there's a problem with obsolete cookies in the server.
Two potential "problems" that I can think of are:
Security - could the stale cookie be exploited for malicious intent? I do not see how that's possible, but I may be wrong(tm).
Storage - are the stale cookies taking too much (RAM) resources? If there's a lot of stale cookies and each cookie is large enough, this could become a problem.
Unless 1 or 2 applies to your use case, I don't see why you'd want to go through the trouble of "manually" cleansing old cookies. Assuming that you're giving a ttl value to each session (2 weeks?), outdated cookies would be purged automatically after that period so no extra action is needed to handle these.
We modified our Session handling from cookie based to URL Rewriting. By doing this the session id gets transmitted as part of the URL.
Now there is a vulnerability issue, where whoever uses this URL will be able to log in into the system.
To resolve this issue we have done the following
[1] A HTTP Session Listener has been created to maintain list of HTTP sessions.
Listener reacts on the events when session are created or destroyed.
[2] A Session Filter has been created to verify HTTP Session and check its integrity against HTTP Request attributes
Session will be invalidated in case Request attributes (identifying the client origin) do not match original attributes stored with session. (to block the session hijack attempt)
However i think that this has a gap, when you are trying to access over a proxy etc.
Is there any other effective solution for this?
Also we cannot use third party libraries to resolve this because of the nature of the produce.
So you need to be doubly careful with session ID likes this: users share URLs! The definitive advice on the subject comes from OWASP:
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
But I think you should consider the following additional controls:
Rotating the session key on each request. This is only practical with simple web applications though. It'll cause problems undoubtedly with AJAX and might be difficult to manage if the user is likely to open a second tab on the application.
Shorter timeouts.
I am presuming that in the 'HTTP Request Attributes' you mention you are already picking up the User-agent, source IP address and invalidating the session if these are inconsistent.
If you are using SSL it might be possible to do a great solution where the session ID is tied to the SSL connection (Apache, for example, exposes this in a SSL_SESSION_ID environment variable). But this information might not be available to your application.
I am using node.js + redis for session persistency, however I'm noticing that in nearly every example of redis store or other session persistence, there is a static maxAge or timeout for sessions that you can configure.
It makes sense to me that the session length should be based on the last interaction, and thus allow me to make an update on the timeout. Redis's documentation on its EXPIRE documentation has a section on refreshing the timeoutl
Is refreshing the session timeout bad by design? Should static timeouts always be used?
Edit
My original question was very general since I couldn't find documentation for my specific case and I assumed perhaps it was bad practice! I finally discovered how to do this with Connect + Node after looking at the source code:
Connect listens to the header end event (to know to update the session)
When the event fires, it asks the session store to save the session
Specifically as part of connect-redis, the save method updates the maxAge
In short, I was looking at the wrong place for documentation. Connect#session documents how if maxAge is assigned a new value, session stores (like connect-redis) should honor that.
There is no such thing as bad design, only bad choices.
Static Max Timeout
A good choice where security is of the utmost importance. Using a tight session timeout, especially with authentication, ensures that the end user is the intended user and not someone who dropped in while the principal user was away from his/her pc or device. The major downside to this approach is negative impact to user experience. The last thing you want is the session going stale just before the user was about to checkout or do something important; with a static timeout, this is inevitable and will happen often enough to piss off users.
Reset Timeout Based on Last Visit
It's safe to say most websites use this approach since it offers a good balance between security and user experience. Resetting the session timeout based on last visit eliminates the issue related to static max timeout, and most ecom and banking websites use this approach, so it's certainly an accepted approach.
Not knowing what you're actually building, I'd say going with the reset approach is probably a good choice nonetheless. The examples you mentioned likely omitted resetting the timeout for brevity reasons, not because it's a bad design.