• One of two fundamental security rules: (1) filter and validate all input; (2) escape output
• Always escape outside data unless previously filtered
• Typical output formats that require escaping when containing user data: html, json, sql
• Never rely on client side (javascript) filtering
• Functions used to escape data before outputting within html: htmlspecialchars() htmlentities() strip_tags()
• Input is everything that comes as part of the http request
• Some data does not seem to be input, but may contain data originating from the user, thus must be considered as input (ex: session data that was originally supplied by the user)
Character Set
• Risk
attack vectors may employ a non-standard char set (ex: utf-8 encoded) that may be missed by filtering, but executed by the browser
• counter
Use the same char set for filtering as the target procedure
convert charsets prior to filtering content-type: text/html; charset=”utf-8″
use php’s filter extension
use filters native to the database (ex: db quoting functions)
escapeshellcmd() escapes any characters in a string that might be used to trick a shell command into executing arbitrary commands. This function should be used to make sure that any data coming from user input is escaped before this data is passed to the exec() or system() functions, or to the backtick operator.
Following characters are preceded by a backslash: &#;`|*?~<>^()[]{}$\, \x0A and \xFF. ‘ and ” are escaped only if they are not paired. In Windows, all these characters plus % and ! are replaced by a space instead.
<?php $command = './configure '.$_POST['configure_options']; $escaped_command = escapeshellcmd($command); system($escaped_command); ?>
Escape a string to be used as a shell argument
Code injection can occur when using dynamic data in calls to system() and related
Counter Measures
• Limit or remove use of system(), exec(), eval(),back tick(‘), and shell_exec()
• escapeshellarg() to escape arguments
• escapeshellcmd() to escape commands
The PHP option allow_url_include normally allows a programmer to include() a remote file (as PHP code) using a URL rather than a local file path. For security reasons, this feature should be disabled. If a script claims to require this feature, you should look into alternative software, as the use of this feature indicates serious design flaws.
There are a number of reasons why URL includes should always be avoided:
It’s insecure – if your application can be tricked into including content from a URL outside itself (and there are a number of common ways this can happen), an attacker can force your application to start running code from their own web site.
It’s inefficient – if your PHP script includes content from a URL, then the web server must make HTTP requests to generate the page. This makes your page load much slower than necessary, especially if the site you’re loading content from is responding slowly.
It’s unreliable, for the same reasons – if the web server you are loading content from occasionally fails to respond, your web site also sometimes fails to load properly.
It’s usually unnecessary – in most cases, allow_url_include can be avoided either by including the content directly (if it is being loaded from a domain you host) or by loading and printing the content without evaluating it as PHP.
Remote code injections attempt to run the attacker’s code on a server, often by exploiting the functionality of the include or require functions.
The eval(), exec(), system(), and shell_exec() functions are vulnerable to remote code injections.
Include / Require attacks occur when including and executing files (possible from remote servers and includes remote code execution)
Counter Measures
• Check data against a whitelist
• Remove paths using basename()
• Set allow_url_include = off in php.ini that helps somewhat but not sufficient, as some attack vectors remain open
The mysqli_real_escape_string() function escapes special characters in a string for use in an SQL statement
• A request generated from a user’s browser without the user’s knowledge
• Relies on web site trust of logged-in users
• An attack involves tricking a user into transmitting ‘bad’ html with a request, which then returns sensitive data to the attacker
• Executed via iframes, xmlhttprequest calls or embedded in tags such as <script>, <object>, <embed>, <img>, …
Example
<form name="myForm"> <input type="hidden" name="item_id" value="123" /> <input type="hidden" name="quantity" value="1" /> </form> <script>document.forms['myForm'].submit();</script>
Counter Measures
• Use a unique form token in a hidden input field to verify the request
• Require re-login before sensitive operations (ex: financial)
Counter Measures
• Regenerate the session id upon login, before authentication, using session_regenerate_id(true). passing boolean true removes the old session and is critical as a counter measure
• Also, regenerate session id prior to “critical” operations
• Use ssl encryption for the login, or assign a hidden key (not as good)
• Check that the ip address remains the same (although not always reliable)
• Use short session timeout
• Provide user logout
• Destroy an old and create a new session with: session_regenerate_id(true)
• Set php configuration directive session.use_only_cookies = 1
• Prevent javascript access to session cookie with php configuration directive session.cookie_httponly = 1