Forum Moderators: phranque
The way I understand it, the point of securing a site with SSL is that you do not want to send sensitive information across the Internet in plain text, you do not want to send such information across the internet in plain text because bad guys can sniff the traffic between you and the web server and perform a “man in the middle” type of attack once they have your login credentials. This much I understand, it is the same in regards to command line access, Telnet is insecure and SSH is not as insecure because with SSH, the information you type is encrypted before it ever leaves you. With both SSL and SSH, your login information is encrypted before it travels across the Internet and if that encrypted information was sniffed by someone in the middle, for the most part it is useless to them.
In regard to securing a web application, at the least you want to secure the login mechanism with SSL. You do not want the user’s credentials getting sent across the Internet in plain text. Once the user is logged in, if you are not doing something crazy and stupid like storing their login information in a cookie, they will receive some kind of identifying token that they send each time they make a subsequent request to the web server (session identifier). How long this token is valid for, and whether the token is valid at all, are functions for the web application on the server to decipher. As I understand it, this is how most web applications function. Hypothetically speaking, unless this application was secured with SSL once they were logged in, someone “in the middle” could hijack a user’s session by sniffing out the token and then submitting it along with their request to the web application and then they are “in” so to speak. This is why I have always secured any web application I build behind a login with SSL.
However I have noticed lately that the trend with many larger web applications (google’s gmail, yahoo, flickr.com, and myspace.com) all now do not implement SSL once you are logged in, the login form where you are asked for a username and password will be secured with SSL, but once you are logged in, you are no longer using SSL. Your identifying token, however it works in each case, must be being sent in plain text, meaning that all these applications have made themselves vulnerable to the kind of session hijacking attacks I mentioned a moment ago, or at least it seems this way.
I am assuming the reason that we see this trend in these large applications is because, in regards to resources, it can be expensive for the web server to encrypt every page in a web application, and when you have millions of users as you do in these cases, it makes sense why one would want to do things in this way. However, it begs the question, what is preventing the possibility of a “man in the middle” type of attack on these systems.
Most the web applications I have built have been small enough that I can afford to take the hit on the server to encrypt all web based applications that rest behind a login, So I have never given this problem much thought, however, now, I am looking at building an application that has the potential to be large enough that I am concerned about the potential drag on the system that encrypting the user sessions would pose.
So what I am ultimately asking is how is it that these applications are secured when not using SSL, and if the answer is simply that they are not, then why have such large profile sites knowingly decided to ignore this aspect of keeping their applications secure? Looking forward to hearing your comments.
Even when your "man in the middle" is able to grab the cookie, it is still not useable because the IP address and/or browser ID he uses is different.
This approach works in general, but may give problems when the visitor is behind a proxy which accesses the server with multiple IP addresses (like AOL) or which blanks / alters the browser identification string.
