Web Security is a major issues with web developers. Somethings apply more than others. For instance, in previous entries, we looked at the way global variables can affect PHP scripts as well as closing the PHP remote file execution loophole. Today I want to shift gears a bit and look at a much more common security point. It affects more than just users who write PHP scripts. In fact, it affects anyone who may try to connect to any remote server in any situation using the FTP protocol.
FTP is often misinterpreted as a program. FTP is not a program. There are many applications that utilize FTP and provide the user with an interface to FTP but it is a protocol and not an application. A protocol is an agreed upon method of transmitting data between two systems. Similarly, HTTP is a protocol that transfers data between a web server and your browser. POP3 is used as a protocol for transmitting email from a mail server to your email client. FTP is a protocol used to transfer files, in this case web files and images from your computer or development server to another computer, in this case the web server.
Now that we’ve established the tech jargon, you are probably wondering why FTP is bad. Well, I wrote about it a long time ago, but to go back over it, let me explain.
In the networking world, we have what is called the OSI model, or the Open Systems Interconnection. This model summarizes the entire process of data transmission. In the foruth and fifth layers (Session and Transport), we have our issue. In order for data to be sent back and forth, a “handshake” must be initiated between systems to confirm the ability to send data over the wire. Once the “handshake” has been completed, we have a “Session”. This “handshake” usually is comprised like a normal conversation:
<phone rings>
Joe: Good Morning. This is ABC Enterprises, Joe Black speaking, how may I help you?Bill: Hi, my name is Bill Burke. I am from XYZ Corporation. I was wondering if I could talk to you for a moment?
Joe: Oh, hi Bill. Yeah, what’s on your mind?
There was an authentication that took place in that conversation. Joe identifies himself as being from ABC Enterprises and Bill provides his own identifcation. Once identities have been established and acknowledged, these two gentlemen carry on with their business.
Likewise, in any network transmission, authentication must be established. Where most people go wrong is assuming that FTP is secure because a username and password have been provided. While this username is required to give a user access to system resources on the remote box, it must go through layer 4 (Transport) first. It is here where we have a problem. Picture this scenario:
<phone rings>
Joe: (on speaker phone) Good Morning. This is ABC Enterprises, Joe Black speaking, how may I help you?Bill: Hi, my name is Bill Burke. I am from XYZ Corporation. I was wondering if I could talk to you for a moment?
Joe: Oh, hi Bill. Yeah, what’s on your mind?
In this scenario, Bill does not realize his conversation is on speaker phone. He believes he is speaking to Joe, and he is! But anyone within earshot of his conversation can hear it. Therefore, it is impossible to carry on a secure conversation.
With FTP, the transport layer broadcasts the session via plaintext for anyone with the proper free network monitoring tools (which can be used remotely) to pick up. You might not be so concerned until it becomes clear that the username and password is also transported via plaintext over FTP!!
The solution for this is pretty simple. Another protocol that is often used is SSH. SSH is immeasurably easy between Linux boxes but is infinitely more difficult to use (interchangeably at least) with Windows system tools. However, utilizing that protocol, it is easy to secure an SFTP connection on top of SSH. In other words, the same functionality of FTP can be achieved with SFTP over top of the SSH protocol. With SSH, the session data in the transport layer is encrypted using a variety of different methods of your choice and even with eavesdropping tools, are very difficul to crack.
I realize that this series is quite technical. But to break it down to the lowest common denominator just follow these rules.
- Do not host your website with a host that does not allow you shell access. If all they provide for is FTP, move along.
- If they do allow SSH, often times you need to request it, a process that should be minor and normal.
- Use an FTP client that allows connections over Port 22 or SSH2.
You’ll find yourself infinitely more secure and in the long run, your website will thank you.
Stumble it!
About the Author: Aaron Brazell is the lead editor of Technosailor.com and a social media expert. His passion is to see companies and individuals use the internet and web technologies wisely and effectively to promote their brands and companies. He served as Director of Technology at b5media from 2005-2008 and is currently an independent consultant.
