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.
Related
If the session is stored in proc
The user logs in, closes the browser directly and reopens it after an hour. Would he need to log in again?
If the web application uses cookies and cookies are enabled on the users browser...
If the web application uses persistent cookies and cookies are enabled on the users browser...
If the web application uses cookies and cookies are disabled on the users browser...
If the web application uses persistent cookies and cookies are disabled on the users browser...
If session is stored in state server and situations are the same, then what would happen?
When a session is created (assuming it is a normal session), a cookie is sent to the browser that looks something like this:
SESSION_ID=437b930db84b8079c2dd804a71936b5f
Sessions can be used without cookies if the session identifier (in the example above, 437b930db84b8079c2dd804a71936b5f) is passed around as request parameter instead of a cookie; however, this is rather uncommon and it is generally considered bad practice.
All session information is stored server-side, and the session identifier is used behind-the-scenes to decide which set of information should be recalled (if any) for each request. Thus we get to your questions.
If the web application uses cookies and cookies are enabled on the users browser...
If the web app uses cookies and cookies are enabled on the browser, then there should not be a problem. With a standard session implementation, the cookies will be non-persistent, though, so the user will need to login again if he/she completely closes all instances of the browser.
If the web application uses persistent cookies and cookies are enabled on the users browser...
If the session-id is stored in a persistent cookie and user's browser respects that by persisting the session identifier cookie to the disk, then the session identifier will be sent even if the browser is fully closed and restarted. However, please be aware that most web frameworks have a garbage-collector-like system that deletes data for sessions that have showed any activity over a certain amount of time. So, for example, let's say my website requires activity at least once every 4 hours to keep a session active. If I login, receive a persistent cookie with my session ID, close my browser, and come back 5 hours later, then I will need to login again because my session information would have been cleared from the server even though my session ID cookie was persistent.
If the web application uses cookies and cookies are disabled on the users browser...
Bad news bears. You will either need to find a way to use a cookieless session (passing an identifier as a parameter for each request), or you will need to ask the user to enable cookies. There is no way around this.
If the web application uses persistent cookies and cookies are disabled on the users browser...
Same situation as #3. If the user has cookies disabled, you are out of luck. Either they need to enable cookies (at least for your site), or you need to find another way to pass around information between requests.
Session is stored in server memory (unless a state server or persistant store is used) but relies on a cookie to identify the session. If cookies aren't available then session won't work since there is no way to identify the user. Cookieless sessions can be used to get around this. Cookieless sessions aren't recommended as they can be hijacked with the session identifier in the url.
If an expiration isn't set on the cookie then it will be lost once the user closes all browser instances (they share memory) and not just the one visited through the website.
If the user has cookies disabled, then cookies aren't available for use by the application. People aren't as worried about cookies now as they were in the late 90's (lots of "security" people raised warnings that cookies could be used to store all sorts of things on your computer, even viruses).
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
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.
Does using cookies pose a threat to application security in asp.net ? Or do we only use as a medium of saving user stats and non-vital information ? Got a little details of using cookies in asp.net from my own blog
IMO cookie is one of the best choice for some situations. For instance, storing the user's selected language. Also you can cache some sensitive information in the cookie as users' roles as ASP.NET Roles manager. But you should encrypt it without doubt and also you should set HttpCookie.HttpOnly = true to prevent javascript from accessing to cookie. Don't worry about supporting cookie in different browsers, size is premier (Browsers support only 4096bytes per cookie). Cookie is bandwidth killer, cause sends and receives within each request and response. Thus, you should use it in avarage. You can check if the client browser supports cookie as follows.
if (Request.Browser.Cookies) { // The browser supports cookie }
To learn more information about cookies, visit here.
Using cookies doesn't pose any threat to an application. It is the way you use them and the information you store that could be problematic. For example, you have to avoid storing sensitive information in cookies. If used for authentication, they should always be transmitted over a secure channel.
It depends on how you use them. Cookies should be treated as un-trusted input at all times, because they can be faked, edited or deleted. I've seen applications where a cookie contains something like admin=true which is obviously a very bad thing to do. If you're just dropping some guid and using that to track someone, but not caring if your results are accurate then that's fine.
If you want to make sure the cookie is semi-valid then you must add something like an HMAC to the cookie itself, which is what ASP.NET does with the forms authentication cookie (and the ViewState field). Of course this doesn't stop the user deleting the cookie, or copying a valid one from another user.
As long as you don't store critical information in the cookie (like the user's password) you should be fine.
Be careful with scenarios like that :
You store the user's ID in a cookie
You test against this ID to see if he's logged in
The user changes the ID manually in the cookie (easy to do)
The user gets access to another account
My point is that you have to keep in mind that the user can access a cookie and change it, so don't store anything you wouldn't want him to see.
Last thing, cookies often have a limited size so be careful: don't store too many information. If you store too much stuff (like a large object), you might end up breaking things.
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).