I think I understand the difference between tokens and session ids.
But it seems to me that it has a major security issue so I've probably misunderstood something :
If someone steals my token or my session id then he can pretend to be me, right? Some XSS attack, or some F12 on my friend's computer is enough to see the info, right?
Yes. That's why you wouldn't leave your device unattended to take care of the F12 part.
XSS cannot steal httpOnly cookie.
I've covered mist of these in the following two answers.
https://stackoverflow.com/a/54258744/1235935
https://stackoverflow.com/a/59464645/1235935
Related
I would like to not have to implement things like redis or storing refresh tokens in a database. I would like to utilize the "full power" of JWTs (scalability, no need for storing anything related to sessions/tokens, stateless, etc.)
Say I have a cookie which is set as secure, httpOnly, samesite=lax.
The cookie will expire when the user closes the website, unless the user specified the "remember me" option. And inside this cookie a JWT will be stored which will never expire.
Of course some CSRF protection would also be implemented!
Is this secure enough? How would an attacker ever retrieve the JWT from a client given the requirements (cookie requirements) mentioned above?
If the JWT is completely inaccessible from an attacker then there is no need to revoke the JWT or have it expire at some point right?
To the question "Is this secure enough?", only you can answer and decide if you want to go with this solution or not.
For an outsider point of view; I think a JWT set with no expiration is already not good practice, because by doing so you are kind of giving away some endless access.
Then you write "How would an attacker ever retrieve ....". That is one more unsafe assumption. The proper of a "successful attack" is usually, exactly when an attacker does something in a way you did not expect.
To sum it up I would say: what you are thinking of is possible; but it is not something to recommend.
To get more in depth opinions you may check further documentations or with experts. To start with you may have a look at these few JWT tutorials.
IMHO if you are protecting sensitive information, having long living auth tokens in the cookies is dangerous. A user could be tricked using social engineering to open the dev tools and share the cookie content. Security is pain but pays off in the log run.
There are a lot of questions and answers about session fixation on StackOverflow, however, I am still confused about one thing. People often suggest that storing session in cookies is not enough to overcome the session fixation issue and you should rotate the session id after login. I can imagine that if you only use the session id to identify a user, you may still be vulnerable to an attack. However, I would like to ask about one specific case.
Let's assume that you use a signed cookie to store the whole session. On login you put into the cookie an id identifying the user. After logout, you delete the id. You do not change the session id, but as you change the session itself and you sign it, I cannot see any attack scenario taking advantage of this design. Is session fixation still an issue and, hence, is session id rotation still necessary in this case? If yes, can you provide an attack that could be used? Thank you.
The basics of Session Fixation is that it’s possible for an attacker to make the victim use a session that the attacker has access to. This is generally done by inducing the victim to use a certain session ID that is known to the attacker and doesn’t change after authentication.
Now what you’ve described doesn’t sound like a session identifier but rather a simple client-side data storage of user authentication data.
But nonetheless, if you make the cookie data dependent on data that again depends on the authenticated user which additionally is signed by the server, it certainly will change after authentication and won’t be known to the attacker. Then the security of that scheme depends on its actual implementation.
I'm designing a very secure login mechanism using play framework2. Since Play does not have a notion of sessions and keep things in the cookies (which I like) I was wondering what are the security measures I need to think about. We obviously going to use SSL to communicate the login credentials and also the cookie is going to be encrypted value of some of user's information like their email or userid. Is it possible that someone can sniff that cookie or get a hold of it from another user's cookie and reuse it? how can i make this more secure?
In fact the cookie isn't encrypted. It is signed. This signature comes from the application.secret in your application.conf.
It means that anyone can see the content of the cookie (and eventually try to spoof other sessions or change their login/id/token...)
From Play documentation :
Of course, cookie values are signed with a secret key so the client can’t modify the cookie data (or it will be invalidated).
I am not a security guru, but, if you keep your application secret secret, it seams enough to me.
Discussion about the strength of the signature are welcome !
Well if you want it really secure, you should general communicate via SSL not only for login. Otherwise someone can get the Cookie. The main-problem you have with the cookie-solution or better the play session is that you have no session-timeout. So imagine that I was able to get the cookie, I can use this user account forever. So you need something like a session-timeout. This becomes really tricky if there are more then one request from the same client, because both try to change the same cookie. A workaround is to handle the session timeout via cache, but have in mind that you need a distributed cache solution if you run in a cluster.
You can try to follow changes at https://launchpad.net/permsec the security solution I wrote. This is an open todo I must do.
If there's a risk of eavesdropping the communication and stealing the cookie, you can make things harder for the attacker. For example add IP address of the computer in the signed cookie. If someone else steals it, he'll have to use the same IP address as the victim. It's not impossible but it raises the bar.
My friend and I have a pari for beer.
From wikipedia:
Requiring a secret, user-specific
token in all form submissions and
side-effect URLs prevents CSRF; the
attacker's site cannot put the right
token in its submissions
The atacker can use browser cookies indirectly, but he can't use them directly!
That's why he can't put the cookies into the link using document.write()
Let us look how the logout link is generated. Is it secure way? Can this GET request be faked?
function logout(){
echo '<a href="?action=logout&sid='.htmlspecialchars($_COOKIE['sid']).'>Logout</a>';
}
sid is a session ID, generated for every session
on the server side, the following checking is performed:
$_GET['sid']==$_COOKIE['sid']
Absolutely not! Never use session identifiers for CSRF protection.
As far as why? Well, the answer is simple. Doing so opens the door for session hijacking attacks. Imagine someone copies and pastes the link for some reason into an email or onto the web. Now, the person on the other end of the email has the session identifier of that session. Sure, if they click the link it won't activate the session, but someone who knows what they are doing will still be able to use it.
And don't use a secret cookie either. Cookies are transmitted on every request. So the mere existence of a cookie does not verify that the user intended to make the request.
How to do it instead? Follow the OWASP recommendations. Use a unique, random token that's issued on each request and is associated with the session. Then verify that the token is valid on submission and then invalidate the token! It should be a one-time-use token only. Have it submitted by the form, and not attached to a link directly...
This prosed security system is immune to CSRF. The reason why this works is because in a CSRF attack the browser keeps track of the cookie, so the attacker doesn't need to know the cookie value when he is building the request. If this proposed security system where vulnerable to CSRF an exploit like the following Proof of Concept would log out a browser:
<img src=http://victim_site/index.php?action=logout&sid= />
Clearly in this case sid needs a value, and an attacker cannot obtain this value without using XSS, which makes this a moot point. Using xss an attacker can read a CSRF token to forge requests. This was used in the MySpace worm Sammy.
The use of the cookie a valid, however weaker form of CSRF protection. One problem is that it totally undermines http_only cookies. Ideally a CSRF token and a session id should be a Cryptographic nonce. However, it is more secure to have them be separate values.
Edit: This answer is at least partially wrong. Using the session ID as a CSRF token could lead to session hijacking if, eg, links are copy+pasted around. See ircmaxell's answer and comments.
Yes, because the session ID is both random and associated with the user, it would be an acceptable form of CSRF protection.
That said, it would be even safer to use a different random number, on the off chance that malicious JavaScript is able to grab the session cookie (and session ID)… But if I had to choose between “no CSRF token” and “session ID as a CSRF token”, I'd always pick the session as a CSRF token.
The only potential problem with using session IDs as CSRF tokens is: if someone was able to steal a CSRF token, they would also be able to hijack the associated session… But I can't think of a sensible scenario where that would be an issue.
Now, from the discussion on Marc B's answer, below: using a nonce would provide other benefits (like preventing duplicate form submissions)… But it isn't any more secure against CSRF attacks than the session ID (with the one caveat I mention in the first second paragraph).
See also: CSRF Validation Token: session id safe?
And what's to stop someone from editing the HTML that you send them, as well as the cookie, which you've also send them? Both are are under the control of the user.
With firebug I can trivially change the contents of any page, as well as any cookie.
Now, if you'd modified your version so that the SERVER stores that ID, then it would be harder to hack...
$_SESSION['form_token'] = 's33krit valu3';
if ($_POST['form_token'] == $_SESSION['form_token']) {
... everything's ok ...
}
Since the session data is kept on the server, out of the attacker's hands, this is far more secure than trusting the attacker won't think to modify the cookie.
You owe your friend a beer.
What methodologies do people recommend for mitigating the 'Firesheep' method for website applications?
We have thought about this and from a usability perspective, other than encrypting all traffic to a site, mitigating the attack can be somewhat of a problem for web developers.
One suggestion we came up with was to use path based cookies, and encrypt traffic for a specific path where account operations or personalised interaction happens. This however complicates usability however, in as much as the rest of the site (the un-encrypted - un-authenticated) bit does not know who the user would be.
Does anyone have any other suggestions for mitigating this vector of attack, while maintaining a usable level of usability?
Firesheep is nothing new. Session hijacking has been going on for more than two decades. You don't need "encrypt" your cookie, thats handled by your transport layer. Cookies must always be a cryptographic nonce.
Usually hackers just set their own cookie by typing this into the address bar javascript:document.cookie='SOME_COOKIE', FireSheep is for script kiddies that fear 1 line of JavaScript. But it really doesn't make this attack any easier to perform.
Cookies can be hijacked if you don't use HTTPS for the entire life of the session and this is apart of OWASP A9 - Insufficient Transport Layer Protection. But you can also hijack a session with XSS.
1)Use httponly cookies. (Makes it so JavaScript cannot access document.cookie, but you can still do session riding with xss)
2)Use "secure cookies" (Horrible name, but its a flag that forces the browser to make the cookie HTTPS only.)
3)Scan your web application for xss using Sitewatch(free) or wapiti (open source)
Also don't forget about CSRF! (Which firesheep doesn't address)
Well I found an interesting article on GitHub that describes a method of mitigating the firesheep attack.
https://github.com/blog/737-sidejack-prevention
Anybody tried taking advantage of the "Web Storage" in HTML 5 to store a shared key (passed during SSL-encrypted responses during authentication) that is used by javascript to alter the session cookie over time?
That way, the stolen (unencrypted) session cookies would only be valid for a short amount of time.
My guess is that Web Storage is segmented by port (in addition to host), so it wouldn't be possible. Just throwing that idea out there in case anybody wants to run with it.
When user logs-in, store the IP-address in the session.
On each subsequent request from this session, check that the IP-address matches the one stored in the session.