Exploiting Data Entry Fields

Anytime your application allows a user to submit data, you should worry. I know what you are thinking. "Duane, we validate all information the user types in our application to make sure it's not malicious. We don't need to worry about this... do we?" It's great that you check all input fields that users can type data into for malicious code. But what about fields they can't type into?

Most people only worry about data that is submitted to the server in a textbox. There are many places data is submitted back to the server, such as via a drop down list. It's easy for a hacker to change the values in the list on the client side, and submit to the server. You need to validate on the server side each and every field that has data the user could have manipulated on the client.

What do you do, once you find out someone has attempted to inject SQL code or other bad things into your input fields? The tendency in our industry is to be helpful. We try to clean up the input, so it's safe enough to put in the database or execute. However, this is a fundamentally flawed mentality.

If someone enters "SELECT * FROM tblCreditCard" as his username for the login of a site, you probably don't want to try to clean that up and then submit it to the database. If any fields are not what you expected, then don't allow the page to execute.

Each and every time your application gets input that was unexpected, it should be logged somewhere! I know what you are thinking: "I have tons of logs already that I don't get a chance to read. Why, oh why, would I want another?" Logs are the only way you can tell what's going on with your application. It's like buying stuff and not keeping the receipt. If, next month, you get a bill from a vendor charging you double what you were told the cost would be, you wouldn't have any proof because you didn't keep a log of the original charge.

Understand the Entire Attack Surface

Keep in mind that most hackers aren't trying just one way of getting into your site. They try hundreds or thousands. The ones who hack by hand (not using automated tools) systematically test each link in the security chain to see which is the weakest. In hacking sites, I've noticed that I usually get access through the systems or sites people didn't know were there or didn't care about. ("We don't really care what happens to that server. We're really concerned with our credit card processing server that sits next to it.") As a hacker, I just need one entry point, one way into your network — and from there, I will set up my base of operations and start moving inside your defenses.

For example, let's say we have a Web server with twenty different Web sites hosted on it; we're an ISP. Now does it seem weird, if we look at our logs and see a random IP address hitting one of those sites? The answer is usually No. We expect people to use the Web site, and we don't block access by IP address. Would it be odd for all the sites on that box to be hit by one IP address? Usually, the answer to this question is Yes. That would be weird, because the audience of each site is different; it would be highly unlikely for one person to hit them all. Could this be a hacker testing the electric fence, surveying the terrain to see where the weakest entry point is? Could be — yet most people don't think of looking for this type of anomaly.

One last point. Trying to track a hacker on the Internet is like trying to track the wild Yeti in Nepal (I'm not sure there are any tamed Yeti...). But in any case, if the Yeti left no tracks, was silent, and hid where you weren't looking or in a place you didn't know existed... would you find him? If hackers can poke and prod your application and potentially get access to sections of your code or data that you weren't expecting them to, will you know they are there?

Neo: "What? Are you trying to tell me that I can dodge bullets?"

Morpheus: "No Neo, I'm trying to tell you that when you're ready, you won't have to."

I could tell you about all the latest exploits and exactly what to look for today to fix your specific application and make sure it's secure. We would talk about buffer-overflows, SQL injection, Cross-Site Script hacking, the list goes on and on. We would be essentially attempting to dodge the bullets; trying to worry about each and every little incoming attack.

Once you are ready, once you start thinking about your applications and the environment in a holistic manner, and once you control your applications to react the way you want them to or log the activity when they don't, then you will be able to protect against attacks that haven't even been dreamt up yet. I'm not saying your application will be 100% secure, just that your application will always be under your control. You will always be aware of what's going on and what your threats are. That is the true nature of security. It's all about control. You want to be in control. Logs, coupled with a strong understanding of how you may be attacked, is a huge step in the right direction.