Application Security
By Abhishek Chauhan

Application security is one of the biggest challenges facing IT organizations today. Statistics show that 80 percent of malicious attacks target Port 80, which allows HTML and XML traffic to bypass firewalls. As a result, robust application security is necessary to ensure application availability, protect sensitive customer and corporate data, maintain business continuity, and protect application-enabled revenue. However, there is growing confusion about what constitutes application security and how it is achieved. The following article compares application communication to a human conversation, and illustrates how application security requires devices that can inspect and understand the language, meaning, context and identity of interactions between a web browser and server.

Application Conversations
To understand application security, it is first necessary to grasp how applications communicate. Most communications consist of a client (e.g., a web browser) making a request to an application (e.g., a web server). After the web server receives the request, it processes the request and returns a response to the browser.

In many respects, application communications are analogous to a conversation between two people. Indeed, there are many parallels between human conversations and electronic conversations employed by applications:
> Both require a common language (including vocabulary and sentence structure).
> Both utilize two-way communication (speaking and listening).
> Both expect answers (responses) to questions asked (requests).
> Both expect answers (responses) to be given in a timely manner.
> Both expect communications to be in the proper context. In other words, an answer (response) should make sense given the question asked (request).

All applications communicate via electronic conversations. Any device promising to deliver application security must be capable of understanding all conversations between the application and its users.

In addition, it must be able to distinguish one conversation from another and listen to both sides of each conversation. It is an absolute requirement to understand an application’s conversation if one is to protect the application from attack or misuse. Application security requires a complete understanding of all conversational elements.

Deep Packet Inspection
Deep packet inspection firewalls are an evolution of traditional network firewalls used to protect corporate networks from Internet threats. They capture and inspect individual IP packets to provide granular access control to network resources. In addition, with an enhanced ability to deeply inspect and analyze the information within packets they attempt to detect attacks aimed at applications.

Does deep inspection of IP packets enable an understanding of application conversations? To answer that question, it is helpful to determine what role IP packets play in an electronic conversation. IP packets are discrete pieces of information.

In this sense, they are analogous to individual words. By themselves, neither IP packets nor single words embody much meaning. It is only when words are assembled into sentences are they are able to convey meaning and support a coherent conversation. If a firewall can assemble a stream of packets into its original order, it can now form complete sentences.

So what can a deep inspection firewall do now that it has captured a complete sentence? Primarily, it can be programmed to look for certain words that may appear in the sentence. For example, it can identify an obscenity appearing in a sentence (assuming that it is spelled correctly). It does this by scanning every word to find a match against a pre-programmed list of impermissible words. If it is particularly intelligent, it may even focus its search in specific areas of the sentence.

So how does this word matching ability improve application security? Well, if those words for which it is programmed to detect are really signatures of known application attacks, the firewall can forcibly end the conversation. This is effective when there are known attacks that can be identified by simply detecting a particular word (signature) in the sentence that has been reconstructed by the firewall.

But is this really providing application security? What about all of the other varieties of application attacks and exploits which cannot be detected by the presence of a single word? True application security comes from understanding the complete conversation of an application. Only then can a security device begin to prevent the plethora of attacks threatening business-critical applications.

The limits of network firewalls
1. How would a network firewall stop a malicious user who is asking the application to perform an illegal operation? What if an attacker asked the application to tell him the credit card numbers of all corporate customers? This is known as a command injection. Because there may be innumerable forms to this question, the network firewall would be unable to find a single word revealing malicious intent.

2. What if an application asks a user to submit his phone number, but the user returns his address instead? This is known as form field manipulation. Because the network firewall was not even aware of the original request, it cannot verify whether or not the user’s reply is consistent with what the application is expecting.

3. Would a network firewall detect a user asking a question that the application should not answer? For example, what if a hacker submitted a specially crafted URL in a request that would access a part of the application that should be off-limits? This is known as a forceful browsing. The network firewall cannot grasp the bounds of the conversation and does not know what questions should be answered.

4. Consider an application that gave each user a secret word and instructed them to use it each time they wanted to converse with the application. What if an attacker sent someone else’s secret word in an attempt to impersonate that person? This is known as a cookie tampering. The network firewall does not follow conversations and, therefore, cannot track when secret words are exchanged.

A deep inspection firewall does not understand an application’s conversations. Its role is comparable to listening to a conversation in a foreign language and trying to detect the presence of specific words. It does not comprehend the conversation. It does not even understand the meaning of the word it is trying to detect. Applying these simple word-matching techniques, without the ability to understand even the rudimentary elements of a conversation, fails to deliver true application security. So, what is the right approach?

Application Security Gateways
Application security gateways go far beyond network firewalls with regard to comprehending electronic conversations. First, they perform the basic operations of a network firewall: capturing individual words (IP packets) and forming complete sentences (stream normalization).

But unlike network firewalls, they understand the language in which the conversation is conducted (e.g., HTML for web applications and XML for web services). Full knowledge of the language enables the application security gateway to parse each sentence the same way a person would. For example, it can determine which words are nouns and verbs, and can enforce proper grammar.

The ability to deconstruct conversations based on an understanding of the language, along with the ability to listen to both sides of the conversation, enables an application security gateway to fully protect the application.

The Intelligence of Application Security Gateways
Application security gateways understand the appropriateness of a request. For example, what if Bob asked an application about Project X, when the application never mentioned Project X to Bob? This is another example of forceful browsing. Because the application security gateway is monitoring both sides of the conversations, it is aware that the application never referred to Project X and would, therefore, block Bob’s request?

Application security gateways can block words outside of the expected vocabulary. For example, what if a hacker attempted to dupe an application by asking the application to pass along a foreign word (or nonsensical word) to another party? This can be accomplished using a SQL injection attack or buffer overflow exploit. The application security gateway would automatically detect that an illegal word was introduced into the conversation, and would terminate that part of the conversation, thus protecting the application.

Application security gateways can monitor multiple conversations. For example, consider what would happen if an application asked Bob for his account number during an established conversation. And then a hacker answered on behalf of Bob with the response, “Hi my name is Bob and my account number is 12345.” The hacker is trying to steal the conversation and impersonate Bob. This is known a session hijacking. An application security gateway maintains separation between conversations (maintains user sessions) and prevents one party from impersonating another.

Application security gateways can remove superfluous comments. Consider an application that answers a user’s question and includes information that is both unnecessary and revealing. For example, the application may comment on how it was designed and how certain inputs are handled. Hackers might find these comments useful in crafting new attacks. Application security gateways can keep conversation content to a minimum and prevent the leakage of sensitive information. This is known as an HTML comment stripping.

Summary
All applications communicate via electronic conversations. The only viable means of securing the application is to monitor and enforce legal conversations between the application and its users. Unlike network firewalls, application security gateways provide complete comprehension of all conversational elements. As such, they provide the only solution for application protection.

About the Author
Abhishek Chauhan is chief technology officer and co-founder of Teros. Prior to Teros, Chauhan helped architect the design of scalable network services and distributed programs at Sun Microsystems.

<< Previous Page