I understand HTTPOnly flag applies to session cookies. Does it apply to persistent cookies? Is anyone able to provide a reference? I have checked http://tools.ietf.org/rfc/rfc6265.txt on HTTPOnly flag but it is not explicitly stated.
from HTTP Cookies Explained:
The expiration date on this cookie hasn’t changed, since the
identifying characteristics of the cookie are the same. In fact, the
expiration date won’t change until you manually change it again. That
means a session cookie can become a persistent cookie (one that lasts
multiple sessions) within the same session but the opposite isn’t
true. In order to change a persistent cookie to a session cookie, you
must delete the persistent cookie by setting its expiration date to a
time in the past and then create a session cookie with the same name.
Keep in mind that the expiration date is checked against the system
time on the computer that is running the browser. There is no way to
verify that the system time is in sync with the server time and so
errors may occur when there is a discrepancy between the system time
and the server time.
further down:
To create an HTTP-only cookie, just add an HttpOnly flag to your
cookie:
In the Opera Dragonfly documentation:
HTTPOnly cookie Session and persistent cookies can also be HTTPOnly. A
HTTPOnly cookie can not be accessed by client-side scripting, which is
designed to help against cross-site scripting attacks. HTTPOnly
cookies are labelled with a tick icon in the HTTPOnly column.
it looks like you can also apply the HTTPOnly flag at least for Opera Dragonfly
Related
I have a simple "session authentication" mechanism:
each time a user logs in a session it's created on database server side, and it's session id is set encrypted as a "session cookie" to the client
on logout or browser instance closing, the session is either deleted or invalidated
I've read and understood that by stealing a cookie encrypting the session id within an active session one steals another identity, and for this reason permanent cookie should not be used.
Still, even if i used a cookie with an short expiration date the theft can still happen within it. Are there other steps to avoid this problem?
It's legit to just use a short expiration date (if so, what is a decent time frame?), or are there other complementary technique to work around this problem?
The best practice for session cookies is to not set an expiry time so that they are valid for the browser session. If you set an expiry time, the cookie becomes persistent, will be stored on disk on the client and so on - it increases the overall risk.
You are right that anybody that has the cookie can impersonate the user. To avoid that, you want to have the cookie set as httpOnly to avoid Javascript access (XSS) and secure so that it is only sent over https.
While there are depths to correct session management, it doesn't seem to make a lot of sense to encrypt the session id. What is the purpose of that encryption? The session id should just be a large random number (possibly encoded into a shorter string, but still), there should be no need to encrypt it.
The generic advice around session management is to not implement it yourself. There are too many pitfalls, and pretty much all frameworks (or languages) have a solid implementation that you can just use reasonably securely. Avoiding all the potential vulnerabilities is hard.
Expiration is an attribute of cookie. Attributes are not sent back to the server upon subsequent requests. A well-behaved browser will not send an expired cookie, but a malicious browser may ignore the expiration and send the cookie anyway. How can the server tell if the browser is actually honoring the expiration date it originally sent as an attribute of the cookie?
Is it as simple as storing the expiration date inside the cookie? Then, if the cookie is signed, the browser can trust that value and check it against its own clock.
NEVER. TRUST. USER. INPUT.
By USER, consider anything external to your application.
https://www.owasp.org/index.php/Don't_trust_user_input
For your particular case, yes, you can add a timestamp to the content of the cookie and sign that content, then check it serverside.
For example using https://secure.php.net/manual/en/function.openssl-sign.php
Recently，I'm learning about the middleware "express-session" of express, I want to understand all properties in the given options.But when I read about the API of express-session, I'm confused with the three
properties:saveUninitialized, resave and rolling.
They all have an effect on cookie setting or session operation, so what's the difference and connection of them?
Hope somebody can help me to distinguish them,
Thanks a lot!
When a modern browser makes a request, it appends all cookies that match the current domain (website) in the Cookie header. Here's an example of what my browser might send if I visit stackoverflow.com:
Cookie: acct=1234
No cookies are sent by the browser when you visit a site for the first time. In that case (and if the owner wanted to utilise cookies to track user sessions, for example) the server will commonly respond with a Set-Cookie header, something like this:
Set-Cookie: acct=5678; expires=Sat, 15 May 2050 15:32:57 GMT; domain=.stackoverflow.com
(It can also append path, secure, and HttpOnly options, all explained here) I'm simplifying but, by default, express-session only sends Set-Cookie when you visit a site for the first time.
If rolling is true, it will be sent every time. This has the desired side-effect of continuously rolling forward the expiration of the cookie with every page refresh. The new expiration date is determined by adding maxAge to the current server time.
If you alter the req.session object, it will be saved back to the session store at the end of the request; otherwise it will not be saved. Setting resave to true forces it to be saved everytime, even if no changes were made. It might seem illogical but certain stores might require this (although, having looked through the list, it seems that none currently do).
When a cookie is set for the first time, a new session object is created in memory and saved to the store at the end of the request. This can take up a lot of space in the db if you have many people visiting and then bouncing without performing any meaningful action like logging in. You can choose to only save sessions if they deviate from the default session object (ie. if you've modified it, like setting req.session.user = user; on login) by setting saveUninitialized to false.
Something to be aware of is certain combinations of these values (along with others) might produce unexpected behaviour. For example, the documentation states:
When this option [rolling] is set to true but the saveUninitialized option is set to false, the cookie will not be set on a response with an uninitialized session.
I am having some cross-session identity contamination in rare cases.
Chasing this down I noticed something that doesn't make sense to me.
I login as user x in my ui (using a CORS servicestack server) and I observe the ss-id cookie value.
I logout using auth/logout and then login as a different user and the ss-id cookie value remains the same, but my session values (identity etc) in the server seem fine.
Is this normal? Isn't the ss-id cookie a session cookie and hence should not stay the same across different sessions?
Thanks
The browser may retain the session cookie until the tab or window is closed. You may want to delete the session cookie from the client side on logout and invalidate it from the server side upon logout.
The temporary ss-id and permanent ss-pid Session cookies are explained on the Session wiki.
If you close your browser session your temporary ss-id will be lost and the next time you access ServiceStack a new one will be generated. The ss-pid permanent cookies survives browser restarts.
Logging out just removes the Server Session stored against those cookies (i.e. essentially making them an anonymous user), it doesn't remove the cookies themselves.
Is it possible to create a session cookie (one that is automatically deleted when the browser closes) AND also has an expiration so that it will expire after a set time, let's say 15 minutes unless the user continues using the site? If they use the site, i'd like to reset the expiration so it lasts another 15 minutes.
I've only really had luck with either creating a session cookie that expires when the browser is closed OR stays around as a persistent cookie but has an expiration either using expires or maxAge arguments.
The only thing I can think of is to create a session cookie that has a timestamp value stored in it and in the session middleware, check of the current time > the timestamp value and then deny the request and delete the cookie by setting it to null. If current time is <= the timestamp updating the timestamp to the new date effectively extending the session timeout.
While my idea may work, it makes me think there is a more official way of accomplishing what I want.
I'm currently experimenting with node and express so any insight that is tailored for that build-out would be appreciated.
Because the way you create a session cookie is to leave out the expiration, you can't really do it with a single cookie.
But, you can do it with two cookies, one session cookie and one expiring cookie. Here's some logic for doing it with two cookies:
Create a random number.
Create a session cookie such as session=randomNumber.
Create a second cookie expiry=randomNumber that expires in 15 minutes.
Have your code check to see that both cookies exist and contain the same random number.
If the browser is closed, the session cookie will be deleted.
If 15 minutes passes, the second cookie will be deleted.
If the browser is closed and then reopened, there won't be a session cookie and even if you coin another one, the second cookie won't have the same random number in it.
By checking for the presence of both cookies, you're making sure that both conditions have been met.
And, if you want the 15 minute cookie to continually refresh itself on any page load, you can have your server recreate that cookie on each page load with a new fresh time 15 minutes from now.