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.
Related
I have a need to preserve session id after login. My session id cookie is marked as HttpOnly. Is such setup absolutely secure? Is there any possibility for an attacker to to perform session fixation attack if my session cookie is HttpOnly?
TLDR: Yes, in PHP and Firefox it is possible to add a second session cookie which, due to the order in the header, is preferred over the original one.
Also Yes, if there is other functionality which allows to set session IDs on the server. This depends on the application specific functionality.
Full explanation
Depends on what other functionality you have on your website to manipulate sessions. In some rare occasions, the application allows a user to set a session via a HTTP request. For example, via a GET parameter.
I believe you want to know if it is possible to fixate a session ID if the original session ID is set in a cookie with the HttpOnly flag. Therefore, I did a small test on a PHP application I was conducting a pentest on. Surprisingly, you can set a new PHPSESSID via a JavaScript injected as XSS. If there already was an existing PHPSESSID cookie with the HttpOnly flag, it simply puts this one next to the other one. In my case, in Firefox, it sent the following Cookies to the server after my attempt to set PHPSESSID via document.cookie = "PHPSESSID=FIXATEDSESSIONID":
Cookie: PHPSESSID=FIXATEDSESSIONID; __utma=139474299.465096418.1547461023.1548839033.1548851774.5; __utmz=139474299.1547461023.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); acceptCookies=true;
So there are now two session IDs in the request. In my setup, with PHP 5.6.25, the server takes the first cookie to bind a session. So in the case with Firefox and PHP 5.6.25, I was able to fixate my session ID (FIXATEDSESSIONID) via a JavaScript. The original session ID is still in the request but it is ignored by the server. Note that FIXATEDSESSIONID is literally the session ID I injected. So it was not necessary to get a legitimate session ID from the PHP server.
It's better to have session cookie as HttpOnly, because it obviously makes session more secure.
The right way to avoid session fixation vulnerability is to make new session for user on authentication.
Check OWASP article about session fixation. It has information about techniques to execute this kind of attack.
According to Where are $_SESSION variables stored?: "Usually the session-id is stored in a cookie, but it can also be appended to urls". Once I read that, I asked myseld: so, why is it said that the session-id is deleted when closing the browsers window if it is stored in a cookie?
Then, after Googling a little bit more about it, I found that there are two different types of cookies: session cookies and persistent cookies.
I guess that the session-id is stored in a session cookie, but: beyond the name evidence, why is a session stored in a session cookie and not in a persistent cookie? What is the need of creating a new session-id every time the browser is opened? Why don't re-use it?
There are many reasons you store sessions in session cookies. One case is public computers: if the previous user has logged into their bank account at the library to pay bills you don't want the next user to be able to log into that session by just looking at the History log in the browser. Being sure that the session is gone by closing the browser alleviates this.
You can also use persistent cookies, and many do too, such as Gmail, but what is then important is to set an expiration time that is not too long. Otherwise, if someone gets hold of the session id they can use that forever. Usually the server will send you a new valid session id some minutes before the next goes out to keep your session alive.
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
How do websites generally log users out and send them to the log in screen automatically when a user's session expires? Is this done through ajax or running async handlers? Can you give me a bit of an explanation.
Banks and such use a client-side timeout via javascript, or something similar. Really, though, the server handles the actual session, so if you disabled the client-side logic it would act as if you were attempting to make transactions while logged out.
Use a cookie as well as a session.
Cookie must be set when a session is
started.
If the cookie is present but the
session is gone, redirect to the
login screen.
If there is no session and no cookie
do nothing
(pardon me if you can't do that because I never used ASP and basing my answer on my PHP knowledge)
Typically, you set an expiration timestamp on your session ID cookie. When the cookie fails to be sent, the client is logged off (no given session ID).
This method is often combined with JavaScript and another timestamp token. When the timers start running down, a notification is sent that allows the user to "refresh" their session... essentially, making a request before the session timestamp expires.
The "refresh" request could be anything, even something as simple as an image load.
If you are using Tomcat you can use its built in <security-constraint> mechanism within your web.xml definition. All of the timing, login screen, and page redirects are handled by Tomcat with little effort on your part other than definitions.
Oh, IIS... nevermind.
Everything I read about cookies says that setting the expiry time of a cookie to zero should make it a `session' cookie, which the browser will then delete upon exit.
http://www.cookiecentral.com/faq/ says that :
"...generally a session is the length of time that the browser is open for..."
http://php.net/manual/en/function.setcookie.php says :
"If set to 0, or omitted, the cookie will expire at the end of the session (when the browser closes)."
However, some experimenting in Firefox (3.0.8) shows that:
cookies set as session and secure get deleted on exit
cookies set as session only do not get deleted on exit
Opera (9.64) behaves as I would expect, deleting the session cookies upon exit whether set as secure or not.
I wanted to be able to rely on this in a web-app I'm working on (having a secure cookie and an insecure cookie as a "logged-in" flag and having them expire together, either with a real time or 0 for a session), but it seems that even if it's in the standard then browsers are not consistent enough to rely on it :/
Is this a bug in the browser, expected behaviour, and/or is the actual lifetime of session cookies not really defined in the standard?
You should never rely on client-side features.
The feature you're working on is usually implemented storing the session ID client-side and the real user info server-side (its ID, whether he's logged in or not, his personal info, etc).
Also bear in mind cookies get sent in every request, so the less you store in a cookie, the better.