Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
Options
How secure is the cookie handling? Is "Keep me signed in" safe?
almostbasic
New
I am an admin on a 2.1.10 forum (soon to be 2.1.11), and we had a user report a security vulnerability on the site, and I wanted to see how valid it is.
They claim that because the cookies don't expire with the browser session, that it's possible for someone to steal those cookies and use them to login to the forum and steal the account.
Is there any validity to this claim? Would removing the "Keep me signed in" option fix it?
0
Comments
I don't believe that to be a valid concern, no. That would make the entire Internet insecure.
Look at the content of your cookie from this site.
How would you retrieve your user details from that?
Cookies are sandboxed, and it entirely up to the client when to expire them or not or to accept them in the first place. You can only send guidelines.
Cookie stealing or session hijack generally doesn't work this way. If someone is in a position to attack the client program, and browse the file system they can already control the computer, this cookie stealing is the least of your worries.
If someone already has malware on their computer it can piggyback the browser sessions, but that is nothing to do with the security of the framework, but to do with their own home security practices.
If someone is in a public place, then obviously with the same browser data they could access the site. This is not how internet cafes, or public libraries operate their services. They have fresh computer sessions, which are separate, so everything including the browser data would be separate.
Another myth about cookies is they store personal information. Cookies can store personal information, but only an idiot would use them this way for a framework. Cookies are a secure reference to something on the server, be it for authentication or something else.
grep is your friend.
Thank you, you all said what I thought was the case, but I wanted to get some input from the Vanilla gurus!
Thanks again for your help.
I can intercept the headers on login with Burp Suite, then go physically log out of the site, close the browser session, then open a new browser, and send those headers from Burp Suite and I am logged in. So, if someone is able to capture the request on login, they will be able to log in over and over again with that method.
It even works after clearing my cache and cookies, which leads me to believe maybe it's more of a problem with how the login is authenticated?
This is a man in the middle attack and requires access to the client machine to install the Burp SSL certificate, no?
Also, the request should stop working to "log in" after an hour or so due to the transient key mismatch, IIRC.
Search first
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.
Thanks for the help. What you're saying makes perfect sense.
Basically whatever method used either require some compromised client or it XSS which is only relevant when the browser is active anyway.
grep is your friend.
There is a saying: why try crack the lock when you and knock the wall down? Essentially what the Hatton Garden Vault Heist guys did, they drilled through the wall, and left the door.
Hackers will be looking for exploits. If the really did want to crack the authentication, cookie peristantace will unlikely be relevant.
The closest analogy to lock picking remotely is something like timing attack. That is like lining up the tumbler, but it takes quite a lot of time weeks. It is also guarded against in this system.
grep is your friend.