A negative security model (or misuse based detection) is based on a set of rules that detect attacks rather than allow only valid traffic. The Core Rule Set discussed in this document is a negative security model rule set.
It is important to note that the differentiation between negative and positive security models is subjective and reflects how tight the security envelope around the application is. A good example would be limiting the characters allowed in an input. Since the character set is a closed set, providing a white list of permitted characters is actually similar to providing a black list of forbidden characters including the characters complementing the 1st group.
A negative security model is very common to Intrusion Detection and Prevention systems (IDPS). Therefore it is very important to understand what the differences are between the negative security model provided by an IDPS and the negative security model provided by a WAF.
Robust HTTP and HTML parsing
A WAF employs an HTTP and HTML parser to analyze the input stream. The parser should be able to understand specific protocol features including content encoding such as chunked encoding or multipart/form-data encoding, request and response compression and even XML payload.
In addition the parser must be as flexible as the environment protected as many headers and protocol elements are not used according to RFC [[i],[ii]] requirements. For example, while the RFC requires a single space between the method and the URI in the HTTP request line, Apache allows any sequence of whitespace between them. Another example is PHP unique use of parameters: in PHP leading and trailing spaces are removed from parameter names.
In a proxy deployment a stricter parsing may be acceptable, but if the WAF is deployed in any way in which only a copy of the data inspected, the WAF has to be at least as flexible as the web server in order to prevent evasion. IDPS systems that fail to do so can be easily evaded by attackers.
Protocol Analysis
Based on the parsed info, a WAF must break up the HTTP stream into logical entities that can be inspected, such as headers, parameters and uploaded files. Each element will be inspected separately not just for its content, but also for its length and count.
In addition a WAF must correctly divide the network stream when keep-alive HTTP connections are used to unique request and replies, and correctly match requests and replies.
In proxy deployment, a WAF or IDPS failing to match correct request and response data may be attacked using HTTP response splitting [[iii]] attacks or HTTP request smuggling attacks [[iv]]. In a passive out of line mode, the WAF or IDPS may be easily circumvented.
Anti Evasion features
Modern protocols such as HTTP and HTML allow the same information to be presented in multiple ways. As a result signature based detection of attacks must inspect the attack vector in any form it may be in. Attackers evade detection systems by using a less common presentation of the attack vector. Some common evasion techniques include using different character encodings for the attack vector or using none canonized path names. In order to prevent evasion a WAF would transform the request to some normalized form before inspection.
While modern IDPS systems may support anti-evasion techniques, those are limited to well defined parts of the request such as the URI. A WAF can selectively employ normalization functions for different input fields for each inspection performed. For example, while an IDPS would normalize the URI, a WAF can normalize an HTML form field that accepts path names as input.
Rules Instead of Signatures
As the tests employed by a WAF are more complex, it cannot rely solely on signatures and requires a more robust rules language to define the tests. For example, the following features exist in ModSecurity rules language [[v]]:
- Operators and logical expressions - a WAF can check an input field for attributed other than its content, such as its size or character distribution. Additionally a WAF can combine such atoms to create more complex conditions using logical operators. For example, a WAF may inspect if a field length is too long only for a specific value of another field, or alternatively check if two different fields are empty.
- Selectable anti-evasion transformation functions - as discussed above, each rule can employ specific transformation function.
- Variables, sessions & state management - since the protocols inspected keep state, the rules language needs to include variables. Such variable can persist for a single transaction, for the life of a session, or globally. Using such variables enables the WAF to aggregate information and therefore detect an attack based on multiple indications during the life span of transaction or a session. Attacks that require such mechanisms to detect are brute force attacks and application layer denial of service attacks.
- Control structures - a WAF rules language may include control structures such as conditional execution. Such structures enable the WAF to perform different rules based on transaction content. For example, if the transaction payload is XML, an entirely different set of rules may be used.
[i]. RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1, 1999 http://www.w3.org/Protocols/rfc2616/rfc2616.html
[ii]. RFC By Category, Hypertext Transfer Protocol
http://www.faqs.org/rfcs/np.html#HTTP
[iii]. "Divide and Conquer", HTTP Response Splitting, Web Cache, Poisoning Attacks, and Related Topics,
Amit Klein, Director of Security and Research, Sanctum, Inc. , March, 2004
http:// www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf
[iv]. HTTP Request Smuggling, Chaim Linhart, Amit Klein, Ronen Heled And Steve Orrin, A Whitepaper From Watchfire
http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf
[v]. ModSecurity Reference Manual, Version 2.1.0 / (February 23, 2007)
http://www.modsecurity.org/documentation/modsecurity-apache/2.1.0/modsec...