In-Depth

Q&A: Protecting Web Applications from Unknown Attacks

Companies must protect their data as well as their reputations.

• By Mathew Schwartz
• 12/10/2003

Accordingly, smart companies have security to protect against Web application attacks. Those that don’t, says Stiennon, “are placing their databases and confidential customer information at risk.” In some industries, these companies also expose themselves “to liabilities from recently enacted privacy legislations such as the Health Insurance Portability and Accountability Act and the Gramm-Leach-Bliley Act.”

One option for guarding against Web site attacks is a Web application network appliance, which restricts data to a single path in and out of the organization. An organization can then scrutinize all data to see if sensitive information is leaving or if someone is trying to rewrite cookies or Web forms with embedded SQL (a so-called “SQL injection attack”) to cause a buffer overflow in the database. If successful, such an attack could knock the Web application offline or give an attacker full access.

To discuss the state of Web application security applications, Security Strategies spoke with Greg Smith, senior director of product marketing for secure application gateway maker Teros.

What’s the fear from an application-level attack? What could an attacker do?

It’s that a hacker gets access to an application, they find a vulnerability in that application, and attack and exploit a weakness in the application. [They] get to the database beyond it and issue commands to the database that would spill all its information—or deface its Web site. And when you read about these attacks, that's typically what happens.

Why use a secure application gateway per se?

Why companies do this is to prevent against identity theft—protecting personal information which, if compromised, would result in the theft of a person’s identity. So we’re protecting social security numbers, credit card numbers, information that's been communicated to a company by an individual … We lock it down. Of course many of the exploits you do read about by hackers, they’re exploits of well-known vulnerabilities.

You mentioned guarding against known vulnerabilities; what about unknown ones?

I want to protect that entire infrastructure, of course, against attacks both known and unknown. And it's the unknown ones that are particularly damaging, because by definition, when they hit on day zero, other security appliances—intrusion detection systems, firewalls—are unable to detect those because they haven't been able to distribute a signature that would detect those attacks.

You’re seeing more intrusion prevention now at the network level. Does that extend to protect Web applications?

What is different about protecting an online application than a network is hackers will typically devise an attack that can be launched en masse against a number of networks, and they will actually try to discern specific weaknesses in a particular company’s infrastructure. Those are custom attacks, which are almost impossible to identify using standard pattern-matching techniques.

What’s the alternative to pattern matching?

Well, our appliance is able to learn the behavior of that application in dynamic environments. We learn what is typical, then we supply security recommendations to the security administrator that he can click and apply, so you can secure [in-use] database records or personally identifying information. This is information you want to collect, but you don't want to see it going outbound. We also make sure that security does not degrade the performance of the application or network, because people want security but they don't want to take a hit in performance.

How does the appliance work?

The Secure Application Gateway sits in front of the Web server, or a cluster of Web servers, and all Web traffic that's headed toward the Web server goes through our box. We analyze it in both directions using deep-packet inspection and full application awareness for HTTP and HTTPS—or SSL-encrypted Web traffic.

What’s the appliance looking for, besides bad application behavior?

There are 16 classes of Web vulnerabilities that Web applications are potentially vulnerable to. These are discrete vulnerabilities; they’re listed on our Web site. It's a good checklist for customers as to what they need to protect, and to use to evaluate products.

Regardless of the type of attack, we have out-of-the-box protection, and we enforce correct application behavior. For example, we know that if a client issues a cookie for an application, when that client returns the cookie, it should be returned unmodified, because perhaps that cookie contains information about a user, [such as] a user number. So it should be untouched. Or Web forms—we make sure they’re unmodified. That will protect the application from divulging or spilling information it shouldn't.

Does an IDS protect against that kind of behavior now?

IDSs operate at the network level. However, … what they’re not designed to do is protect the application, because they don't understand the application language—it just looks at packets.

So how do you recognize when someone is trying to inject bad SQL into the site, before the application then starts acting funny?

What we can detect is SQL syntax anywhere in a Web request coming from a client, and typically these types of attacks are trying to exploit weaknesses in an application, and trying to corrupt the database, or more typically, get the database to leak information. So [catching that] is another way to prevent against identity theft.

How do you ensure sensitive information doesn’t flow out of the company?

I'll tell you what we're not doing. We're not just blocking all 16-character strings; we feed it all through an algorithm first to see what it is. This is particularly useful and valued by customers in e-commerce and finance, for obvious reasons. We're also going to extend this functionality to firm-specific numbers, such as patient IDs, customer numbers, invoices, etc.

Any tips for preventing hackers from learning about your infrastructure, then exploiting known weaknesses?

Hackers usually undertake some kind of reconnaissance, and one of the first steps is to find out exactly what they're targeting. We're actually able to provide cloaking of that information, to disguise a lot of the infrastructure or URL specifics, that would allow a hacker to say, "Oh they're running Linux, or they're running Apache."

Does that extend to preventing people from rewriting the URLs they’re using to interact with a server?

Yes, we … allow content designers to put any information they want into the URL, but before it goes out, we can translate it into something much cleaner, and without sensitive, identifying information. So, for example, as [the URL] hits our gateway, rather than seeing this 300-character URL, instead you might get http://www.checking.mybank/george. In other words, something that's very clean and doesn't reveal any information, but it’s [good] because … it’s [also] associated with the brand.

Is this sort of functionality new?

Companies did it before today, but they had to do it with dedicated proxy servers, with Microsoft, or with Netscape Proxies.

So this puts URL renaming under the security rubric?

Exactly.