Lets say session for an application is opened and its session expiry time is 15 min.
Scenarios:
Leaving the application for 15 min and doing some action after that - leading to Login Page.
In other way I am removing the Browser cookies by using (Ctrl+Shift+Del) and trying to navigate in the application - leading to Login Page.
The Question is: Will both of the above cases were one and the same or will there be any difference in the behavior.
The first scenario is based on a cookie expiring while the second one will have the cookie removed.
If you are guaranteed the refresh for the first case is made after the cookie expired, then the client behaviour will be the same (login page) although the internal workings will be different (check the cookie exists vs check its expiry date)
If you can't guarantee the operation will happen after the cookie expiry, then you won't get the same outcome.
Depending on what you do on the server, you might end up with multiple sessions for the same user in the second case, because the server doesn't know the user has deleted the cookie (there are mechanisms to compensate for this though).
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.
I can redirect a user to home page upon session logout.. this was very simple. However, if an user had logged into the app and had the page open, even on session time out, he is able to perform all the functions(this is bad).
The redirect does not happen until the page is refreshed, or submitted to the server... there are some update functions that could be done by the user even if he is not currently logged in... I have done a lot of research but unable to fix this solution. I also found this thread but it seems to have no proper answer:
Spring Security 3.1 - Automatically redirect to login page when session-timeout occurs
For example, most of the banking sites log you out after a time out.. they do not wait until you come back and then submit a request before you are redirected to home page.
HTTP is stateless. To achieve some form of state the server can maintain a session for each user by giving them a session id on their first request. The user would have to resend that session id on each future request to identify that the other requests happen within the same session.
Because the session is maintained by the server, there is no way to notify the client that the session has timed out.
Instead, if the user makes a new request when the session is timed out, their session ID is no longer good and therefore you can take a particular action like redirect them to login page.
Assuming nothing works out. You may want to consider below mentioned approches:
Approach 1:
Create a cookie on browser and have encrypted timestamp in it that will contain last visited/request timestamp from browser, for each request first get get this cookie value and compare with the pre-defined session out time, if session-out time reached then redirect user to error page else serve the request. On logout delete the cookie.
Why encrypted value for timestamp: if somehow user gets to know about cookie used for session timeout then (s)he can change this value in browser and keep on sending this request.
Approach 2:
You can also achieve this by making an entry in your database for every logged-in user and updating timestamp in this database for each request. For each incoming request get this timestamp from database and compare it with pre-defined value for timeout and handle accordingly. On logout delete the entry.
In both the approaches explicitly perform response.redirect("errorPageUrl");
Looking at the OWASP Session Management Cheat Sheet, every time a session expires, must a user go through the same Pre-Auth --> Auth --> ... steps to make a new session?
For example, if a session expires and the web app requires authentication, will the user have to log back into the web app before getting a new session?
Sessions are maintained with cookies.
Http is a stateless protocol. Every request to server works in isolation. No request has any information about previous request.
Say a user named A logs in to the site. This site works with session and sets session data for a user. Internally the server creates some value and associates with a particular user. A value 12345 is computed and associated with user A. The server decides to give this value's name as sessionId. It sends sessionId in the cookie and this cookie will be stored on the user's browser. Next time the user A makes a request this cookie will be sent to server. Server reads for cookie sessionId, and finds it. Then it sees with what user is the value in this cookie i.e 12345 is associated. It finds that this value is associated with user A and so its the user A, who is making the request.
Say this cookie expires, can be for various reasons. Either user deletes the cookie on his end. Or after certain days, server cleans this association between user and the session. In that case server will not be able to know who is the user making the request. And hence the entire flow of login by user, seesion generation will have to take place.
So, yes, if a session expires and the web app requires authentication, user will have to login again
Yes, the user has to log in again. Also, it's important that a new session gets a new session id, as an attacker could have gained the session id. If you re-authenticate the same session id, the attacker would gain access as well. See session fixation attack.
Depending on the safety requirements, you might also have to implement a maximum time to life for every session. Usually an attacker would take over a session and try to keep it alive as long as possible. Expiring the session after a certain amount of time, even if it is active, is an effective way to ensure that attackers can only have access for limited time.
The premise is simple.
New customer arrives at our site, is redirected to the register/login page (since they are a new visitor and no cookie is present) and after registering or logging in (if already have an account but visiting from a different machine/browser) they are taken to the home page.
Every time they subsequently visit, they should not see the register/login page (unless they explicitly log out, cookies are disabled/blocked, or they visit from a different browser/device).
I would think that theoretically, setting the cookie value to an absurdly high number (in our case, 30+ years) and checking for the presence of that cookie before the redirect to the register/login page would work.
In our case it is not. I feel like the session is still lasting roughly an hour or so before a visit back to the home page of the site redirects a user to register/login.
So what am I missing here? Any advice?
---edit---
I had been assured by our web host that session.gc_maxlifetime was not the issue. I set it to 86400 on our development server and after leaving my browser idle overnight, I returned the next day and I think it's working as intended.
One issue I have with this is that it also sets the magento admin timeout to the same value, which may introduce a security risk if an employee is given Magento admin access and then gets fired/quits/etc. I certainly don't want their session to continue for as long as we want customer sessions to last (months).
I'm hoping that the CONFIG>>ADVANCED>>ADMIN>>SECURITY>>SESSION LIFETIME setting is not overridden by this.
Your problem is most likely with the Php session value you need to increase it to match the value in the cookie duration; on your php.ini put the following:
session.gc_maxlifetime = 86400
You need to replace the '86400' value with what equivalent time that you want the session / cookie to last I would advice that you set your sessions and cookie value'604800' that's about a week.
What is going to happen on your server is that magento is going to a session file per session under the var/sessions folder. This can potentially can cause your server to run out of inodes , depends on your server configuration.
Cheers!
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.