News Stay informed about the latest enterprise technology news and product updates.

One simple rule to make your Web apps more secure

If there's one thing developers should do to increase Web applications security, it's input validation, according to Caleb Sima, founder and CTO of SPI Dynamics. In this interview, he discusses the most dangerous threats to Web applications, such as SQL injection and cross-site scripting, and how input validation can make Web sites 80% more secure.

Do developers need to be specially trained to create secure code or can they pick up a book such as yours and figure things out?

It would be nice if they were trained to write secure code, but do they absolutely have to be a secure coder to do things properly? Not necessarily. Having knowledge of security vulnerabilities and issues helps your code to be more secure and makes you a better developer, but certain strict rules and policies, and certain very static rules such as validate your input, can help you write secure code without having knowledge of security.

The book itself doesn't teach anything about secure coding. The only thing the book teaches is examples and techniques of how hackers break into Web applications. If a developer reads it, it will hopefully open their eyes to see exactly what kinds of things a hacker can do with mistakes that they make, and allow them to realize that security holes aren't just bugs—they're not simple little bugs that they can fix later. These are big problems that they have to deal with in their code.

What threat do you consider the most dangerous to Web applications and why?
SQL injection. It is a high-severity problem in the fact that a SQL injection allows a hacker to connect to the back-end database in that Web application and do anything that hacker wants in terms of extracting data. It is by far, in my opinion, the most dangerous Web application vulnerability and still one of the most common.

SQL injection requires no third-party intervention like cross-site scripting (XSS) does; all it requires is a hacker finding a hole and exploiting it, and you get access to all the data right there. Finding a cross-site scripting exploit in a Web site allows you to affect a lot of people, but the fact still remains that the user has to view that link or view the cross-site scripting exploit or at least click on it. It still requires third-party intervention, and even if that third-party intervention is there, it still requires the hacker to obtain usable information from that third party.

We'll give you an online dating Web site example. In terms of a SQL injection problem, what a hacker can get access to is the back-end database of this site. That database will contain profiles, user information, passwords to accounts and credit card data. Not only does the SQL injection vulnerability give them [access to this], but it probably also gives them the ability to control that back-end database to get access to the internal network of the company that runs the online dating Web site.

SQL injection is by far the most dangerous Web application vulnerability and still one of the most common.
Caleb Sima
CTOS.P.I. Dynamics

Say this online dating Web site has cross-site scripting. And say I infect every user of that system with my cross-site scripting exploit. Now what do I do with it? Well, I can try to capture the keystrokes in their Web browser and capture any data they have for the instance of their Web browser being open and hope they enter things like credit card numbers. I could also do something like make them click on banner ads that might make them pay me money in terms of clicks, but here's the thing: I don't get it immediately, and it's not guaranteed I'll get everybody, and it's not guaranteed that I'll get other types of information. So you can see where the severity breaks down. SQL injection by far is much more dangerous and much more critical.

Why is cross-site scripting getting so much attention?
The main reason is because of Ajax and Web 2.0 social community Web sites. Ajax allows JavaScript to do all sorts of cool things. If you pair that with cross-site scripting, which is really just the ability to run JavaScript in a user's browser, that gives cross-site scripting a much more powerful ability. Now I can run, in a sense, actual programs in a user's browser.

Now let's add Web 2.0 social networking. In order for cross-site scripting to have any impact or to make any danger or damage to a user, that user has to view the exploit or click on the exploit. Now that social networking is a big deal, everybody wants to view everybody else's stuff. Now I have a venue that's very popular for people to view things that other people have written. I have a nice attack avenue for my cross-site scripting. So all three of those together [Ajax, cross-site scripting and Web 2.0] makes cross-site scripting the new hot thing today.

You talk about new SQL injection techniques in your book. Can you hit upon one that is very dangerous?
One is blind SQL injection. The reason why this more dangerous than normal SQL injection is that fact that the educated security community knows about SQL injection, and they know that database error messages on Web pages are bad. So they remove those error messages, and they trap the errors in order to make sure these database error messages—which indicate SQL injection—don't get shown to the common user. This is good to a certain extent in the fact that there is no longer this database error message that is shown to users. What is bad is the fact that they don't fix the problem; they just remove what appears to be the effect of the problem. People are doing this en masse—they are removing the database error message but not fixing the core issue. So blind SQL injection is still a SQL injection, but does it without an error message, which makes it much more difficult to identify. Is there one thing a company should absolutely do to help make their applications secure?
I tell this to everybody. Not only will this one method or one rule protect you against SQL injection, but it will protect you against cross-site scripting, buffer overflows, all sorts of security issues. It's a very simple solution, and it's called input validation. Input validation, in my belief, is the only thing that security people need to be telling their developers to do right now. If they do that properly, it will eliminate most security problems in their Web applications. Once that has been done, then figure out how to teach/educate your developers on security.

[In] companies today, usually their developers' time is spent on functionality and getting things out the door. They are very time-constrained, and in order to make developers learn about security, it takes a lot of time, a lot of education and a lot of looking over the developers' shoulders to see that they do the things correctly. That can take years to do properly. And even if you do that, there is going to be a certain percentage of developers who pick it up and apply it and a certain percentage who just don't care. And in most organizations, that percentage of people who care and apply it are probably 5%, while 95% just goes about and does what it does.

So if you want to write secure Web applications and you want to do it quickly and efficiently, give them one simple rule to apply. Don't worry about anything else; just do the one thing. Once they do that well and they take that step, you have successfully made your Web application 80% more secure, guaranteed. I'm not saying ignore those vulnerabilities in your code. You have to fix them, but if you do input validation first, that at least gives you the time to go through and fix the others. There's been a significant increase in the number of Web application attacks over the last year. Are there really more attacks or are companies more willing to report them now?
It's definitely a true rise. Guaranteed, Web applications are the way to go. All hackers are focusing on it because that's the only thing left. There's no point in doing network-level attacks, there's no point in finding zero-day vulnerabilities in software, in mail service or a Web server. Web applications are where it's at—that's where all the vulnerabilities are.

Free book excerpt
Download a Chapter 6: Input Validation Attacks from Caleb Sima's book, Hacking Exposed Web Applications, Second Edition.

Should hackers contact a company first if they find a vulnerability and give them a chance to fix it before posting it in a public forum? Should they even be testing the sites without the company's permission?
I'm kind of split on the matter. There's a side of me that says that's unethical, you shouldn't be testing for these vulnerabilities because you don't have that site's permission, or you should at least alert them to the fact first before posting it. But a second side of me also says the Web application and the Web site are public and there for everybody to see, and the fact is people are using this for exploiting people and a lot of these companies are ignoring it. If they [hackers] want to take it upon themselves to go and find this issue and post it, and to let people know that this is a problem, then more power to them. It does nothing but educate market to this kind of problem, and the fact is it's serious.


Caleb Sima is a well-known expert in emerging security threats and penetration testing. He is the founder and CTO of Atlanta-based S.P.I. Dynamics Inc., a Web application security testing software and services company. He is also a co-author of the recently published book Hacking Exposed Web Applications, Second Edition.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.