Apache Security - Ivan Ristic [199]
document.cookie
onFocus
onUnload
document.write
onKeyDown
style[[:space:]]*=
dynsrc
onKeyPress
vbscript:
Command execution and file disclosure
Detecting command execution and file disclosure attacks in the input data can be difficult. The commands are often very short and can appear as normal words in many request parameters. The recommended course of action is to implement a set of patterns to detect but not reject requests. Table 12-7 shows patterns that can be of use. (I have combined many patterns into one to save space.) The patterns in the table are too broad and should never be used to reject requests automatically.
Table 12-7. Command execution and file disclosure detection patterns
Pattern
Description
(uname|id|ls|cat|rm|kill|mail)
Common Unix commands
(/home/|/var/|/boot/|/etc/|/bin/|/usr/|/tmp/)
Fragments of common Unix system path
../
Directory backreference commonly used as part of file disclosure attacks
Command execution and file disclosure attacks are often easier to detect in the output. On my system, the first line of /etc/passwd contains "root:x:0:0:root:/root:/bin/bash," and this is the file any attacker is likely to examine. A pattern such as root:x:0:0:root is likely to work here. Similarly, the output of the id command looks like this:
uid=506(ivanr) gid=506(ivanr) groups=506(ivanr)
A pattern such as uid=[[:digit:]]+\([[:alnum:]]+\) gid=\[[:digit:]]\([[:alnum:]]+\) will catch its use by looking at the output.
Advanced Topics
I conclude this chapter with a few advanced topics. These topics are regularly the subject of email messages I get about mod_security on the users' mailing list.
Complex configuration scenarios
The mod_security configuration data can be placed into any Apache context. This means you can configure it in the main server, virtual hosts, directories, locations, and file matches. It can even work in the .htaccess files context. Whenever a subcontext is created, it automatically inherits the configuration and all the rules from the parent context. Suppose you have the following:
SecFilterSelective ARG_p KEYWORD
SecFilterSelective ARG_q KEYWORD
Requests for the parent configuration will have only parameter p tested, while the requests that fall in the /moresecure/ location will have p and q tested (in that order). This makes it easy to add more protection. If you need less protection, you can choose not to inherit any of the rules from the parent context. You do this with the SecFilterInheritance directive. For example, suppose you have:
SecFilterSelective ARG_p KEYWORD
SecFilterInheritance Off
SecFilterSelective ARG_q KEYWORD
Requests for the parent configuration will have only parameter p tested, while the requests that fall in the /moresecure/ location will have only parameter q tested. The SecFilterInheritance directive affects only rule inheritance. The rest of the configuration is still inherited, but you can use the configuration directives to change configuration at will.
Byte-range restriction
Byte-range restriction is a special type of protection that aims to reduce the possibility of a full range of bytes in the request parameters. Such protection can be effective against buffer overflow attacks against vulnerable binaries. The built-in protection, if used, will validate that every variable used in a rule conforms to the range specified with the SecFilterForceByteRange directive. Applications built for an English-speaking audience will probably use a part of the ASCII set. Restricting all bytes to have values from 32 to 126 will not prevent normal functionality:
SecFilterForceByteRange 32 126
However, many applications do need to allow 0x0a and 0x0d bytes (line feed and carriage return, respectfully) because these characters are used in free-form fields (ones with a