In my previous article I wrote about getting your webserver set up so you can use encrypted SSL/TLS (Secure Sockets Layer/Transport Layer Security) connections. In this article you'll learn how to use of encrypted connections so you don't negate all the time, effort and probably money that went into setting them up. Some mistakes stem from a lack of understanding about the basic fundamentals of SSL/TLS. Other, less obvious mistakes are often overlooked simply because the developer made reasonable, yet inaccurate assumptions. Starting with the most basic mistakes, we'll go through some of the most common SSL problems, explain why they happen and how to avoid them.
The Basics
When people are first starting out with SSL they often don't have any understanding of the basics of how it works, but some abstract notion of the page being protected by encryption throughout its entire lifespan:
being created, transmitted to a browser, used by a user and, in the case of something like a form, transmitting sensitive data back
to the server. They make the assumption that everything is safe because the page has been encrypted, but it actually isn't. The classic mistake people make when they
try to secure things like login forms is to serve the login form page from a secured https address, then have
the actual login data posted back to the server over a standard http address. Using SSL in this way doesn't provide encryption protection over its entire lifespan. The page and any other data such as the contents of a form are only protected
while being transmitted in either direction between the browser and the server. Once a page has finished downloading it's
no longer protected by SSL. In this situation, the login data which should be protected is transmitted unencrypted, and the form which doesn't
need any protection is downloaded over a securely encrypted connection. Developers new to SSL and
the users of their forms are lured into a false sense of security because they see that the address of the page containing
the form begins with https. At this time of writing, there are at least two browsers that I know of which perpetuate
this illusion of protection by not issuing any kind of warning about this misuse of SSL. Microsoft's Internet
Explorer (version 7 tested) and Google's Chrome are both quite happy to let their users send data over unencrypted connections even
though it should be obvious that the data is supposed to be protected. In contrast, Konqueror, Firefox and Opera, all make it
clear to their users that such a form is in no way secure and should not be trusted.
It's worth noting that, despite the fact that there's no need for the page containing the login form to
be served over an encrypted connection, it's not a good idea to actually serve it over an unencrypted connection. This isn't for any technical reason; but when an average user sees that the address of the page containing the form doesn't begin with https they naturally assume that it's not secure and will often lose trust and leave. This is one of those times where the reality is the opposite of the perception.
SSL Does Not Mean Secure Storage
Protecting Sessions
Protecting session data (and therefore all data that a user has entrusted to a site) is probably the area that the largest
number of systems fail to get right. It isn't just small time self-employed developers that get it wrong. A large number of
multi-nationals make their use of SSL utterly pointless by failing to properly protect sessions. Of the sites that render
their SSL useless, most of them do it in one of two ways, but both leave the same type of security hole. The
first method is to have the entire login process done safely and securely over encrypted connections.
They keep the user's login details such as passwords and any other identifying data nice and safe; but as soon as all of this
nice, safe and secure logging in is finished, the user is dumped back onto a standard http connection and is
immediately vulnerable to anything they might have been protected against during the login process.
Users are vulnerable on standard http connections because of the way that sessions work. After a user logs in to a
site they are given a session cookie. A session cookie is a tiny text file
containing a reasonably long sequence of random characters. Whenever a browser downloads a page from a site that gave it a
session cookie it will also send the contents of the session cookie back to the site along with the request for the Web page. The Web site uses the contents of the session cookie to uniquely identify each user and provide them with appropriate
controls and content. If someone else can read the contents of the session cookie when the browser sends it to the Web site, they can write the same session cookie on their own computer and use it to identify themselves to the Web site as the person they
copied the cookie from. This means that having someone's session cookie is as good as having someone's login details, and all an
attacker has to do is—if they can't take a victim's login details—simply wait a few seconds longer to grab the
victim's session cookie after they've logged in. As you can see, a secure login followed by non-secure browsing does
nothing to prevent an attacker from gaining access to a user's account.
The solution is obvious. Use encrypted connections for the entire session and the user is safe, right? Wrong. This is the mistake that even the big boys make. Many retail, banking and sensitive data storage sites offer encrypted connections for the entire session, but still fail to adequately protect a user's session cookie from being taken. The reason for this failure is because the session cookie needs to be marked as secure. If a cookie is marked as secure, the browser won't send the cookie over a unsecured connection; but if the cookie isn't designated as secure the browser can be tricked into sending it over unprotected connections which can be read by a third party. This type of security hole is less easy to exploit than the session's connections simply not being encrypted after the login, but, as the Cookie Monster toolkit recently demonstrated, it's still very much an exploitable hole.
Summary
SSL is a powerful tool for protecting not only your user's data, but also their confidence in you. It's the first thing a user will look for when deciding whether or not to trust a site, but it doesn't cover all the security issues. It's just one aspect of a greater effort. SSL protects data during one specific period of time, but that time isn't the only window of opportunity that an attacker has to strike. Care must be taken to ensure that when you employ SSL you don't render it redundant by neglecting to examine your systems for weaknesses in other key areas. It should never be assumed that a system is secure. A system should be proven to be secure by pro-actively seeking out weaknesses and eliminating them.
Original: October 3, 2008
Find a programming school near you