Will Your Web Applications Betray You?

K. K. Mookhey's tips for ferreting out vulnerable code

[And now for something completely different: This article begins our series of reports live from the BlackHat Briefings in Las Vegas. Leading security researchers have gathered to report their latest findings, and wherever those findings affect administrators of small-to-medium business (SMB) networks, we're sharing the latest thinking with you. If you prefer not to receive this special BlackHat coverage, visit our Broadcast Preferences page and turn off the Area of Interest labeled "Special Events." If you like this type of coverage, please let us know by e-mailing lsseditor@watchguard.com. You can also catch our short updates from the conference thoughout the day from our free RSS feed, WatchGuard Wire. —Scott Pinzon, Editor-in-Chief, LiveSecurity]

In 2001, Code Red and Nimda dramatically drew attention to Web server vulnerabilities by exploiting them automatically and en masse. Many security professionals feel that since then, administrators have gotten better at protecting their Web servers and vendors have patched many of the flaws in server software such as IIS and Apache. With servers themselves tightened down, hackers have moved on to attacking Web applications, often focusing intently on gaining access to your customer database servers. Seemingly every week, we read of another business that accidentally gave up thousands of customer records to hackers -- and in at least one case, millions of records. Common vectors of attack rely on the hacker visiting your public site and using your own insecurely-coded Web applications against you.

K. K. Mookhey has done a lot of thinking about how to secure Web applications. One of our favorite BlackHat speakers this year, Mookhey is Founder and CTO of information security consulting firm Network Intelligence. He has provided security consulting services to Fortune 500 companies and industry segment leaders in India, the Middle East, and North America. His team has found security vulnerabilities in products from Oracle, Symantec, Macromedia, and others. He contributes regularly to the Infocus series of articles on SecurityFocus. Here, he shares useful tips to help you determine how secure your Web apps are.

LiveSecurity: Many Small-to-Medium Business (SMB) administrators have heard of "SQL injection attacks" but don't fully understand what they are. Can you describe them for us?

K. K. Mookhey: A SQL injection attack is essentially the insertion of SQL metacharacters into a Web application with the aim to execute the attacker's choice of SQL query on the victim's backend database. So the idea is to use your Web-based front-end to compromise your backend SQL database.

LS: Another group of attacks referred to often is Cross-Site Scripting (XSS) attacks. What are those?

KKM: Cross-site scripting falls under the same category of attacks as SQL injection, specifically metacharacter insertion attacks, where the attacker tries to insert special characters that the Web application is not designed to handle. In the case of cross-site scripting attacks, the attacker inserts HTML characters which eventually results in JavaScript being executed on another user's browser. The key difference is that SQL injection attacks a server, whereas the cross-site scripting attack is against another user of the same Web site. It leverages the trust the user has in the Web site he thinks he is visiting.

LS: One might assume these types of targeted attacks only affect large companies. Do these attacks present any real world risk to small business networks?

KKM: Web application attacks will become common against Web sites of all sizes. The key criteria attackers use to choose targets are whether or not there's any financial data involved. If there's money, attackers will use all kinds of techniques to break in. Further, just as port scans happen to arbitrary IPs, attackers don't always pick a specific target. This may become the case for Web application attacks as well.

LS: Obviously, no company intends their customer-facing Web applications to contain security flaws. But the emphasis on secure coding only began recently. Is there any way to protect against Web application attacks short of hiring an HTML secure-coding expert?

KKM: The good news is that most of the Web application languages, like Perl, PHP, and ASP .NET, now have built-in input and output validation routines. A Web developer simply has to ensure that all user input is validated by these routines. These routines basically check for metacharacters, like those seen in SQL injection or cross-site scripting attacks, and clean them up.

LS: Popular programming languages, like C, also come with functions that do input validation or are more secure (e.g. strlcpy vs. strcpy). However, there seems to be a struggle to get programmers, who are not naturally security savvy, to use them. Is it the same in Web application development? Are the developers aware of these security routines?

KKM: It's a mix. For example, one client we worked with was doing basic input validation, but not enough to catch cross-site scripting attacks. Information is out there to help organizations to establish the procedures and processes necessary for secure coding, but it's not completely out there. One important step a company can take is to ensure their software developers subscribe to the "Secure Programming" and "Web Application Security" mailing-lists hosted by SecurityFocus.com.

LS: Are there tools to help you find Web applications flaws in your own Web code?

KKM: Most of the source-code auditing tools are geared towards finding flaws like buffer overflows, format strings, or race conditions. They generally don't detect the bugs we come across in Web applications.

LS: We've talked about what developers can do to improve the security of their code, but most of our readers are network administrators. Can the person who minds the Web server do anything to protect the network against Web application attacks?

KKM: There are tools available like mod_security, a security module for Apache, which he can install. For Windows, Microsoft has a free tool called ISS Lockdown that also includes URLscan. IIS Lockdown helps you configure your IIS server with a good security configuration, while URLscan sits in front of your IIS server and scans the input and output based upon rules you create. However, URLscan is not very flexible. SecureIIS from eEye might be a good option. An administrator should do a cost/benefit analysis to see if it's worth purchasing.

LS: One of the buzzwords in security right now is IDS (Intrusion Detection Systems), which usually recognize attacks based on signatures in the attack code. Could a generic signature be used to detect Web application attacks like cross-site scripting and SQL injection?

KKM: Cross-site scripting attacks are much easier to detect using a signature then SQL injection attacks. No matter how an attacker exploits a cross-site scripting flaw, he has to insert the HTML angle bracket < sooner or later. As soon as you see that input coming in, there's a very good chance it's malicious.

LS: Could a signature that detects HTML angle brackets produce false positives?

KKM: Yes. If you allow visitors of your Web page to compose an HTML e-mail or post to a newsgroup or blog in HTML format, the signature would detect HTML angle brackets.

LS: In your BlackHat briefing you discuss using signature-based IDS combined with anomaly detection to best detect Web application attacks. Can you elaborate on the strengths and weaknesses of signature-based IDS, of anomaly-based detection, and how they complement one another?

KKM: There are some attacks you just can't write a signature for. For instance, an attacker might try to brute force authentication or a session ID. We haven't been able to imagine a signature that can detect these types of attacks. One other type of attack where signatures fail is HTML hidden field input attacks. This is where certain key parameters are stored in the hidden field of an HTML page on the user's browser.

Another concern, of course, is that IDS relying on signatures sometimes generate false positives. For example with SQL attacks, if someone knows what signatures the IDS is scanning for, he can use attacks that try and evade them. However, we have also found that by the time the attacker tries to evade signature detection, he's already triggered a lot of the IDS system's alarms.

I think that anomaly-based detection makes up for many of the weaknesses of signature-based detection. For example, when an attacker tries to brute force a session ID, what's really happening is there are numerous requests with different session IDs in a short period of time, all coming from the same IP. This is very anomalous. Anomaly-based IDS systems would flag the traffic as radically different from normal traffic because typically you'd see traffic with the same session ID coming from one IP address.

LS: In your briefing you talk about how someone can use Snort to detect SQL attacks. Do you have any tips or tricks for our readers who don't use Snort?

KKM: One of the best techniques I've found, one I mentioned earlier, is using the mod_security module with Apache. Mod_security comes with a postscript that takes Snort rules and converts them into a format that mod_security understands. An administrator could just download the latest Snort ruleset, convert them using the postscript, and then use them with their Apache configuration using mod_security; that would be the easiest thing to do.

LSS: So if I'm a Microsoft shop, I'm just out of luck?

KKM: [laughing] No, you're not out of luck. But you will have to shell out some money to buy SecureIIS or some other commercial product since URLscan doesn't support regular expressions. I assume your question means you are using IIS as your Web server. However, if you use Apache in Windows, mod_security works just as well in that environment.

LSS: Many of our customers often hire outside vendors to develop their Web sites for them. For someone running Web applications they didn't create, any tips on how to assess them and assess the vendor that made them?

KKM: If you already have a Web application in place, the best bet might be to get a penetration test done on it. If it makes financial sense, go for a full source-code audit. Figure out the financial impact if your Web application is compromised, then determine: does the benefit of a pen-test or source-code audit outweigh that cost?

If a company hires outside developers to create their Web site, some of the key questions to ask them include: What are the secure coding practices you follow? What standards do you follow? See if they mention OWASP and if they are aware of the Top 10 Web application vulnerabilities published by OWASP. These are things you want to hear from the development team.

LSS: If I run a small business, what's the first thing I should do for my Web developers to start them along the path of secure Web coding?

KKM: All the developers should start with the OWASP Web site. They have a guide called "Guide to Building Secure Web Applications," with a new version coming out in a couple of months. They also have a list of the Top 10 Web vulnerabilities that all Web developers should be aware of. The "Secure Programming" and "Web Application Security" mailing-lists at SecurityFocus, that I mentioned earlier, are also very good resources for Web developers. Finally, get a black box audit done. Until someone tries to break your Web app, some flaws may never be discovered.