Sometimes, at OpenAM Log-in page, right ID/Password failed to Log-in. (Chrome Browser)
- After Log-in, Browser return to Log-in page.
In this situation, I checked the Authentication Error, but no error found.
And in the same environment, Internet Explorer succeeded to Log-in.
In Chrome, I opened developer window, and I found iPlanetDirectoryPro cookie value is null.
I think, After successful authentication, Browser failed to create iPlanetDirectoryPro cookie value.
Then, I unchecked 'Enable phishing and malware protection'.
After that, Chrome Log-in succeeded.
And after one success, though I return to check 'Enable phishing and malware protection', Chrome continue to succeed to Log-in.
Why this phenamenon occurs?
Need to fix-up something?
Related
Each time I log into Instagram, it shows that there are two sessions under Login Activity even though I've only logged in once and have only one session open in the browser? Is anyone else experiencing this? Been seeing this for the past few months.
It must have to do with session cookies. I would be storing a new session cookie instead of updating it and passing them both while validating your session. Although, I do not think this should pose a security threat unless these cookies are safe. You can verify that by inspecting the cookies passed by intercepting the requests either from the Network tab in the browser Developer Tools or by using a tool like Burp Suite or OWASP ZAP if you're looking for an open source alternative.
I'm using Identity Server 4 version 3.1.2. I logged in with a user information in Chrome and with another user information in Firefox in the same computer. If I copy the first user token saved in Chrome Cookies and paste it to the Firefox Cookies (replace with second user token) and refresh Firefox (pressing F5), Firefox logged in user will be changed to Chrome user and it is a security issue. What can I do to prevent this problem?
There is nothing you can do to mitigate this issue for sure. You may check if the user agent header is what you expect it to be, but then someone will fake the user agent header with a plugin and you are back to square one. All the other headers can be bypassed in a similar fashion.
(Although if you decide to trust the user agent header then this is the solution for you).
Checking for IPs, sockets, TLS sessions has proven to generate to much problems to be considered a solution at all.
My application is a J2EE web application running using Jetty server. when I login to the application and open a 2nd tab, it shows automatically the application without asking for login credentials. But, when I open 3rd tab, it is asking for login/password again. The same works fine in IE.
How to make the 3rd, 4th tab work without asking for login credentials when I am already logged in the same browser ?
We found the issue. The session was getting invalidated in the login service when opening a new tab in the browser. We removed Session.invalidate() and that fixed the issue.
When an application is logged in with a user and password, then opening a tab in the same browser with same application url will automatically takes us to the application without asking for user, password. This is browser behavior. All browsers support this.
Question 1
My secure web application sets a session cookie for authenticated users which is not cleared even after I close my Chrome browser.
As a result, when a user tries to hit the dashboard page of my application after re-launching the browser (even restarting machine!), they are not asked to login again. Chrome is NOT set to "continue where I left off" which is also my next question.
I tested my bank's site under the same settings and it seems to force log out the user even when Network tab shows that same cookies are being retained (and sent with initial request header) for bank site as well. My server is Apache over SSL.
Can someone please point to some resource where I can handle this scenario because Chrome clearly is not clearing session cookie at the time of browser closing.
Question 2
Now with the setting "continue where I left off" where it basically persists your sessional cookies and practically you can remain authenticated forever, is there a way to override/work around this Chrome feature.
When I see even my supposedly secure bank site letting a browser bypass security like that, it kind of makes me unnerved. Any suggestions there?
Cheers!
What ended up fixing this issue for me was to uncheck the:
Continue running background apps when Google Chrome is closed
setting under the SYSTEM section.
Hope this helps save some headaches....
See update at end of question
In Rails 4 I understand that sessions are, by default, only supposed to exist for the browsing session. If you closed your browser, the sessions should no longer exist.
However, I'm not finding that to be the case. I have a Rails 4 app using all the defaults provided by Rails. I was working on some authentication code and ran into this problem.
When the user logs into the system, they have the option to "remember me" via a checkbox. When they check the box, the session should have an expiration of 2 weeks. The goal is that when the user logs into the system and closes his browser, he can then open the browser up again and use the app without having to authenticate again.
On the flip side, if the user does NOT want to check the "remember me" box and logs in to the app and closes the browser, when the browser opens again the user should be required to authenticate again because his session "expired" when the browser closed.
The problem is that my sessions never go away. I tested some simple code where on page 1 I set a session variable in the controller and then on page 2 I display that session. When I close the browser and go to page 2 (not page 1 so session is not set again), the session still exists as it did before.
I thought sessions were supposed to expire when the browser closed by default? I have also tried this with "cookies" instead of sessions and get the same result.
In short, how can I get a session/cookie that expires/dies when the user closes their browser? It doesn't seem very secure to me to have all sessions persist if the user doesn't want them to, and I'm not going to have my users delete their cookies everytime they close their browser (may be on a public computer where their login info should ONLY persist until they close the browser).
Update
I think I found what may be causing the problem. I'm using Chrome as my browser and I had it set to "remember where I left off" when the browser closes and opens. This seems to save all sessions/cookies. I verified this with Gmail as well. If you have the "remember where I left off" set, but don't set the remember me token in Gmail, Gmail opens right back up when you close/open browser. If you tell Chrome to open a new tab on open, then Gmail sends you to the login page like I expect.
So that solves one problem, but the overall problem still persists. How can I make this "secure"? Let's say you're at a public computer, and a malicious user sets the browser to "remember where I left off" when the browser opens. So you login to an app (such as Gmail) but don't check the "remember me" box. So when you close the browser you expect your login to be "secure". But if another user opens the browser back up, he's already logged into your app.
Is this something I can feasibly prevent? If Gmail has this flaw (with an army of very intelligent developers) should I be bothered that this situation exists?
The browser "remember where I left off" functionality was indeed the problem. Removing that option resulted in the "expected" behavior for my cookies/sessions.