Please read my following statements and tell me if they are true or false for persistent cookies:
Session and cookie are created when user logs in.
Session is created with a unique id which is stored in the cookie.
By default, a cookie stores session id only. If a developer wants, then he can store other information in that cookie with session id.
Session variables, if any, are removed from server memory after the session is expired or user logs out but the session id is still in the cookie.
If its true, then what is the use of session id ?
After this, user would again logs in and the cookie is replaced with a new session id. Right ?
After the cookie is expired, the session id is removed from cookie and the cookie is deleted.
For security purpose, the session must be expired before cookie. In this way, user is forced to authenticate himself and logs in to confirm its identity again.
What's the purpose of the cookie? The server has to be able to recognize which session belongs to which client. So the SessionID is provided to the client, and communicated back and forth via cookie (or via QueryString if cookieless authentication is enabled, but that isn't recommended).
User logging in or out doesn't necessarily change the SessionID. To do that, you'd need to call Session.Abandon().
Related
We have two factor authentication in place to login into our system.
User has to login using username/password.
In the next page, user has to answer security questions to successfully login into our application.
We are creating multiple sessions upon user successfully authenticated in step #1. This session information will be used across the application.
I have used below peace of code to handle session fixation issue:
When user browse the application login page, I am deleting the sessionid in the session-cookie using below code in the page load.
if(!IsPostBack)
{
HttpContext.Current.Session.Clear();
HttpContext.Current.Session.Abandon();
HttpContext.Current.Session.RemoveAll();
Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", ""));
}
The above code will empty the sessionid in the session cookie. Now when user enter the appropriate credentials asp.net will create new session id automatically, so browser will get new session upon successful authentication. If user entered wrong credentials then using above code i am resetting the sessionid again so the new sessionid will automatically generated up on successful authentication.
This approach worked fine for single factor authentication and session fixation was no more a defect in security reports. But with multi factor authentication still it is an issue. I couldn't use above code to reset the cookie sessioid in the page where i am verifying the security answers as the application loosing all the session variables created in step #1.
As a work around in #2, after answering security questions successfully I have tried to save session values in the temporary object and reset the sessioid in the cookie and reassigning the object to session variables again, but sessionid is not regenerating at this point of time so i coudln't re save the session and application started throwing the exceptions wherever those session variables being accessed.
Below is the event triggered up on successful authentication in step #2 page
private void Sucess()
{
login = Session.logininfo
HttpContext.Current.Session.Abandon();
HttpContext.Current.Session.RemoveAll();
Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", ""));
Session.logininfo = login;
Response.Redirect("New.aspx", true);
}
May i know is there any better way to update the session cookies in this case.
I'm exploring cookies and sessions [I'm using them with respect to ASP.NET C# microsoft framework]
Learnt how sessions and cookies work here and here.
My take on it is like,
Once a user logs in and establishes a session, he or she is given a session id to track them further.
Also, this sessionId can be stored on a Server, like SQL Server or a InProc, meaning it is stored on the issuing server or on a cache, Redis Cache.
My question is like,
I can understand that the sessionId is stored in a memory and being sent with every request (since HttpSessions are stateless) as HttpHeaders.
When we talk about storing sessions in a memory, which memory are we talking about ?
If we are storing them in a cookie, what If I go and modify the cookie ?
If I can modify them, what If I change the sessionId and supply in a new sessionId ?
1. When we talk about storing sessions in a memory, which memory are we talking about ?
Ans: InProc mode, which stores session state in memory on the Web server (RAM). This is the default.
2. If we are storing them in a cookie, what If I go and modify the cookie ?
Ans : Only session id is stored in cookie. If you don't want to use cookies for session tracking, asp.net framework also supports it by appending it in the URL. If you change the cookie value, the server will not be able to identify the request with the stored session data. You need to understand the http is a stateless protocol, sessionid is the identifier of a browser for the request during roundtrips. If you change the cookie value, server will not be able to identify the request.
By luck if you supply a valid sessionid, server will serve the content stored in session against that id. This is called session hijacking
https://en.wikipedia.org/wiki/Session_hijacking
3. If I can modify them, what If I change the sessionId and supply in a new sessionId ?
Ans: If you are taking about the SessionId of System.Web.SessionState. It can't be changed as it is readonly. But you are free to change anything at the client side (Cookie or URL)
Namespace: System.Web.SessionState
Assembly: System.Web (in System.Web.dll)
public string SessionID { get; }
The session data is stored on the server, either in memory or in a database. This data is looked up with a sessionId that is stored in a cookie.
2/3. Modifying the sessionId is known as session hijacking, and allows you to "be" that user. This is commonly exploited with attacks like cross-site scripting (XSS).
To protect against hijacking make sure that:
The cookie is encrypted. There are ways for ASP.NET to do this for you, but this way it cannot be tampered with
The cookie is set to HttpOnly. This ensures that the cookie can only be sent over http requests and things like javascript - and thus XSS attacks - don't have access to the cookie.
If you are using something like ASP.NET Session State, change the default name of the cookie so it is not easily recognizable
I'm using the standard Authentication middleware in my Startup.cs file like this:
services.AddAuthentication("auth")
.AddCookie("auth", options =>
{
options.LoginPath = new PathString("/account/index");
options.AccessDeniedPath = new PathString("/account/forbidden");
options.SlidingExpiration = true;
});
I want to be able to display a "Your session has expired" message on my login page once the user is redirected there because of an expired session. And obviously not have it there when a new user is visiting the page.
By the looks of it, the Authentication middleware simply checks for a 401 passed from another middleware and changes it to a 302 to my desired location, leaving me no chance of differentiating between those two.
Can I achieve this differentiation by using the standard .net core 2.0 libraries, or should I go for a custom implementation instead?
If you want to detect whether or not the user was logged in, you could set a second unrelated Session cookie saying that the user HAD a session. Do not store any other information in the cookie. Let's call this a 'Flag' cookie.
When the user logs in, you create both a session cookie and a flag cookie. The session cookie can expire whenever you set it to, and the flag cookie should never expire. Lets say after 30 days, you are automatically logged out of your account - the session cookie should expire. Because you still have the flag cookie but not the session cookie, you can check on each page if you have the flag cookie when no session cookie is present.
If the Flag cookie exists but the actual session cookie does not, you can redirect to the login page and inform them that their login session has expired. I'd be sure to delete the cookie once you get there too so that every time they load a page they aren't redirected to login. This means the message will only show once to the user so they can still try visiting other pages on the site afterwards without being redirected should they want to browse (for example the homepage) but not want to log back in. If they attempt to access an authenticated page, they should be prompted for credentials again
Normally I would handle a logged in user by setting a session after a successful login. That session is then checked on each request to ensure it exists.
But was about if I disabled a user account and they were currently logged in? In that case, the user would still have access to the system until their session expired.
Currently, I am pulling the account information from the database on every request and checking the status field. I feel this is a lot of unnecessary overhead. In my scenario, there are accounts and users within those accounts. Therefore, I'm having to check the account status as well as the user status on each request.
Is there a better way? Note that I'm using SQL Server Session State as this a multi-server environment.
Thanks in advance.
Store the session ID's in the database on session start. When you disable a user just remove the value in the user session id field in your database.
Check if the session id matches the stored session id in your database on requests.
If not, session.abandon().
When you disable a user account, why not remove any sessions associated with the account. Then we user accesses the server, the session will no longer exist and user will not have access.
You can use cookies ! Cookies are most powerful light weight data
storage ! store encrypted username information & state(active/deactive)
into cookies.
Instead of storing the data on each request, after the first request, you can implement a method like AuthenticationManager.IsAuthorized("user name"). This method should return two values:
True/False (If it's authorized or not, respectively).
Reason as an enumeration: UserBlocked, Timeout, ...
Thus, you'll be checking if the session is still valid on every request and the user data will be retrieved once per session start.
You can use Anonymous Identification if enabled with in your Application:
<anonymousIdentification enabled="true"/>
and you can get it like:
string strId = Request.AnonymousID;
where default it's Guid.
AnonymousId is unique for each user and you will keep track of your users as they IsAuthenticated or not.
What is the difference between a Session and a Cookie?
What circumstances should each be used?
Sessions
Sessions are stored per-user in memory(or an alternative Session-State) on the server. Sessions use a cookie(session key) to tie the user to the session. This means no "sensitive" data is stored in the cookie on the users machine.
Sessions are generally used to maintain state when you navigate through a website. However, they can also be used to hold commonly accessed objects. Only if the Session-state is set to InProc, if set to another Session-State mode the object must also serializable.
Session["userName"] = "EvilBoy";
if(Session["userName"] != null)
lblUserName.Text = Session["userName"].ToString();
Cookies
Cookies are stored per-user on the users machine. A cookie is usually just a bit of information. Cookies are usually used for simple user settings colours preferences ect. No sensitive information should ever be stored in a cookie.
You can never fully trust that a cookie has not been tampered with by a user or outside source however if security is a big concern and you must use cookies then you can either encrypt your cookies or set them to only be transmitted over SSL. A user can clear his cookies at any time or not allow cookies altogether so you cannot count on them being there just because a user has visited your site in the past.
//add a username Cookie
Response.Cookies["userName"].Value = "EvilBoy";
Response.Cookies["userName"].Expires = DateTime.Now.AddDays(10);
//Can Limit a cookie to a certain Domain
Response.Cookies["userName"].Domain = "Stackoverflow.com";
//request a username cookie
if(Request.Cookies["userName"] != null)
lblUserName.Text = Server.HtmlEncode(Request.Cookies["userName"].Value);
sidenote
It is worth mentioning that ASP.NET also supports cookieless state-management
Cookie is a client side storage of your variables. It stored on client machine by browser physically. It's scope is machine wide. Different users at same machine can read same cookie.
Because of this :
You should not store sensitive data on cookie.
You should not store data that belongs to one user account.
Cookie has no effect on server resources.
Cookie expires at specified date by you.
Session is a server side storage of your variables. Default, it stored on server's memory. But you can configure it to store at SqlServer. It's scope is browser wide. Same user can run two or more browsers and each browser has it's own session.
Because of this :
You can save sensitive data in session.
You should not save everything in session. it's waste of server resources.
After user closes browser, session timeout clears all information. (default is 20 minutes)
A cookie is an identifaction string stored by a server (who has a domain) in the browser of the user who visits the server/domain.
A session is a unit of maybe variables, state, settings while a certain user is accessing a server/domain in a specific time frame. All the session information is in the traditional model stored on the server (!)
Because many concurrent users can visit a server/domain at the same time the server needs to be able to distinguish many different concurrent sessions and always assign the right session to the right user. (And no user may "steal" another uses's session)
This is done through the cookie. The cookie which is stored in the browser and which should in this case be a random combination like s73jsd74df4fdf (so it cannot be guessed) is sent on each request from the browser to the server, and the server can assign and use the correct session for its answers (page views)
The cookie allows the server to recognize the browser/user. The session allows the server to remember information between different page views.
Sessions are not reliant on the user allowing a cookie. They work instead like a token allowing access and passing information while the user has their browser open. The problem with sessions is that when you close your browser you also lose the session. So, if you had a site requiring a login, this couldn't be saved as a session like it could as a cookie, and the user would be forced to re-login every time they visit.
Its possible to have both: a database primary key is hashed and stored in a lookup table: then the hash is stored on the client as a cookie. Once the hash cookie (hahhahaha :) is submitted, its corresponding primary key is looked up, and the rest of the details are associated with it in another table on the server database.
The main difference between cookies and sessions is that cookies are stored in the user's browser, and sessions are not. This difference determines what each is best used for.
A cookie can keep information in the user's browser until deleted. If a person has a login and password, this can be set as a cookie in their browser so they do not have to re-login to your website every time they visit. You can store almost anything in a browser cookie.
Session is a server side object,
which transfer or access data between page call.
Cookies is a object which is client side/client machine which store some text information of browser and server.
There appears to be some confusion regarding what a session cookie is.
Firstly, when we are talking session cookies - it has nothing to do with ASP.Net sessions. Likewise, session cookies have nothing to do with server side processes or caching.
A session cookie is nothing more than a cookie that expires when the browser session expires. To create a session cookie - don't put an expiration date on it. Doing this stores the cookie in memory and is disposed of when the browser is disposed.