I am getting a weird ColdFusion Session loss issue when taking I am making a payment with a card payment on return to the website. this is happening on both versions ColdFusion 2016 / 2021
The transaction takes the user away from the site with a post goes to another website to get a 3dsecure token and then is returned to my website, then the session is completely lost. I have attached the CFID=xx&CFTOKEN=xxx&jsessionid=xxx to the return.
I am using samesite cookie, secure cookie and httponly cookies.
any help with be greatly appreciated.
Related
I run a Django site that hasn't undergone any updates in the last few months, yet all of a sudden I'm receiving a bunch of emails from users saying they're getting the following error:
CSRF Failed: CSRF cookie not set.
The bizarre thing is that refreshing the page does not fix the issue. The only way to resolve it is to have them manually clear their browser's cookies.
Bear in mind that they are still logged in after refreshing. So even though they aren't getting a CSRF cookie, Django is acknowledging their session.
While I'm glad they can clear their cookies to fix it, it's concerning to me as I can't fathom what is happening. It started happening around the same time that iOS 14.5 came out, so I initially thought it may somehow be related to that, but I just received a report from an Android user.
Has anyone run into this before? Is there any way to resolve this without putting a banner on the site explaining to clear cookies if you see the error?
Thanks!
Thanks for your comments and suggestions! I ended up figuring out what was going on.
So for some reason, Django won't create a new CSRF cookie (even if it has been expired/deleted) if the session cookie is still valid. This seems like a bug, but maybe there's a security reason for it.
In my case, I had extended SESSION_COOKIE_AGE to 60 * 60 * 24 * 365 * 10, or 10 years. It turns out the default value for CSRF_COOKIE_AGE is 1 year. As such, everyone that had been logged in for a year no longer had a valid CSRF cookie, and Django wouldn't issue them a new one because their session was still valid for another 9 years.
This may sound like a very trivial doubt, but I need some help here.
I have set up Application load balancer with OIDC authentication. After logging into my application, using chrome developer tool I looked into the client application cookie. Found that AWSELBAuthSessionCookie-0 and AWSELBAuthSessionCookie-1 have an expiry 2070-10-04T05:02:12.122Z which is almost 50 years from now. Since the ALB isn't forwarding this cookie to my application (EC2) which resides behind the ALB, I am unable to reset the cookie's expiration. I am using Flask to read the headers. Any leads to reduce the AWSELBAuthSessionCookie's expiry will be helpful.
quite an old question already but here are my 2 cents:
invalidating a cookie is somehow just a set-cookie with an expired date, so I don't think you need to be able to read the cookie from the request to invalidate it. I have not tried but I would just do something like
Set-Cookie "AWSELBAuthSessionCookie-0=deleted;path=/;expires=Thu, 01 Jan 1970 00:00:00 GMT;"
for the 2nd point (from #codematix), to logout you need to invalidate the auth cookie AND to redirect the user the logout page configured in your IDP (probably to also invalidate the tokens, otherwise the ALB would just revalidate the tokens and re-create a session). See https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html#authentication-logout-timeout
I think you are confusing the ALB session (JSESSIONID cookie if I recall correctly) with the auth session cookie here.
Once again I am no time to validate this but hope that helps :)
I too have the same question, in my case it is being set to Expires=Sat, 29 Aug 2071 22:16:30 GMT. And I am unsure, even when I have set the Session timeout to 14400 seconds which is about 4 hours in the ALB authenticate rule.
It is quite unexplainable as to why this large expiry time would be set despite an explicit smaller value.
I am using Django Basic authentication and Session authentication inbuilt API.In my application I have given a session timeout value of 24 hours in settings.py.
It is working fine but in some chrome browsers it is doing session timeout at every 10-15 minutes.
I have checked session cookie after successful login it is showing correct expiry date.but after 10-15 minutes when session timeouts, cookie expiry date automatically changes.
Please reply if someone has faced some issue.
When I'm logged in to a google account, site responses contain this cookie:
set-cookie:SIDCC=xxx; expires=Mon, 27-Nov-2017 06:12:16 GMT; path=/; domain=.google.com; priority=high
However when I restart Chrome and visit same site, no cookie is sent. Why is that? I thought that expires makes it persistent.
There and multiple cookies are generated by the server and cookies are stored on the browser.
There are few cookies are having the short expiry and some have the long expiry. If cookie gets expired (deleted from the browser) then the browser will not append that cookie in the request. So sever again set the cookie on the browser.
Since cookie are generated by the server and cookies are used by the server so whenever the server wants to set cookie it can change. Usually, some cookies are persistent and some are not persistent always.
So there will be a case some cookie is stored for a long time duration but server used to the keep on changing. So, In that case, it will set the cookie again.
As per your example, this SIDCC cookie is used by the google apps. So this cookie is kept on changing the other cookie like SID and HSID are not changing on browser reopen. There few cookies like NID, SAPISID, and Compass is also changing. The SAPISID is changing after the few transaction or after a particular transaction.
How long can I use a session cookie? I have a client application where I authenticated to a SharePoint site and I am using the cookies for navigating through the subsites. I am saving the cookie and reusing the headers to login to the site at a later point without authenticating again. There is no expiration date set. How long will the cookie last and when should I authenticate back again?
The expiration of session cookies varies from browser to browser. I was unable to find any kind of reference giving the current specifics per browser. It used to be that session cookies would be destroyed when the browser was closed, but some browsers now have settings that, if enabled, will cause session cookies to persist past the browser being closed. For example, Firefox's "When Firefox starts: Show my windows and tabs from last time" will cause this to happen, somewhat surprisingly. The same goes for, "On startup: Continue where I left off" in Chrome.
I don't really care for SharePoint so I haven't used it in a while, but as I recall it uses ASP.Net Forms Authentication, pulling the configuration from the web.config just like any other ASP.Net site. That being said, you're not really concerned with the timeout of your cookie. What you care about is the timeout of your server-side session token - that is to say, how long the data contained in said cookie will be recognized by the server. That is set by the timeout property in the forms tag of the web.config file for an ASP.Net app:
<system.web>
<!-- ... -->
<authentication mode="Forms">
<forms timeout="2880" />
</authentication>
<!-- ... -->
</system.web>
If there's no expire it's going to be around until the browser is killed. Normally in ASP.Net the session cookies are set with a 20 minute timeout. That's usually pretty good. Depending on your app, you may want a javascript timer as well. Otherwise the browser won't understand when it's logged out until a page refresh happens and sensitive data can be exposed. You'll see this implementation on any online banking site.
(Edit to clarify from downvote)
Session cookies do, in fact, stay around until the browser is closed. You can look it up here: http://www.allaboutcookies.org/cookies/cookies-the-same.html
The above answer is also correct in that some newer browsers will recover session cookies after a crash/close.
#Grinn, you do bring up a good point able the Ticket. When using ASP.Net Forms auth, an encrypted Ticket is placed within the session cookie. They cookie can still be in place as far as the browser is concerned, but if the datestamp inside the ticket is expired, it will be considered invalid.
If you're using some semblance of Forms auth with Sharepoint, you should probably just write your own membership provider that can crack the Ticket in the cookie, but disregard if the datestamp is expired. Building Custom Membership Provider