I'm using Codeigniter sessions for logging in users. For reasons that have always been mysterious to me, sometimes a user session gets destroyed and they have to log in again.
Because Codeigniter sessions are cookie based I assume I need to be looking at the browser to try to understand why the cookie got destroyed.
First of all, is that true? And if so, might someone suggest a method (php, js, browser dev tools?) to log the errors that lead to each session getting destroyed?
I would try checking the cookie timeout setting in ./application/config/config.php and make sure this isn't something ridiculously low.
$config['sess_expiration'] = 7200;
There are many other potential causes for this behavior, all of which depend on your environment. For instance:
If your code runs on multiple servers behind a load balancer not
configured for "sticky sessions", then you will hit a new server
(potentially) for every request, causing your session to be
recreated.
If your website utilizes multiple domains, your cookie will not be
valid for all domains, only the one who created it.
But without knowing anything about your code or environment, I would recommend using firebug or chrome developer tools to check your cookie from your browser while checking what is being requested and responded in the network layer.
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.
Steps to re-create the issue:
Login with Admin Credentials and copy the session cookie.
Open another browser, Login as another user, paste the session cookie of the admin. Refresh the page. Now, you'll be
logged in as Admin.
How to solve this issue? Any suggestions would be of great help.
Tried using the event subscriber to get the previous session before drupal loads the cookie session, but no luck with it.
This is not a problem, I mean, of course, Session Hijacking is a really big concern - but standard defences are fine.
These are the controls that I know are widely known/used:
Ensure HTTPS is used everywhere,
Only use a securely created random string for the cookie value,
Set the secure flag on all cookies. This will ensure that they are only sent over an SSL connection,
Change the session cookie on each new login attempt.
All of Drupal 8's cookies are secure by default.
The exception is BigPipe's no-JS cookie, see https://www.drupal.org/node/2678628 — but there are no security consequences there.
I know some very sensitive applications may also store - for each session - the following additional information:
SSL Session ID
HTTP User Agent
Remote IP Address
In my point of view, I wouldn't bother with checking the HTTP User Agent or the remote IP address. They don't add that much security and they will break legitimate use in certain scenarios. Checking the SSL session ID (SSL session binding) would be OK from a security perspective, but could be painful to implement, the other defences are fine.
If your concern is Cookie Theft via XSS, the best defence is to use standard methods to avoid XSS bugs in your web application. See OWASP for plenty excellent resources.
You may find a lot of best practices to write secure code for Drupal 8 here: https://www.drupal.org/docs/8/security/writing-secure-code-for-drupal-8
You may also find a pretty old discussion about this on Drupal here: https://www.drupal.org/project/drupal/issues/19845
I have a Spring MVC App and I have an issue with invalidated sessions.
The app performs AJAX requests that are all authenticated/tied to a session (hold a JSESSIONID)
So here's what happens. Let's say I'm in the app authenticated with a session. If I go into Tomcat and invalidate that session, then the next time an HTTP request gets made, Spring forwards me to the login page. Once I login again, Spring authenticates me fine, but then a number of my AJAX requests get HTTP 403 errors, continuously.
If I go into the HTTP Headers of the requests that get the 403s, I notice they have 2 JSESSIONIDs, one of the authenticated session, the other one of a session that holds only this attribute:
SPRING_SECURITY_SAVED_REQUEST DefaultSavedRequest[<OLD URL>]
So these sessions are not authenticated sessions so they are causing Spring to return a 403.
The issue is that this persists until I kill the browser (on some mobile devices that doesn't even work, and I have to go into settings to clear the browser cache).
Any suggestions?
this is a big problem because it's happening when Sessions invalidate themselves because of TTL, and we're stuck with users who get booted out, log back in and still get 403s, forever, until they clear the cache.
One thing to note is that Spring Security invalidates the existing session when you login and creates a new one, copying the contents of the old one across. This is intended to create a new session identifier to avoid session fixation attacks. You can try disabling this feature to see if it is related to your problem. It sounds like these are the two sessions you are talking about.
However if there are two JSESSIONID headers in the request then it sounds like a problem on the client side. You should work out why your client is sending two values. Also, it sounds like there may be an issue with Tomcat on the server side if you are still able to read the contents of the previously invalidated session.
Also check that Tomcat isn't sending two JSESSIONID values in the login response. There was an issue ages ago where it was doing just that, but it's unlikely you are running such an old version of Tomcat.
I have a MediaWiki running on multiple AWS instances and login and registration is broken. The session.save_path is set to /tmp which is writeable and readable by anyone. I use Apache2 and PHP5 as well as MEMCACHED.
Whenever you try to login you either get informed that there is protection against session hijacking or that you have cookies off. These are the errors:
There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again.
Wiki uses cookies to log in users. You have cookies disabled. Please
enable them and try again.
I use a shared cookiedomain in the format ".domain.tld" and the entire domain is behind CloudFlare and an Amazon ELB load balancer. All LocalSettings.php are the same and the Apaches have shared configurations.
Per Aaron Schulz, don't use the default session handling, it's disastrous.
As you have memcached enabled, add
$wgMainCacheType = CACHE_ANYTHING;
$wgSessionsInObjectCache = true;
in your LocalSettings.php and let us know if things improved (they definitely should).
I am currently working on the authentication of an AJAX based site, and was wondering if anybody had any reccomendations on best practices for this sort of thing.
My original approach was a cookie based system. Essentially I set a cookie with an auth code, and every data access changed the cookie. As well, whenever there was a failed authentication, all sessions by that user were de-authenticated, to keep hijackers out. To hijack a session, somebody would have to leave themselves logged in, and a hacker would need to have the very last cookie update sent to spoof a session.
Unfortunatley, due to the nature of AJAX, when making multiple requests quickly, they might come back out of order, setting the cookie wrong, and breaking the session, so I need to reimplement.
My ideas were:
A decidedly less secure session based method
using SSL over the whole site (seems like overkill)
Using an iFrame which is ssl authenticated to do secure transactions (I just sorta assume this is possible, with a little bit of jquery hacking)
The issue is not the data being transferred, the only concern is that somebody might get control over an account that is not theirs.
A decidedly less secure session based method
Personally, I have not found using SSL for the entire site (or most of it) to be overkill. Maybe a while ago when speeds and feeds were slower. Now I wouldn't hesitate to put any part of a site under SSL.
If you've decided that using SSL for the entire site is acceptable, you might consider just using the old "Basic Authentication" where the server returns the 401 response which causes the browser to prompt for username/password. If your application can live with this type of login, is works great for AJAX and all other accesses to your site because the browser handles re-submitting requests with appropriate credentials (and it is safe if you use SSL, but only if you use SSL -- don't use Basic auth with plain http!).
SSL is a must, preventing transparent proxy connections that could be used by several users. Then I'd simply check the incoming ip address with the one that got authenticated.
Re-authenticate:
as soon as the ip address changes
on a time out bigger than n seconds without any request
individually on any important transaction
A common solution is to hash the user's session id and pass that in with every request to ensure the request is coming from a valid user (see this slideshow). This is reasonably secure from a CSRF perspective, but if someone was sniffing the data it could be intercepted. Depending on your needs, ssl is always going to be the most secure method.
What if you put a "generated" timestamp on each of the responses from the server and the AJAX application could always use the cookie with the latest timestamp.
Your best bet is using an SSL connection over a previously authenticated connection with something Apache and/or Tomcat. Form based authentication in either one, with a required SSL connection gives you a secure connection. The webapp can then provide security and identity for the session and the client side Ajax doesn't need to be concerned with security.
You might try reading the book Ajax Security,by Billy Hoffman and Bryan Sullivan. I found it changed my way of thinking about security. There are very specific suggestions for each phase of Ajax.