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.
Related
From what I understand and have read about sessions, a website, like Facebook, will store a code on your computer that your computer sends back to Facebook every time you visit their site. This saves you the trouble of logging in every time you want to see your news feed.
My question is, how is this in any way secure? Can't anyone write a simple program to find this code on your computer - just like Facebook does? Or if you let your geeky friend use your computer, how do you know he doesn't copy your session codes and just use your account from somewhere else?
I read that sessions are more secure than cookies because cookies actually carry information like your username, password and other vital info. But if a session code can provide access to your whole account anyway, isn't a session just as insecure?
Are there any other factors at play that I don't know about or are sessions really this insecure?
My question is, how is this in any way secure? Can't anyone write a simple program to find this code on your computer - just like Facebook does?
Yes. Someone can do that. And they can steal your session credentials. If your computer is compromised, you can't build any form of security on top of that. If you can't trust the computer, you can't trust the browser. And if you can't trust the browser, there's no way you can possibly trust the website.
So we need to start with a fundamental assumption. To secure the website, we must assume the browser (and hence the computer) is secure.
If you can get code onto the computer to search for the session identifiers, it's game over already, since you can typically do much worse while you're there.
Or if you let your geeky friend use your computer, how do you know he doesn't copy your session codes and just use your account from somewhere else?
You don't. This is why you shouldn't let friends use your computer (among other reasons).
There are some techniques that can be done to verify the session came from the specific computer. But they tend to be either insecure (like verifying user agents) or fragile (like verifying IP addresses).
I read that sessions are more secure than cookies because cookies actually carry information like your username, password and other vital info. But if a session code can provide access to your whole account anyway, isn't a session just as insecure?
Sessions are no more secure than cookies, because the session uses a cookie for identification. Sure, the specific data doesn't leave the server (so it doesn't leak), but the attacker can resume the session.
Are there any other factors at play that I don't know about or are sessions really this insecure?
The key here is who are you trying to protect against. Specifically, what threat model:
A friend, who you give admin access to your computer (let them borrow with a privileged account)
You can't reliably protect against that. If your users let others borrow their computer, you, as a website operator, can't help that unless you don't use a session at all and require users to authenticate every action.
Simply don't do it, or give them a clean guest account. Or better yet, use a chromebook, and let them sign in with their own account.
An attacker getting code onto the computer
You can't help that.
Someone snooping the network traffic (read-only) like a network packet sniffer.
Use TLS (HTTPS)
Someone man-in-the-middle attacking the network traffic (read/write)
Use TLS (HTTPS)
Someone attacking the server
Secure your server!!!
In general, to figure out how to secure something, you need to consider the vector the attack is going to come from. Some attacks you simply can't defend against. And some, you just need to educate the user about.
Session IDs are stored in cookies, so their security is the same as that of cookies.
Cookies are handled by your browser, which takes care of protecting them to the extent that it's possible.
No website can "ask your browser for a cookie" (and that is not what Facebook does). Instead, when accessing facebook.com, your browser sends along your facebook.com cookies, but not your google.com cookies.
Of course, "writing a simple program to find this code" would be easy, but distributing it wouldn't be that easy (i.e. you're talking about distributing malware), and it's definitely not what Facebook does to get access to the relevant session cookies.
There are several additional ways to protect cookies from unauthorized access (to a certain extent). One of them is to make them "HTTP-only", so that they aren't accessible in Javascript (they'll still be sent to Facebook's servers, but the browser won't expose them to anything else).
Note that cookies are indeed as secure as the browser itself. If your browser is "compromised" (by your geeky friend), then so are your cookies, and so is your session.
So with Firesheep, everyone in a public Wi-Fi now has a one-click session hijack tool.
The way it works - to my understanding - is that it simply captures all traffic and grabs the session cookie (so it doesn't steal passwords).
From my understanding, this also means that a HTTPS secured login does not solve this alone, as further HTTP traffic would include the Session Cookie in clear text again.
Tying the session to a specific IP address is useless thanks to NAT, and tying it to the user agent is easy to spoof.
So is 100% HTTPS at all times the only way to prevent this type of session hijacking? Couldn't people simply sniff the entire HTTPS Traffic including the handshake, or is this stuff safe? (I'm thinking of replay attacks, but have no knowledge in that area.)
Of course, not using public/open Wi-Fi Networks is the better choice, but I'm still interested what a website developer can do to protect his/her users.
Firesheep is nothing new. Session hijacking has been around for as long as web applications have been using Session IDs. Usually hackers just set their own cookie by typing this into the address bar: javascript:document.cookie='SOME_COOKIE'. This tool is for script kiddies that fear 1 line of JavaScript.
Cookies can be hijacked if you don't use HTTPS for the entire life of the session and this is a part of OWASP A9 - Insufficient Transport Layer Protection. But you can also hijack a session with XSS.
1) Use httponly cookies.
2) Use "secure cookies" (Horrible name, but it's a flag that forces the browser to make the cookie HTTPS only.)
3) Scan your web application for XSS.
Also don't forget about CSRF! (Which Firesheep doesn't address.)
The Rook has answered some of it, I'll just answer the other parts of your question.
Is 100% HTTPS at all times the only way to prevent this type of session hijacking?
That's right. 100% HTTPS is the only way. And 100% is key.
Couldn't people simply sniff the entire HTTPS Traffic including the handshake, or is this stuff safe? (I'm thinking of replay attacks, but have no knowledge in that area)
HTTPS has built-in protection against replay attacks. If implemented correctly, HTTPS is truly safe.
Even if HTTPS is implemented correctly, there are ways to get around it. SSL Strip is one such tool. The tool doesn't exploit SSL, it just exploits the fact that people always type mybank.com in the url instead of https://mybank.com.
I do beleive SSL is cheap and a complete solution. But till you dont have it or looking for some extra layers here is how to protect your SESSIOn data.
As always defence in dept is the way to go.
1st Use Sessions to store user login data
2nd If admin logged in also check for DB, might slows a little but as there is a small number of admins and rest are users this is a feasible security plus.
3rd PROTECT YOUR SESSION <= !
Session protection:
Put session start into an object file where you call an "is_session_valid()" function on self construct. This function would check for (IP / TIME / Browser) for $_SERVER superglobal, and store them in session.
Up on Next load see if values are the same if not just waste no more resources logout user and show index page.
This is not a complete solution as it might be same browser on same network e.g. Wifi with lot of users and session hijacked might also be recent (in time).
But till no SSL is used this is FAR BETTER then nothing. Anyhow rarely happens that the victim and the hijacker use same everything....so this effectively mitigates chances of successfull attack even without any SSL!
Original idea by Kevin Skoglund if ineterested in securing your APP see his secure PHP tutorial.
https://www.lynda.com/PHP-tutorials/Creating-Secure-PHP-Websites/133321-2.html
P.S. Several other defenses (CSRF least) needs to be used to have a somewhat secure AP
Bye :-)
Regarding this security issue: http://techcrunch.com/2010/10/24/firesheep-in-wolves-clothing-app-lets-you-hack-into-twitter-facebook-accounts-easily/
Is it true to say "any time a user logs into a site, and isn't redirected to SSL/TLS/HTTPS connection, that the session cookies are vulnerable"?
What is the best solution to protect a Facebook credentials, and how does it work?
Is there any way to have a secure session and not have SSL/TLS? In other words, is there any way to make it so that cookies on one machine can't be replayed on another?
The reason the last question is important is because Google AdSense does not support SSL/TLS and therefore will force the designer to expose all cookies. This will in turn affect every site that relies on AdSense
The problem is the cookies and send in clear on the network if you don't have SSL/TLS.
Anyone listening to the TCP/IP traffic can read unencrypted data and can read you cookies.
When you have them you can copy it on your own computer and it will work...
You need SSL/TLS !
When you are transmitting data in the open (unencrypted) there is NO WAY to protect your information, especially not using a cookie which is a well-known and widely used protocol for storing insensitive user information. You may try tricks and hacks to assert that only the person to whom the cookie was issued is the one who can use it, but that is not what cookies were designed for. COOKIES ARE NOT A SECURITY FEATURE!
If you want privacy, use encryption. It's as simple as that. SSL certs are cheap (as low as $10 per year). If security and privacy are a requirement, there is no excuse not to use SSL.
For your own sites, you can design cookies to be more secure: http://jaspan.com/improved_persistent_login_cookie_best_practice
But because Facebook hasn't done this, the only option if to use SSL.
Hey just a quick question for any experts out there. I have a site that lets users interact through messages and to sign up you just make a username and password, verify your age, and optionally, add an email. There isn't really any sensitive information I suppose. Is it worth using https. Will it prevent session hi jacking and will it hinder performance?
Anytime you use a username/password you should absolutely secure the entire session with HTTPS. The cost to you is fairly minor compared to the potential cost to your users if their passwords are exposed. Research consistently shows that people use the same password for nearly every system they access.
Additionally, beyond the risk of password exposure, consider that your site is a communications tool. What's the potential risk or harm to your users of being impersonated? Of having malicious messages sent under their identity?
It's just not worth the risk. Secure the transport at the very least.
I think that as soon as you have some kind of login handling you should protect the password of the user. You can do that either through https or by using http digest authentication.
My main point for encryption is that quite a lot of your users will have the same password to your site as they have to their bank account or something similar. Even though the information at your site is not sensitive, the passwords may indeed protect something important.
Yes, SSL/TLS is required to maintain a securely authenticated session. If you have a login, then the login's post and THE ENTIRE SESSION must be protected by https. It is easier and more secure to forward all traffic to https, even if you have a simple web application.
The problem is that a session id (cookie) can be leaked if you use http. If that session is authenticated then a hacker can use that session id to authenticate with the server without a username and password.
This is clear requirement of The OWASP top 10 A3: "Broken Authentication and Session Management"
http://www.owasp.org/images/0/0f/OWASP_T10_-_2010_rc1.pdf
Sending a cookie over http is also a violation of CWE-614 and CWE-311.
It is worth it at the very least if you transmit passwords and email addresses, or any other private or personally identifiable information. Session hijacking is possible if there's any non-HTTPS communication, but that's a risk many websites are willing to accept, and depends on your situation.
Performance issues depend on your hardware and your stack, but there will be "some" performance hit from HTTPS vs HTTP. It's not enough to stop you from protecting passwords and sensitive user information.
I've thought about this before as well. I would think you would want a secure connection when users are logging in or changing information.
For some people, passwords and age would be considered sensitive information, though. Are you prepared to deal with some people who may have a different view than you?
Is it acceptable to submit from an http form through https? It seems like it should be secure, but it allows for a man in the middle attack (here is a good discussion). There are sites like mint.com that allow you to sign-in from an http page but does an https post. In my site, the request is to have an http landing page but be able to login securely. Is it not worth the possible security risk and should I just make all users go to a secure page to login (or make the landing page secure)?
Posting a form from an http page to an https page does encrypt the data in the form when it is transmitted in the most simple terms. If there is a man-in-the-middle attack, the browser will warn you.
However, if the original http form was subjected to man-in-the-middle and the https post-back address was modified by the attacker, then you will get no warning. The data will still actually be encrypted, but the man-in-the-middle attacker would be able to decrypt (since he sent you the key in the first place) and read the data.
Also, if the form is sending things back through other means (scripted connections) there may be a possibility of unencrypted data being sent over the wire before the form is posted (although any good website would never do this with any kind of sensitive data).
Is there any reason not to use HTTPS for the entire transaction? If you can't find a very good one, use it!
It's arguably simpler than switching protocols.
The MITM risk is real.
Following your link, the user "Helios" makes an excellent point that using 100% HTTPS is far less confusing to the user.
This kind of thing is popping up all over the net, especially in sites for which login is optional. However, it's inherently unsafe, for quite subtle reasons, and gives the user a false sense of security. I think there was an article about this recently on codinghorror.com.
The danger is that while you sent your page with a post target of "https://xxx", the page in which that reference occurs is not secure, so it can be modified in transit by an attacker to point to any URL the attacker wishes. So if I visit your site, I must view the source to verify my credentials are being posted to a secure address, and that verification has relevance only for that particular submit. If I return tomorrow, I must view source again, since that particular delivery of the page may have been attacked and the post target subverted - if I don't verify every single time, by the time I know the post target was subverted, it's too late - I've already sent my credentials to the attacker's URL.
You should only provide a link to the login page; and the login page and everything thereafter should be HTTPS for as long as you are logged in. And, really, there is no reason not to; the burden of SSL is on the initial negotiation; the subsequent connections will use SSL session caching and the symmetric crypto used for the link data is actually extremely low overhead.
IE Blog explains: Critical Mistake #1: Non-HTTPS Login pages (even if submitting to a HTTPS page)
How does the user know that the form is being submitted via HTTPS? Most browsers have no such UI cue.
How could the user know that it was going to the right HTTPS page? If the login form was delivered via HTTP, there's no guarantee it hasn't been changed between the server and the client.
Jay and Kiwi are right about the MITM attack. However, its important to note that the attacker doesn't have to break the form and give some error message; the attacker can instead insert JavaScript to send the form data twice, once to him and once to you.
But, honestly, you have to ask, what's the chance of an attacker intercepting your login page and modifying it in flight? How's it compare to the risk of (a) doing a MITM attack strait on the SSL session, and hoping the user presses "OK" to continue; (b) doing the MITM on your initial redirect to SSL (e.g., from http://example.com to https://example.com) and redirecting to https://doma1n.com instead, which is under the attacker's control; (c) You having a XSS, XSRF, or SQL injection flaw somewhere on your site.
Yes, I'd suggest running the login form under SSL, there isn't any reason not to. But I wouldn't worry much if it weren't, there are probably much lower hanging fruit.
Update
The above answer is from 2008. Since then, a lot of additional threats have become apparent. E.g., access sites from random untrusted networks such as WiFi hotspots (where anyone nearby may be able to pull off that attack). Now I'd say yes, you definitely should encrypt your login page, and further your entire site. Further, there are now solutions to the initial redirect problem (HTTP Strict Transport Security). The Open Web Application Security Project makes several best practices guides available.
This post is the key one. Yes, if the user's data is sent to you, it will have arrived somewhere securely. But there is no reason to believe that somewhere will be your site. The attacker isn't just going to get to listen to the data moving in each direction at this point. He'll be the other end of the user's session. The your site is just going to think the user never bothered to submit the form.
For me (as an end-user), the value of an HTTPS session is not only that the data is encrypted, but that I have verification that the page I'm typing my super-secrets into has come from the place I want it to.
Having the form in a non-HTTPS session defeats that assurance.
(I know - this is just another way of saying that the form is subject to an MITM attack).
No, it's not secure to go from HTTP to HTTPS. The originating and resulting points of the request must be HTTPS for the secure channel to be established and utilized.
Everyone suggesting that you provide only a link to the login page seems to be forgetting that the link could easily be changed using a MITM attack.
One of the biggest things missed out in all of the above is that there is a general trend to place a login on a home page (Huge trend in User Experience Trends).
The big problem here is that Google does not like to search secure pages with good reason, so all those Devs who are wondering why not make it all secure, well if you want your page invisible to Google, secure it all. Else, the second best option to post from http to https is the lesser of two evils at this point?
I think the main consideration of this question has to do with the URL that users know and the protocol scheme (http:)that browsers substitute by default.
In that case, the normal behavior of a site that wants to ensure an encrypted channel is to have the http://home-page redirect to https://home-page. There is still a spoofing / MitM opportunity, but if it is by DNS poisoning, the risk is no higher than if one starts out with the https: URL. If a different domain name comes back, you need to worry then.
This is probably safe enough. After all, if you are subject to a targetted MitM, you might as well start worrying about keyboard loggers, your local HOSTS file, and all sorts of other ways of finding out about your secure transactions involving your system already being owned.