We are programming a new web application framework (Second WAF). I was wondering if we should support cookieless sessions or not.
Who use it and who needs it?
I was wondering if we should support
cookieless sessions or not.
I think this depends largely on your userbase. In my organization we support several intranet applications. We also control our users desktops. Since we control their desktop environment we can control browser settings and ensure cookies are enabled. Because of this and the increased risk of session hijacking, there is no reason for us to ever allow cookieless sessions.
Who use it and who needs it?
Those who need to support sessions regardless of the end users' browser settings would need to implement cookieless sessions; keeping in mind the implications of doing so.
It is a good feature, but several aspects have to be taken into account
what if an URL containing session ID is cached by a web spider such as Google, will you be able to provide content if the ID in session is other than the ID provided in URL
security. If you don't implement it smart enough, users will be able to send a URL to another user, where the URL contains the session ID and hence, allowing hijacking the first user's session. For instance, in ASP.Net1.1 the cookieless session mechanism was considered vulnerable
Related
I'm creating a website where security conscious (paranoid) people might block cookies, and even authentication cookies.
I'd like to detect this instance, and redirect to a FAQ/Help page that describes the corresponding risks with cookieless sessions.
You're mixing terminology, so it's a little unclear what you're talking about. Sessions are either cookieless or not. If you're using cookieless sessions in ASP.NET, then every session is cookieless. As a result, it's kind of pointless to warn a user about the inherent security risks in something they are forced to use. If you're not using cookieless sessions, then every session requires a cookie, and again there's no point in warning a user about something that doesn't even apply to them.
The only thing that would make sense here, is to require a session cookie (no cookieless sessions) and then notify users without cookies enabled that they will not be able to utilize portions of your site that require cookies (authenticated areas and other places where you might utilize the session). To do that, you can either use JavaScript to detect whether cookies are enabled via navigator.cookieEnabled or you can do it server-side via:
Set a cookie or simply save something to the session (which will require a cookie to be set)
Redirect
Check for the previously set cookie or session data
If it exists after the redirect, then cookies are enabled. If not, then they are disabled.
The use of cookies in web applications is extremely convenient and universal. But in some countries the law requires to place additional information on a website that uses cookies.
To avoid this in the web application, I consider to use the ETags instead cookies.
I mean mainly about use its to the technical approach, such as maintaining user session, in particular for tasks such as logging and storing information about the state of product basket.
Another advantage ETags instead of cookies in the web application could be:
Protect from attacks associated with cookies.
Protect from clearing browser's cookies by user (but not from clearing browser's cache of course ;)
How do you think you can either use ETags instead of cookies?
Is it carries behind an additional risk?
It is possible to use ETag instead of cookies but not 1-1 and it is not recommended.
They can be a support for cookies.
I have not been able to find legal objections to this issue.
For various reasons I am fed up with ASP.NET session state and I'm trying to do it myself (separate question coming soon related to why I'm fed up and whether it's feasible to do it myself, but for now let's assume that it is).
Security concerns aside, it seems like tracking sessions involves little more than storing a cookie with a guid and associating that guid with a small "sessions" table in the database, which is keyed on the guid and contains a small number of fields to track timeout and to link to the primary key in the user's table, for those sessions that are linked to registered users.
But I'm stuck on a detail with the cookie, in the case the user's browser is not set to accept cookies. It seems to me that each time a user accesses any page that has session state enabled, ASP.NET must determine whether the browser supports cookies. If there already is a session cookie sent with the request, obviously it knows cookies are accepted.
If not, it seems like it needs to check, which as I understand it involves trying to write a cookie and redirecting to a page that tries to read the cookie. So it seems, when a user with cookies turned off visits several pages of a site, that ASP.NET
(a) has to do this round-trip test for every page the user visits, or
(b) has to assume the browser accepts cookies and create a record with a (provisional) session id for the user on each page -- and if session state is supposed to be persistent, it seems it has to write that initial session id to the database on each page.
But (a) sounds crazy and (b) sounds crazy also, since we would quickly accumulate session ids for all these single-page sessions. So I'm thinking there must be some other trick/heuristic that is used to know when to do the round-trip test and/or when to actually create a record for the session.
Am I wrong to be perplexed?
(To be clear, I'm not talking about implementing a custom storage solution within ASP.NET's pluggable session state system. I'm talking about skipping ASP.NET's session state system entirely. My question is a more detailed version of this one: Implementing own Session Management in ASP.NET.)
Session behaviour is set through the sessionState element in web.config. In the sessionState element the HttpCookieMode can be set to one of UseUri, UseCookies, AutoDetect, UseDeviceProfile.
UseUri and UseCookies tell ASP.NET explicitly how to handle storing the session identifier. If UseDeviceProfile is used then the behavior is determined by whether the user agent supports cookies (not whether they are enabled or not).
AutoDetect is the interesting case that you are interested in. How ASP.NET is handling the auto detection is explained in Understand How the ASP.NET Cookieless Feature Works. In that article you will see that they have 5 different checks they do. One of the checks is, as you mention, to set a cookie and do a redirect to see if the cookie exists. If the cookie exists, then the browser supports cookies and the sessionID cookie is set. However, this is not done on every request because another check they do before tring to redirect is is check to for the existence of any cookies. Since after the initial set-cookie and redirect the sessionID cookie will be set then the existence of the cookie lets ASP.NET know that cookies are supported and no further set-cookie and redirects are required.
Well, cookies are a standard mechanism of web authentication. Do you have any reason at all why you wouldn't want to use them? Are you sure you're not trying to invent a problem where there isn't any problem?
Most serious websites I know of require the browser to accept cookies in order for the user to be authenticated. It's safe to assume that every modern browser supports them.
There's an interesting article about cookieless ASP.NET that you should read.
EDIT:
#o.k.w: By default the session state is kept by ASP.NET in-process (read: in memory). Unless told explicitly by the configuration to store the session in the database (SQL Server is supported out-of-the-box), this won't result in a database hit. The stale session states will get purged from the in-process storage. Unfortunately, with default ASP.NET settings every cookieless request will result in a new session being created.
Here's a detailed comparison of available session storage options: http://msdn.microsoft.com/en-us/library/ms178586.aspx.
We're creating a new consumer/public-facing ASP.Net web app. There are two concerns:
--Use cookie or cookieless forms authentication?
--If we decide not to use cookies at all, how would you store the data that would otherwise be stored in the cookie (Customer ID, AffiliateID, etc.). Does the ASP.Net authentication framework track something like CustomerID?
For a normal web app there is no good reason to use cookieless authentication - Fear of cookies died out about a decade ago.
For actual data, the session object is generally a better choice than individual cookies - The session cookie is a single value that effectively gives you a key to whatever session data you have stored on the server. There are certain specialized cases where there are problems with using session, for example in multi-server deployments, but in for most applications it is simple and adequate.
The standard forms authentication system does track the username - generally this is enough to look up whatever data you need from your database if you don't want to keep anything in the session.
If you're doing authentication, cookies are the usual method. It's very rare these days that people will have cookies turned off because so many sites already depend on them.
Having said that, ASP.NET does support "cookieless" authentication. Basically it just adds the authentication token as a parameter on the URL. It parses all outbound URLs to ensure that they also include the token information. Personally, I wouldn't bother with this and just go with requiring cookies. There are a few additional headaches when trying to go cookieless (for example, it can make SEO that much harder, because the search engines will see a different URL every time it crawls the page).
We have a web application running on ASP.NET 3.5. It is viewed by the world as one URL but in reality there are multiple IIS boxes hosting the application controlled by a load balancer.
My problem is that it is a sensitive application with strict security controls around it, and that post authentication if you open another browser to the same application and log in as someone else, the second login overwrites the first logins' session id value in the cookie, and then the first window crashes.
Any idea how I can get around this?
The session ID is placed in the cookie. If another browser window is opened and starts a second session the ID in the cookie will be replaced.
Also, logins should not be controlled via the session cookie. There is a Forms Authentication cookie for that purpose which is more secure as I recall.
Most web applications only allow one session per PC. Try logging into Yahoo Mail, Amazon or Ebay twice on the same machine and you will find the same problem. So ASP.NET is pretty much designed around the idea that there is one login per PC. Although, if you have multiple browsers installed on a machine, you can generally log into apps more than once because each browser keeps its own cookie collection.
edit: You might want to try cookieless sessions, in theory they might allow multiple sessions per PC, although I haven't tried it. But cookieless sessions come with plenty of problems and limitations of their own.
In short, there may be some hacky way to do what you want to do, but it will probably be fiddly and cause other problems elsewhere, because what you are asking for goes against the grain of ASP.NET's core design.