A) I assume Asp.Net allows you to reuse session identifier only if we operate in cookieless mode, but not if we use cookies to store session ID?
B) From my book:
By default, ASP.NET allows you to reuse a session identifier. For example, if you make a request and your query string contains an expired session, ASP.NET creates a new session and uses that session ID. The problem is that a session ID might inadvertently appear in a public place - such as in a results page in a search engine. This could lead to multiple users accessing the server with the same session identifier and then all joining the same session with the same shared data.”
I’m not sure I understand how reusing session identifier could cause session ID to appear in a results page in a search engine?
C) Continuing:
To avoid this potential security risk, it’s recommended that you include the optional regenerateExpiredSessionId attribute and set it to true whenever you use cookieless sessions. This way, a new session ID will be issued if a user connects with an expired session ID. The only drawback is that this process also forces the current page to lose all view state and form data, because ASP.NET performs a redirect to make sure the browser has a new session identifier.
Why needs Asp.Net to perform a redirect to make sure browser has a new session identifier? Couldn’t it just extract session ID from the URL and throw it away?
Thank you
A) No. When using cookie-based sessions, if a client sends an invalid session ID (from a stale cookie for example), the server will reject the ID, generate a new ID and send that value back in the cookie with the response.
Just to be sure I understand what you are saying:
When session is cookie-based and if you make a request, but your cookie contains a session Id of an already expired session, then server will generate a new ID?
But if session is cookieless ( thus ID is contained in URL ), then by default Asp.Net will create new session using that same ID?
C) The redirect is performed to ensure that the client received the new session id value and properly sends it back with the follow-up request. It's just a double-confirmation that occurs.
But why doesn’t it instead just put new Session ID in a URL and send it back. There must be a reason why this wouldn’t work and thus redirect is needed?!
A) No. When using cookie-based sessions, if a client sends an invalid session ID (from a stale cookie for example), the server will reject the ID, generate a new ID and send that value back in the cookie with the response.
B) When using cookie-less sessions, it's quite possible that a search engine could index a page with the session ID implanted in the URL. In this case, should a user click on the link from the search engine (and regenerateExpiredSessionid was 'true'), a new session would be created using the same ID. Subsequent users would also re-use the same ID should they click the link and if multiple users are browsing at the same time using the same ID, they would be overwriting each other's session values with each request.
C) The redirect is performed to ensure that the client received the new session id value and properly sends it back with the follow-up request. It's just a double-confirmation that occurs.
Related
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 have created an asp.net page which store user specific data in session variable.
string key= Session.SessionID;
Session.Add(key,"myData");
Till now I have been testing it on chrome and everything works properly. But as soon as I started testing it on IE 10, the functionality stops working. Later on I figured it out that on each post back the IE returns new value of Session.SessionID while this value is persistent in Chrome.
Please let me know how can I resolve this issue.
You need to enable cookies in IE.
Session works in this way - It depends on client cookie to uniquely identify a client, and it saves the unique value to cookie, and it depends on your web.config setting, if cookieless = false, then it stores in client cookie.
When request comes from a client, it gets your session stored (in server) value using that uniquely identifiable cookie.
If cookie is disabled, it will create new session each time for each request, that is why you are getting new session id every time in IE, as it might have cookie disabled.
I have a session variable which is accessed by multiple users through different pc's...so my question is do session variables overwrite when same login credentials are associated?
Session variables / objects are 'unique to users', also unique to browsers and are not over written by other users. You can read more about session state here.
Sessions are identified by a unique identifier that can be read by
using the SessionID property. When session state is enabled for an
ASP.NET application, each request for a page in the application is
examined for a SessionID value sent from the browser. If no SessionID
value is supplied, ASP.NET starts a new session and the SessionID
value for that session is sent to the browser with the response. Reference
Session Variables / Cookies are unique to Users/Browsers only. However you are confusing sessions with Application variables....which are Global to users. Sessions are generated via Webserver.
In my application every time a user lands on my website I check that user with it's session ID and make a insert(with all the details ip,browser etc) into the database if its a different session ID.
string sessionId = HttpContext.Current.Session.SessionID;
if (objDB.checkDuplicate("session", "sessionId", sessionId))
{
// code to make insert in database
}
But when checking database I am getting multiple inserts from same IP at the same time.
Can anybody explain why this happens?
NOTE : SESSION of the user is different so checkDuplicate() works fine but how can a user have a different session ID at the same time? (or such a sort span of time)
Most probably it's multiple people sharing the same connection over a router or proxy server.
More reasons (being behind router/proxy is most likely one) to have different session Id for same IP
restarting browser will make new session Id for the same user (as long it is set in session cookies)
opening separate browsing session (i.e. normal vs. private for IE, depending on configuration and browser tabs may be treated as separate sessions)
different users on the same computer
Another set of reasons for different session Id is based on failure to set persist session cookie between requests:
I think if there is no writes to ASP.Net session state cookie can be regenerated on every request (need to verify)
cookie could be disabled (rare, but possible)
cookie can be blocked (i.e. lack of P3P policy for pages/images in IFrame) or some other policy in browser
There are valid reasons to get multiple browser windows for the same sessionId for the same user (tabs in same "browser session", "open in new window/tab" with Ctrl+click ). You as site creator have to decide if you want to try to enforce "single session = single window" policy or deal with potentially multiple windows opened in the same session. There is no reasonable way I know to detect case when same session Id is used in different tabs, especially if you have to support GET requests (otherwise you can dump some addition ID into hidden field).
I am reviewing some web code and I am not exactly sure how ASP.net session state works. Any helps would be gratefully appreciated.
If a User object is saved to the session state during login, and User.FirstName and User.LastName is set. If other web pages retrieve the user object from the session and set the FirstName to something else is that persisted on other web pages? Or, do you need to re-add the user object back to the session once it has been modified? Thanks
Session is persisted on the server, but tracked via the client. I repeat - via the client.
In most cases, sessions are tracked with cookies. So using your example, when User object is saved to Session:
Session["UserInfo"] = new User { FirstName = "Joe", LastName = "Bloggs" };
A cookie will be sent to the client with a unique identifier. This cookie is passed along to all further HTTP requests from this client/browser unless it expires.
If another user comes along (from a different machine) for the first time, Session["UserInfo"] will be null.
An alternative to cookies is "cookieless-session" - where instead of using a cookie to store the session identifer - the identifier is tacked onto the URL.
So the answer is no - other web pages (e.g other clients/machines/browsers) will not have access to this information.
If you want information shared between different clients from the web server, use Cache.
However given the context of the question (User information), it is valid to store this information in the Session, as it is only relevant to a particular user (shouldn't be shared).
An alternative a lot of people use instead of sticking the User info in the session, is to put it in a generic principle which get's attached to the Forms Authentication ticket.
Up to you which road you choose.
This should help you get your head around Sessions in ASP.Net
http://www.codeproject.com/KB/aspnet/ExploringSession.aspx
http://www.codeproject.com/Articles/32545/Exploring-Session-in-ASP-Net
Any changes you make to the object are persisted.