If cookies are disabled in a browser, can we create a non persistent cookie which will get destroyed when the browser is closed?
go through below links, will clarify your doubts.
1) Session Cookies.
2) Persistent Cookies.
3) Managing Cookies.
4) Creating Session Cookies.
No. What the browsers do with your cookie is up to them. You can only offer them one, not dictate what they do with it.
My browser is set up to ask me if I want to accept cookies, and if I want to I can override their expiration to browser exit.
Persistent cookies are permanent cookies.They are stored as a text file in the hard disk of the computer.
Non-persistent cookies are stored in browser processor in temporarily. Its also called in memory cookies. Non-Persistent cookies are otherwise called as temporary cookies.They are active as long as the browser remains active.They are also called as session based cookies.Once the browser is closed the cookies vanishes automatically.
Non-persistent cookies are cookies in any way. So if cookies are disabled, it includes disabling all types of cookies i.e locking the browser out of writing any data to the main memory or the file system.
However if you wish to store session information you can use cookie less sessions, which obviously use the alternative of adding a session key to the address.
Related
I try to do a simple auth system with NodeJS.
I want to save the status of login (logged or not) in cookies in browser.
Can anyone read cookies and then add the same cookie to his browser and pretend he is logged?
Is this good way to save the status of login?
Look at the node/npm module client-sessions (from the Mozilla team). It allows you to create encrypted cookies that are stored securely on the client so you don't have to worry about tampering.
This does have a couple of downsides:
You are limited in size to what a browser will store in a cookie, generally 4K is a safe number, so if you need a session bigger than that you will need some backend storage/cache to hold it and use just a key in the cookie.
You cannot invalidate a cookie once it is on the client with a given expire time. You can always use other checks and reset the expiration to now/0/etc but you have to handle that with some backend storage/cache.
I find that a combination of the cookie for authentication with whatever you use for a user database and/or a cache (like redis maybe) make for a good architecture.
I am currently implementing an "auto-login" mechanism in JSF, see
Cookie maxAge always -1
I have tested the following scenario:
A user logs in without "remember me", then directly closes the browser without clicking log-out (if click log-out, cookie's maxAge will be set to 0). Later, if the user loads the page again, in the filter, the cookie is present in the request (normal, because cookie maxAge is not changed to 0 when closing the browser), and the user is automatically logged-in, which is not what I want.
Is there a way to solve this? what is the relation between cookie and session? I use session scope. As what I know, session won't get destroyed when the browser is closed, it is up to the server's decision. Therefore, I can't use #PreDestroy. I can't use Jquery.unload neither, because a user can also close the tab only, not the browser. Also in my application, several tabs can be opened at the same time...
Any suggestions?
You seem to want the cookie live as long as the opened browser instance. I.e. you want the cookie to live as long as the browser session.
Just make it a session cookie by giving a max age of -1. The cookie will then live as long as the browser instance.
As to the relationship between HttpSession and cookies, head to How do servlets work? Instantiation, sessions, shared variables and multithreading. Key difference is that the HttpSession has also a server-managed timeout.
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.
I'm fairly new to website development. I'm working on a site where the user logs in with username/password, and gets a sessionID from the server in response. This sessionID is sent back to the server (and a new one returned) with each request.
I'd like the site to work properly if the user opens it in multiple tabs or windows. i.e. once logged in at one tab, opening a members-only URL in another tab works without loggin in. (And, logging out in one tab logs out from all.) I see no way of doing this without storing the latest sessionID in a cookie. That way the latest sessionID can be "shared" among all tabs.
However I am starting to read up on cookies, and some of the security threats. I was unaware that cookies were sent with every request. I don't need to send my cookie to the server, ever. The sessionID is added to the xhr request's headers -- not read as a cookie. So I'm wondering if there is a way to disable sending of this cookie. My only purpose for it is to allow multiple tabs/windows in the same browser to share the same session.
I was reading up on the path parameter for cookies. Apparently this can be used to restrict when the cookie is sent to a server? What if I set the path to something that would never be used? Would this prevent the cookie from ever being sent out automatically? I only want to access it from JavaScript.
A coworker has put a lot of safeguards into the server-side of this application, which I won't go into here. So this question is just about what client-side precautions I can and should take, particularly with cookies, for optimal security. If there is a better way to allow a members-only site to work properly with multiple tabs open at once, I'm all ears.
I discovered just now that in HTML 5 there is local storage, which stores key/value pairs much like a cookie, but is not sent with every server request. Since it's supported in every browser except IE 7 and earlier, I'll be switching to this to enable sharing data between tabs when available, and use cookies instead on IE 7 and earlier.
The sessionID is stored in a cookie already there's no need to manage it. Because the HTTP protocol is stateless the only way to maintain state is through a cookie. What happens when you set a session value the server will look up the dictionary of items associated with that cookie id (session Id).
What is meant by stateless is that between requests HTTP does not know if your still alive or have closed your browser. Therefore with each request the browser will attach all cookie values to the request on the domain. SessionId is stored in the cookie automatically when they go to your site. The Server then uses that value to look up anything you've set in the users session.
Depending on which programming language and/or server you're using the session could be handled differently but that's usually abstracted away from the programmer.
Now with respect to sessions, there are a number of different things that make them insecure. For example if an attacker were able to get their hands on your session cookie value they could replay that cookie and take over your session. So sessions aren't a terribly secure way of storing user information. Instead what most people do is create an encrypted cookie value with the users details, the cookie could be a "session cookie" meaning as soon as the user closes their browser window the cookie is thrown away from the browser. The encrypted cookie contains user information and role information as well as some identifier (usually the clients ip address) to verify that the user who is submitting the request is the same user the cookie was issued to. In most programming languages there are tools that help in abstracting that away as well (such as the ASP.NET membership provider model).
Check out some details on the HTTP protocol and HTTP cookies on Wikipedia first
http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
http://en.wikipedia.org/wiki/HTTP_cookie
and check out the membership provider model on ASP.NET, it's a really good tool for helping to secure your site.
http://msdn.microsoft.com/en-us/library/sx3h274z(v=vs.100).aspx
Preventing the browser sending cookies seems to defeat the object of using cookies in the first place.
If you don't want the sessionID to be sent with each request, why set the cookie? A better solution would be to use a custom response header that you send from the server to the browser - this will then be under your control and will not be sent automatically with all browser requests. You are using request headers to send your sessionID anyway so you could receive them from the server using a custom header and read this into your JavaScript from each XHR.
Recently we removed jsessionid from URL did cookies based session management to prevent "session hijacking attack"
But we found that first request URL always has jsessionid when cookies are enabled and subsequent request URL has NO jsessionid.
using the jsessionid from first url we could directly hit other pages in the workflow
Question : is there any security vulnerability exposing jsessionid only on first request?
There is a solution to remove jsessionid from first request , but wanted to check , if its really vulnerable to mandate the changes
thanks
J
EDIT : I got my doubt clarified. Thanks for replies.
What you've done here could improve the overall security of the solution somewhat, but won't necessarily prevent session hijacking.
the security issue with placing the session ID in the URL is that URLs are exposed in various places (eg, copy and pasted URLs could expose a live session, URLs can be stored in proxy server logs, web server logs and browser history), which could allow an attacker to grab a valid session ID and get access to your users data.
Ideally you should remove the JSESSIONID from the URL in all places, and only use cookie storage.
Additionally if you want to mitiate Session hijacking there's a number of other areas to consider.
You need to use SSL on all pages where the session ID is passed (this is to mitigate the risk of the session ID being intercepted in transit (eg, the Firesheep attack).
If the session ID is set before you authenticate the user, you should ensure that a new session ID is issued when the user logs in.
Also if possible the session cookies should be use of the httpOnly and secure flags, to reduce the risk of them being leaked over cleartext channels.
There's some good additional information on the OWASP Site
BTW if you've got more question on the security side of things, there's a stack exchange site specifically for that at Security.stackexchange.com
did cookies based session management to prevent "session hijacking attack"
Whats stopping the cookie being hijacked?
Session managment is a server side thing - You need to server to check (based on the cookie) that the user is meant to be logged in.
I don't think you've improved security here at all to be honest, take a look at this excellent article to see why.
If someone gets hold of the session id then they pretty much hijack the whole session, see Predictable Session IDs vulnerability.