In order to mitigate potential Session Fixation/Trapping attacks, we need to be able to transfer the ASP.NET session state from one session Id to another after a user successfully logs in. A user has important session information before login that needs to be transferred, so we cannot just call Session.Abandon or Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", "")) as all the session state is lost. We can use System.Web.SessionState.SessionIDManager to call CreateSessionID() and then SaveSessionID() to generate a new ID, but again, the prior state is lost on the next request. So my question is basically how to transfer/correlate session state from a pre-login session Id to a post-login session Id.
There are multiple articles and posts around that explain the potential issues with using Session state. The most obvious is problematic support for multi-server environments.
If you store the items that you're currently putting in Session[]in a database or use SQL-based sessions, "transferring" is simply a matter of associating a user or connection with a particular record set.
If you bypass the Session object and handle everything yourself, which is a trivial task if you want to maintain the simple Session[] key-value interface, you get a number of benefits, such as settings that persist between sessions and across applications (as long as they share a common database).
Related
What we have currently implemented works well but I'm just concerned that there maybe a better way or we are doing it completely wrong.
Once logged into our website, on each and every request it will make a request to the API to get the users details.
E.g. Username, ImageUrl, Roles / Permissions, Email Address etc
It then stores this data in the BaseController for the viewpage or anyone else to see during that request.
Upside:
to doing it this way is that you know each request that the users permissions/roles and their details are all up to date!
Downside:
Your most likely to get exactly the same data every request, until that one day they change their details. Thus your possibly making unnecessary calls??
However the first way we tried all this was when the user logged in all their data gets stored in the cookie, the problem with this is that our users hardly ever logout so all the data that is stored in the cookie gets stale often. -> Stale Roles/Permissions is an annoying issue!!!
How does everyone get around the stale data from login.
I would go back to your initial approach of storing the claims inside the cookie.
If you do indeed have very long log in times then I would guard against stagnant claims by periodically refreshing the cookie.
If you are using forms authentication then you could intercept the FormsAuthentication_OnAuthenticate event in Global.asax, decrypt and manage the cookie (here), validate the user and cookie first then run a quick conditional check against a custom field in the userdata property, called refreshedDate.
If the last refresh date or creation date is greater than some configurable window then call to the database and refresh the claim data from the database. Finally update the refreshDate and claim data and update the cookie.
Update
Following on from your comment...
Just to say that it is not uncommon to hit the database for each request, that is to say I have known it happen in a number of production systems. Many people are probably using ASP.NET session state using MS-SQL database's. Typically I have seen it when there is a real security need to invalidate someone's session, deny access and log them out immediately.
If your database is on the network locally to your web servers and/or latency is acceptably low then it can be a perfectly workable solution. Just make sure your database queries are minimal and performance tuned to perfection, consider side steeping any ORM (if applicable) and use raw SQL connections to make things as fast a possible.
If database latency is high, the other middle ground solution is caching, using Redis or Memcached to house the results of your queries and invalidating the cache when permissions are altered etc... but obviously adding the required infrastructure and operational support for caching solutions is a serious consideration.
You can apply an expiration to the cookie; that way it dies and requires them to login. Or, keep their user ID in the cookie, but store their profile info in session. When session dies, the next time the profile is checked if it is null, make a query to the API again. This way, it's getting updated more frequently.
In addition to other suggestions, another option may be to use a notification mechanism from the underlying role/permission store whenever a user's data changes. This notification could then be used to invalidate the cached data on the web server. This would ensure that the cached data is returned in the majority cases but the store would then be hit only when the data had changed.
If the underlying datastore is SQL Serevr then consider something like SqlDependency.
This is obviously a more complex architecture but it would meet your requirement and only you could say whether it's worth the effort / complexity / tradeoff!
I was revising the concept of Session Objects in JSP & ASP.Net.
I was confused, 'when an actual Session Object is created?'
Until recently I thought it was created when a user logs into his account, But now I read in the books that its implicitly created when the user visits any page on your site.
So when is it actually created? And are JSP sessions different from Website User Account sessions?
If the latter is correct, Is a second new Session created when a user actually logs into his account, and the previous session destroyed?
eg: A shopping site may allow a user to select many items & 'Add to My Cart'. What happens to this data after he logs in. Is a new session created internally after destroying the initial one?
If this seems confusing, then you can just specify how Session is typically implemented in real-world systems (as I'm a student)? When is the session typically started? What data is stored in it? What is the typical timeout you set and why?
My research: JSP sessions are abstract concepts and User account sessions are implementation specific. Both are different
A session is typically implemented by
generating a unique token,
creating a Session object to hold session data and store it in a map, indexed by the unique token,
sending a session cookie containing this token to the browser.
Each time a request comes in from this browser, it contains the cookie, and the container can thus retrieved the appropriate session from its internal map of sessions.
So yes, a session can exist before a user is authenticated, or even without authentication at all. And when a user is authenticated, he keeps the same session. The only difference is that you typically add the user ID in the session, in order to associate the user with the session.
You could thus, for example, let aninymous users shopping and add items to their cart in the session, and only ask them to authenticate once they need to pay (to retrieve their stored account). Or you could let them add items to their cart, and never authenticate them at all.
response.Cookies( SOFTWARE_PROGRAM_NAME).Expires = datetime.now.adddays(365*10)
this sets expiration for 10 years.
Anyway to set it for unlimited?
Cookies were intended to store temporary state information, like a token that identifies a shopping cart or user authentication session. User's can of course easily delete your cookie by clearing their browser cache anyway. If you want a cookie that lasts forever, you are never going to get it, and its not what cookies are for. If you want to store user-based information permanently, consider storing it in your database or other server side storage.
From RFC2109:
There are, of course, many different potential contexts and thus many different potential types of session. The designers' paradigm for sessions created by the exchange of cookies has these key attributes:
Each session has a beginning and an end.
Each session is relatively short-lived.
Either the user agent or the origin server may terminate a session.
The session is implicit in the exchange of state information.
I.e. cookies must expire because each session has a beginning and an end.
I'm fairly new to using Forms Authentication and am trying to wrap my head around how this all works. Basically, what I'd like to be able to do is store some user data that is associated with the FormsAuthentication ticket (data that comes back from my ldap server); however, I don't want to actually store this data in the cookie as it could be a rather large amount of data. Is it somehow possible to store this information in memory on the server, but keep it strongly tied to the ticket so that if the user times out or is logged out the data is destroyed as well. I realize I could use session variables to do this, but this seems awkward as I'd have to manually clean up the session variables if the user logs out. Is this possible or does this even make sense to do?
Why would you have to manually clean up a Session? The entire purpose of the Session dictionary is to allow you to do exactly what you want to do here: associate some known data with the user's current browser session. When the user's browser session ends for whatever reason, the HttpApplication and its Session are orphaned and GCed. So, I would just put your LDAP data into Session under a key, or set of same, and forget about it.
The Setup:
Account controller with the typical logon / logoff stuff that comes baked in from the template. Not much modification here on the logon page. Using a custom membership provider (SQL), but I don't think that is impacting what I am trying to do here.
The Requirements:
The client wants to handle licensing by limiting concurrent users and not by total users. So, after referencing this post here, I set out to make this work for what I need to do. And that is to track maximum and current users for each organization that has signed up for our application. No problem, just have an application("max") and application ("current") which are both hashtables with the key being the organization id and the value being current or max users for the organization. On Session_Start, I would increment the current users, check if it exceeds max and either a) redirect to an error page or b) let them go on with what they need to do. On Session_End, I would decrement the count.
The Problem:
When using formsService.signIn, what is actually stored in session? I cannot seem to gather any information about my session in the session_start except for the session ID. So, I cannot increment the correct number for user tracking. And I cannot add a variable to session as session_start will have already fired before I get the opportunity.
The notion that session is somehow connected with authentication is a myth. They are entirely independent of each other. Session can even be shared between multiple users if they happen to share their session key; that's why you never put security-sensitive info in session. Session can also expire while you're logged in. Likewise, your session is still active after logout unless you explicitly abandon it.
Session is more like a user-specific cache.
So you need to accept this fact and adapt to it. Look and see if the current user is authenticated during session start. You'll need to increment during logon as well, since the session will have already started. Etc.