Related
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 :-)
When faced by an untrusted certificate, every single browser I know displays a blaring error like this:
Why is that?
This strongly discourages web developers to use an awesome technology like SSL out of fears that users will find the website extremely shady. Ilegitimate (ie: phishing) sites do fine on HTTP, so that can't be a concern.
Why do they make it look like such a big deal? Isn't having SSL even if untrusted better than not having it at all?
It looks like I am being misunderstood. I am taking issue with the fact that HTTP sites cannot be more secure than an HTTPS site, even if untrusted. HTTP doesn't do encryption or identification. Phishers can make their sites on HTTP and no warnings are shown. In good faith, I am at the very least encrypting traffic. How can that be a bad thing?
They do that because a SSL certificate isn't just meant to secure the communication over the wire. It is also a means to identify the source of the content that is being secured (secured content coming from a man in the middle attack via a fake cert isn't very helpful).
Unless you have a third party validate that you are who you say you are, there's no good reason to trust that your information (which is being sent over SSL) is any more secure than if you weren't using SSL in the first place.
SSL provides for secure communication between client and server by allowing mutual authentication, the use of digital signatures for integrity, and encryption for privacy.
(apache ssl docs)
Yep, I don't see anything about third party certificate authorities that all browsers should recognize as "legit." Of course, that's just the way the world is, so if you don't want people to see a scary page, you've got to get a cert signed by someone the browsers will recognize.
or
If you're just using SSL for a small group of individuals or for in-house stuff, you can have people install your root cert in their browser as a trusted cert. This would work fairly well on a lan, where a network admin could install it across the entire network.
It may sound awkward to suggest sending your cert to people to install, but if you think about it, what do you trust more: a cert that came with your browser because that authority paid their dues, or a cert sent to you personally by your server admin / account manager / inside contact?
Just for shits and giggles I thought I'd include the text displayed by the "Help me understand" link in the screenshot in the OP...
When you connect to a secure website, the server hosting that site presents your browser with something called a "certificate" to verify its identity. This certificate contains identity information, such as the address of the website, which is verified by a third party that your computer trusts. By checking that the address in the certificate matches the address of the website, it is possible to verify that you are securely communicating with the website you intended, and not a third party (such as an attacker on your network).
For a domain mismatch (for example trying to go to a subdomain on a non-wildcard cert), this paragraph follows:
In this case, the address listed in the certificate does not match the address of the website your browser tried to go to. One possible reason for this is that your communications are being intercepted by an attacker who is presenting a certificate for a different website, which would cause a mismatch. Another possible reason is that the server is set up to return the same certificate for multiple websites, including the one you are attempting to visit, even though that certificate is not valid for all of those websites. Chromium can say for sure that you reached , but cannot verify that that is the same site as foo.admin.example.com which you intended to reach. If you proceed, Chromium will not check for any further name mismatches. In general, it is best not to proceed past this point.
If the cert isn't signed by a trusted authority, these paragraphs follow instead:
In this case, the certificate has not been verified by a third party that your computer trusts. Anyone can create a certificate claiming to be whatever website they choose, which is why it must be verified by a trusted third party. Without that verification, the identity information in the certificate is meaningless. It is therefore not possible to verify that you are communicating with admin.example.com instead of an attacker who generated his own certificate claiming to be admin.example.com. You should not proceed past this point.
If, however, you work in an organization that generates its own certificates, and you are trying to connect to an internal website of that organization using such a certificate, you may be able to solve this problem securely. You can import your organization's root certificate as a "root certificate", and then certificates issued or verified by your organization will be trusted and you will not see this error next time you try to connect to an internal website. Contact your organization's help staff for assistance in adding a new root certificate to your computer.
Those last paragraphs make a pretty good answer to this question I think. ;)
The whole point of SSL is that you can verify that the site is who it says it is. If the certificate cannot be trusted, then it's highly likely that the site is not who it says it is.
An encrypted connection is really just a side-benefit in that respect (that is, you can encrypt the connection without the use of certificates).
People assume that https connections are secure, good enough for their credit card details and important passwords. A man-in-the-middle can intercept the SSL connection to your bank or paypal and provide you with their own self-signed or different certificate instead of the bank's real certificate. It's important to warn people loudly if such an attack might be taking place.
If an attacker uses a false certificate for the bank's domain, and gets it signed by some dodgy CA that does not check things properly, he may be able to intercept SSL traffic to your bank and you will be none the wiser, just a little poorer. Without the popup warning, there's no need for a dodgy CA, and internet banking and e-commerce would be totally unsafe.
Why is that?
Because most people don't read. They don't what what https means. A big error is MANDATORY to make people read it.
This strongly discourages web developers to use an awesome technology like SSL out of fears that users will find the website extremely shady.
No it doesn't. Do you have any evidence for that? That claim is ridiculous.
This strongly encourages developers and users to know whom they are dealing with.
"fears that users will find the website extremely shady"
What does this even mean? Do you mean "fears that lack of a certificate means that users will find the website extremely shady"?
That's not a "fear": that's the goal.
The goal is that "lack of a certificate means that users will find the website extremely shady" That's the purpose.
Judging from your comments, I can see that you're confused between what you think people are saying and what they are really saying.
Why do they make it look like such a big deal? Isn't having SSL even if untrusted better than not having it at all?
But why do they have to show the error? Sure, an "untrusted" cert can't be guaranteed to be more secure than no SSL, but it can't be less secure.
If you are solely interested in an encrypted connection, yes this is true. But SSL is designed for an additional goal: identification. Thus, certificates.
I am not talking about certs that don't match the domain (yes, that is pretty bad). I am talking about certs signed by authorities not in the browser's trusted CA's (eg: self-signed)
How can you trust the certificate if it is not trusted by anyone you trust?
Edit
The need to prevent man-in-the-middle attacks arises because you are trying to establish a privileged connection.
What you need to understand is that with plain HTTP, there is absolutely no promise of security, and anyone can read the contents passed over the connection. Therefore, you don't pass any sensitive information. There is no need for a warning because you are not transferring sensitive information.
When you use HTTPS, the browser assumes you will be transferring sensitive information, otherwise you would be using plain HTTP. Therefore, it makes a big fuss when it cannot verify the server's identity.
Why is that?
Because if there's a site that's pretending to be a legit site, you really want to know about it as a user!
Look, a secure connection to the attacker is no damn good at all, and every man and his dog can make a self-signed certificate. There's no inherent trust in a self-signed cert from anyone, except for the trust roots you've got installed in your browser. The default set of trust roots is picked (carefully!) by the browser maker with the aim that only CAs who only act in a way to secure trust will be trusted by the system, and this mostly works. You can add your own trust roots too, and if you're using a private CA for testing then you should.
This strongly discourages web developers to use an awesome technology like SSL out of fears that users will find the website extremely shady. Ilegitimate (ie: phishing) sites do fine on HTTP, so that can't be a concern.
What?! You can get a legit certificate for very little. You can set up your own trust root for free (plus some work). Anyone developing and moaning about this issue is just being lazy and/or over-cheap and I've no sympathy for such attitudes.
Ideally a browser would look for information that you want kept secure (such as things that look like credit card numbers) and throw that sort of warning up if there was an attempt to send that data over an insecure or improperly-secured channel. Alas, it's hard to know from just inspection whether data is private or not; just as there's no such thing as an EVIL bit, there's also no PRIVATE bit. (Maybe a pervasive metadata system could do it… Yeah, right. Forget it.) So they just do the best they can and flag up situations where it is extremely likely that there's a problem.
Why do they make it look like such a big deal? Isn't having SSL even if untrusted better than not having it at all?
What threat model are you dealing with?
Browser makers have focused on the case where anyone can synthesize an SSL certificate (because that's indeed the case) and DNS hacks are all too common; what the combination of these means is that you can't know that the IP address you've got for a host name corresponds to the legitimate owner of that domain, and anyone can claim to own that domain. Ah, but you instead trust a CA to at least check that they're issuing the certificate to the right person and that in turn is enough (plus a few other things) to make it possible to work out whether you're talking to the legitimate owner of the domain; it provides a basis for all the rest of the trust involved in a secure conversation. Hopefully the bank will have used other unblockable communications (e.g., a letter sent by post) to tell people to check that the identity of the site is right (EV certs help a little here) but that's still a bit of a band-aid given how unsuspicious some users are.
The problems with this come from CAs who don't apply proper checks (frankly, they ought to be kicked off the gravy train for failing their duty) and users who'll tell anyone anything. You can't stop them from deliberately posting their own CC# on a public message board run by some shady characters from Smolensk[1], no matter how stupid an idea that is…
[1] Not that there's anything wrong with that city. The point would be the same if you substituted with Tallahassee, Ballarat, Lagos, Chonqing, Bogota, Salerno, Durban, Mumbai, … There are scum all over.
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.
Quite simply, what is the criteria a website must meet for it to need SSL certificate?
Website is not ecommerce but will take user information, contact details and event information.
Even if not technically required does SSL just provide users with added 'trust' in the site?
Cheers
Use SSL when you are collecting sensitive information from your users, which (IMO) includes contact details. Personally I try and avoid submitting personal details about myself over an unencrypted channel.
In the end it's a judgement call. However, if you're collecting addresses, phone numbers, bank details, or anything that can be physically traced back to the user I'd recommend using SSL.
Obviously this only applies if your transport method is insecure (which the Internet, by definition, is). If you're running your website over an already-secure channel (like an internal network, where you trust your users, then there's not much point).
However, if you do decide to use SSL, make sure you get a valid, signed certificate! SSL without a signed certificate is kind of pointless, since it means your end users cannot trust the authenticity of the certificate. This unfortunately costs money, which is why many small websites don't bother.
SSL is all about trust - the certificates are signed by a "trusted" authority, so users can be sure that they are dealing with the proper certificate holders (as opposed to someone performing a man-in-the-middle attack). Obviously this trust is not ultimate - but it's an added step to providing a safe data channel for user information.
I would want to use SSL for any area of any website where personal information is being transmitted e.g. Login, Registration, Account Settings, Contact Details, User Information.
Take a look at the data being shown and ask yourself if you would want to leave that information posted around about you without any protection - go from there.
Whenever you cannot trust the wire - Whenever there is a chance of somebody snooping in to whatever is being sent over the wire (network hub, MITM vulnerability etc.) and whatever is being sent on the wire may contain stuff which at least a small subsection of your customer base will not like anyone to have access to.
Interestingly, SSL combines two components of security, they are:
Encryption
Identification
Encryption
Typically people use SSL because it encrypts the sending of data to the server. This is important if you are taking passwords, but critically important if you are taking credit card information. For this purpose, generally people have SSL for only that page. This isn't perfect, because the non-secure page you land at may have been spoofed, hence your already at the wrong site, so it doesn't really matter if it's encrypted.
Which brings us to ...
Identification
The identification component of SSL is also interesting. PayPal, for example, like their certificates because it is supposed to "prove" that PayPal bought it. Sadly, users don't care or notice this, despite some improvements in browser UI's.
Rarely is it necessary, or worthwhile, to get a certificate for identification (of the server), and IMHO, the two components of SSL should be separated (but that's another story :p). But some may argue that it is useful. I'm not one of those people.
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.