Here are some solutions:
- Ensure the user level of the Web server or Web application is given the least amount of read permissions possible for files outside of the Web document root. This also applies to scripting engines or modules necessary to interpret dynamic pages for the Web application.
- Normalize all path references before applying security checks.
When the Web server decodes path and file names, it should parse each encoding scheme it encounters before applying security checks on the supplied data and submitting the value to the file access function.
In many cases, the path and file name can be safely reduced to a subset of 7-bit ASCII characters even though the operating systems supports extended encodings. Be aware of systems that (incorrectly) reduce Unicode characters to ASCII equivalents, such as Windows' interpretation of U+2216 (intended as a mathematical operator) as a slash character.
- When possible, refer to absolute path names for files, directories and commands using constants in the source code of the Web application. This prevents variables from being exposed to the user and altered or overwritten by user input.
- If file names will be passed in URL parameters, then restrict all user-accessible files to a single directory that does not include dynamic script files. Use a global constant to set this base path.
Prefix the base path to all file requests in order to prevent attacks from accessing files outside the Web document root. This is more restrictive than setting the base path to the Web document root and will prevent attackers from viewing the source code of dynamic scripts.
- If file names will be passed in URL parameters, then use a hard- coded file extension constant to limit access to specific file types. Append this constant to all file names. Also, make sure to remove all NULL-character (%00) sequences in order to prevent attacks that bypass this type of check. (Some interpreted scripting languages permit NULL characters within a string even though the underlying operating system truncates strings at the first NULL character.) This prevents directory traversal attacks within the Web document root that attempt to view dynamic script files.
- Validate all input so that only the expected character set is accepted (such as alphanumeric). The validation routine should be especially aware of shell meta-characters such as path-related characters (/ and \\) and command concatenation characters (& for Windows shells and semi-colon for Unix shells). Set a hard limit for the length of a user-supplied value. Note that this step should be applied to every parameter passed between the client and server, not just the parameters expected to be modified by the user through text boxes or similar input fields.
- Depending on your environment consider using a chroot jail for the Web server directories. This will virtually remove all upper-level file-system access even if the Web server or Web application is found to be vulnerable.
This was first published in August 2006