ColdFusion sets the CFID and CFTOKEN cookie on every single page, obviously connecting that to a session on the server.
However, with the EU cookie law coming up I'm not how to sort this out. The CFID and CFTOKEN cookie is only needed if I need to use the SESSION scope in my application.
Probably 90% of our website tools don't need to use the session.
However our login system obviously uses the SESSION, and we have a few tools that we store user preferences in.
If I disable the CFID and CFTOKEN cookie from being set in the ColdFusion administrator, can I later turn that on for individual requests, based on a per user basis?
ie. if a user says "yes I want cookies", can I then request a ColdFusion page that sets the cookies for future use?
Sorry if that question is a little unclear.
Cookies such as CFID and CFTOKEN would be very likely to fall within the exception to the new law as effectively they are required for your site to operate and in themselves pose no threat to privacy.
Session cookies like these are generally being accepted as being excluded from the requirement for consent. See the ICO guidance document here: http://t.co/kvNH1QME - pages 9-10 describe the exception.
OK if you don't want to rely on the exception there's a couple of possibilities:
If you really want to disable/enable cookies dynamically you can use the setclientcookies="no" attribute in the cfapplication tag. This could be a dynamic value depending on whether they had accepted or not - so it defaults to no, but if they select to accept cookies later would switch to yes.
Or you could do away with cookies altogether and simply pass URL parameters - see "Using client and session variables without cookies" here: http://tinyurl.com/2c6jyfy
Related
I have a very straightforward session system on my website: User logs in and the response on success contains a session token. The session token is then stored as a cookie with no expiry (expires=Fri, 31 Dec 9999 23:59:59 GMT) and root path (path=/).
On requests which require authentication, the client will send the session token value as part of the message, and as a fallback, also as a header and cookie.
Even so, from time to time I get users that just lose their sessions. Their session tokens are still valid, and they haven't logged out. All of a sudden, they apparently don't have the session cookie anymore. They were able to make requests for a while, and for many thousands of requests a day this happens maybe once every day or two so it's a rare occurrence. The requests don't seem to be malicious, they're just normal users who have the website open for a while and suddenly lose auth.
What are some things that can cause this (I expect in at least some cases it's some odd browser/OS setting out of my control)? What are some ways I can prevent this from happening without necessarily knowing the cause?
google Chrome, Firefox and other browsers plan to abandon cookies in near future source1, here is what you need to know. about GDPR and why so.
EU’s General Data Protection Regulation (GDPR) to let users from inside Europe control the activation of cookies and trackers that collect their personal data.
this could be a pain for companies eating cookies. because of the strict legal atmosphere for cookies these days.
a more robust Method to store persistent client side data is discussed here, you can even store whole databases via these methods discussed in MDN webpage. MDN=Mozilla developer Network.
Client-side storage: Link
Web Storage API : LINK
IndexedDB : Link
LocalStorage : LINK (next best alternative for cookies)
Highlights of LocalStorage API:
localStorage does the same thing, but persists even when the browser is closed and reopened. ie system reboot does not affect it.
Stores data with no expiration date, and
gets cleared only through JavaScript, or clearing the Browser cache / Locally Stored Data.
Storage limit is the non limiting around 5MB!
Are you perhaps redirecting domains? So for example: you SET the cookie ok productlogin.com and you redirect to product.com or any other server where you then want to READ the cookie? Because that won't work.
It could also be that your app is requesting the wrong cookie. Are you matching the same session? It could help us if you have some code to share.
In this document, page 7, it describes a vulnerability that may happen when a user is tricked into going to
"http://online.worldbank.dom/<script>document.cookie="sessionid=1234;domain=.worldbank.dom”;</script>.idc". (They also include a url with <meta> at the end, as an example.) I noticed that at least in Firefox, this only gives 404 error. For example, http://example.iana.org/%3Cscript%3Ealert%28%27hi%27%29;%3C/script%3E.htm
I know there's javascript: "url" prefix, but was there also a bug in old browsers that somehow allowed scripts in the url? Or is this document implying something completely different?
One other thing I don't quite understand - on page 11:
"Notes: It’s important to realize that using an encrypted
communication between the user’s browser and the target web server has
literally no effect on the exploitability of session fixation
vulnerabilities."
It says this in the section that describes network sniffing and injecting, is that really possible with https??
The idea with session fixation is that the attacker doesn't need to pay attention to whether or not it's https. Sniffing is not needed.
Normally the attacker could try to steal a valid session id by sniffing, and then take over the user's session. With session fixation the attacker picks a session id, and then tricks the victims browser into using that preselected session id. Thus there is no need to sniff. The session id is already known.
Regarding script-tags in the url, that attack will work in some, but not all websites. If the website has (as described) a cross site scripting (XSS) then the attacker can craft a url with a fixation attack. However a more likely scenario is injecting scripts that steal the current session id, but this may not work if the session cookie is httpOnly. In this case session fixation might be a better option for the attacker.
I have a standard HTML login page, which I would much rather use than the standard HTTP authentication pop-up provided by browsers. Today, I am using session cookies to keep track of the session after logging in, but I'd like to be stateless and pass the HTTP authentication every time. The web services I am hitting already support this, so this is a browser-only issue.
Adding authentication credentials is trivial in jQuery, but I don't know how to keep them around. If you go from the login page (a jsp) to the Home page (another jsp) you clearly don't keep the username and password fields from the login page. I know some browsers will store your HTTP authentication credentials if you enter them from the pop-up, but I don't know if they get stored when using an XHRRequest. If they do, is there much consistency among browsers?
Also, the user needs to be able to "sign out" of the application, too. If the browser stores the authentication credentials, is there a way to clear them using JavaScript.
I feel like I can't be the first person to try to solve this. Is there some jQuery plugin or something that already handles this? Or is it simply not possible to do what I'm trying to do?
You have 2 options:
1) Client-side storage of credentials -- not a good idea. For obvious reasons you don't want to store the username/password on the client. If you had a hashed version of the password, it might not be so bad, but still not recommended. In any case, if you're going to store on the client side, you either have to use a cookie, or HTML5 local storage (which is not widely supported, yet)
2) Server-side storage of credentials -- typically done with sessions. Then the resultant Session ID can be passed back to the client and persisted in either a cookie or in the URL of each subsequent AJAX call (?SESSID=xyz for example)
The server-side approach would be the most secure, reliable, and easiest to implement
Okay, I'll take a stab at helping ...
Firstly, understand how HTTP authentication works. There are two versions - Basic and Digest. Basic transmits in plaintext, digest is encrypted. With these types of authentication, the username/password are passed in the HTTP header with every single request. The browser captures these at login and they are stored in an inaccessible browser session cookie which is deleted when the browser session is closed. So, in answer to one of your questions, you can't access these from javascript.
You could create your own session cookie variables for username and password. The jQuery functions for this are really simple. See jquery-cookie module as one example of how to set session cookies. These could be retrieved from the session cookie and sent with each ajax request and validated in the server. However, this is not a particulary good way to do authentication since sniffing the network will allow anybody to easily grab your auth details. But, it would work.
Using session cookie based authentication where the session ID is sent sent with each request is the best way to do this. At the server side, you need to have a function called for every HTTP request. This function should do the following:
check to see if the session has been authenticated
if no:
redirect to login screen
if yes:
do authorization and allow the user access to the page
Most web frameworks support session cookie authentication and the management of session ids at the server. This is definately the way to go.
This is interesting one.
Manage user sessions on server by use of cookies. Create a session when user first accesses the login page and pass the session id/key as value to one of the cookie via response. When the user is authenticated put user "key" info in cookie and "values" in application context at server. Once user is logged, any subsequent request will be authenticated based on session cookie value at server. Authorization will be done based on user "key" passed as cookie value.
On logout clear the session based cookies from server and refresh the site to default page.
Cookies are bizarre with different browsers - just a note ;)
Hope this helps.
Update
The answer below was posted in 2012 and the links are mostly dead. However, since then, a more elegant standards-based approach to the same solution appeared using JSON Web Tokens. Here is a good blog post explaining how to use them.
Most answers miss the point, which is to avoid having any server-side session. I don't want any application state in the server. I'll award the bounty to answer that came closest, but the real credit goes to the rest-discuss group and Jon Moore for the correct answer and to Mike Amundsen for helping me to actually understand it.
The best answer I've gotten is to use a cookie, but not the typical automatic session id cookie given to you by most application servers. The cookie (which will automatically be sent with each subsequent request) is a user identifier and time signed by the server. You can include an expiration time with the cookie so it simulates the typical 30 minute session on a server (which means you have to push it forward with subsequent requests) as well as keeps the same cookie from being valid forever.
The XHR/AJAX part is a red herring. This will work whether you are doing XHR requests or an old-fashioned page-by-page web application. The main points are:
The cookie is automatically sent on subsequent requests so there's no
special scripting required - it's just how browsers work already.
The server does not need to store any session for the user, so the user
can hit any server in a cluster and not have to re-authenticate.
Slightly interesting in that you consider pushing some of the authent to the client. If you want a conventional solution, KOGI's server-side suggestion is the way to go.
But you also seem to be asking questions about memory leaks involving your user supplied secrets. Good questions. But to take a general stab at answering that I'd say it would have to be browser specific. It's browser internals, javascript engine internals -dependent where a client side application (i.e., the browser, or js in the browser) is storing the values the user inputs.
Most likely those values are not replicated needlessly throughout memory, but there's no way to guarantee that. Apart from responsible javascript coding practices, there's nothing you can do to guarantee the limit of locations of user inputs.
Slight digression
The basic point is if you store it on the client it is not really secure -- unless, the serve stores encrypted information on the client with a key that only the server (or the user via their correct credentials), has. So you could conceivably code a JS application to do some authent on the client -- much the same as how bank card (used to?) do POS authent by checking the PIN to the PIN on the card, and not back at the DB. It's based on the (somewhat flimsy) assumption the user has no direct read/write access of the "dark area" cookie/local storage on client / mag strip on bank card. So I would only advise this as disqualifier for false authents and not as a sole qualifier for the credentials.
Main point
If you do want to be stateless, just store user credentials in localstorage, or as a cookie but encrypt them with a server key. When you need them send an XHR with the encrypted / use stored credentials to the server over HTTPS, let your server decrypt them and send them to the callback. Then pass those cleartext of HTTPS to do your authent.
Which is the difference between sessions and cookies. I know that sessions are server side, and managed by the server, and the cookies are client side and managed by the browser.
I don't know why, but I see those things as rendundant. Which data have to be keept in a session variable and which on cookies?
Session is implemented with cookies. You would normally save in a cookie things like the user id, or some identifier that will allow you to know who the user is, and use that information as a key for your session variable on the server side.
Most importantly, you wouldn't want any secret information being stored on the client side, since cookies can easily be stolen (from a security point of view).
Don't forget that HTTP is stateless, so cookies are just a way to bypass this.
In short, cookies are more persistent than sessions. As soon as you close your browser, the session information is gone. Therefore a session has no way to store information about a website/user pair. Cookies do, and are used for things like allowing you to stay logged in to a website, or storing preferences for that website (e.g. language).
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.
see http://php.about.com/od/learnphp/qt/session_cookie.htm
Cookies are for small data. They can only hold strings.
In session variables you're able to store objects in the server memory.
What's an elegant way in Classic ASP to check if session cookies are enabled in a user's browser using server side code (because javascript might be disabled as well).
I have a solution of my own but it looks ugly as hell.
#James - that doesn't differentiate between setting a session cookie and a general purpose cookie though (IE lets you differentiate between First Party, Session Cookies and Third Party, but I see with Firefox they only differentiate between First Party and Third Party)? I'm setting a session value in a login page then doing a Response.Redirect kinda thing and checking to see if the session value is still valid.
Unless you specify an expiry on the cookie it will be a session cookie. The term session is a bit overloaded in HTTP. When the IE dialog refers to a session cookie it means any cookie that is only stored in process memory and not persisted to disk, therefore only lives for the duration of the process (the session). Start another IExplore.exe process and you have another session which will not have the values of any previous or extant session cookies.
You are correct though that you can test whether even session level cookies are being blocked by just storing a value in the session object and testing for its presence on a redirect.
Well, the "ugly as hell" method we used, was to set a cookie and redirect to a new page. In the code for the new page, see if the cookie was set. Since the only way to get to the second page is to be redirected there when the cookie is set, it's presence or absence should tell the state of the browser.