Difference between revisions of "Unsafe string replacement"
(→Defense) |
(→Overview) |
||
Line 3: | Line 3: | ||
__FORCETOC__ | __FORCETOC__ | ||
=Overview= | =Overview= | ||
− | Unsafe use of string replacement functions to sanitize user input is extremely common. Because string | + | Unsafe use of string replacement functions to sanitize user input is extremely common. Because string replacement ([http://php.net/manual/en/function.str-replace.php str_replace] in PHP) functions only do a single replacement, it is necessary to loop over them until all unsafe characters or strings are removed if you are replacing more than a single character. This also applies to replacements powered by regular expressions. |
=Example= | =Example= |
Revision as of 14:19, 6 May 2012
This is a programming language agnostic vulnerability, effecting any application which incorrectly uses string replacement to sanitize data. |
Contents
Overview
Unsafe use of string replacement functions to sanitize user input is extremely common. Because string replacement (str_replace in PHP) functions only do a single replacement, it is necessary to loop over them until all unsafe characters or strings are removed if you are replacing more than a single character. This also applies to replacements powered by regular expressions.
Example
A trivial example:
<?php $filepath = $_GET['file']; $safe_filepath = str_replace('../', '', $filepath); echo("Safe filepath is '" . $safe_filepath . "'<br />"); include($safe_filepath); ?> |
First an attacker may try a simple directory transversal attack, using '../' to escape. The result:
Safe filepath is 'etc/passwd'
No dice, the dangerous string ('../') is dutifully sanitized by str_replace. But, our attacker isn't going to give up yet, now armed with the knowledge that '../' is being filtered out, he may try:
test.php?file=....//....//....//....//....//....//....//....//....//....//....//....//....//etc/passwd
The result:
Safe filepath is '../../../../../../../../../../../etc/passwd' [contents of /etc/passwd]
Even if '../' is replaced twice, it can be easily bypassed by using ......///. No matter how many times the replacement is made, the attacker simply needs to nest another layer.
Other examples of unsafe uses of string replacement include:
str_replace('<?', '', $source); |
Bypassed by '<<??'
str_replace(array('<script', '<img'), '', $source); |
Bypassed by '<<imgscript>'
str_replace('file://', '', $source); |
Bypassed by 'file:/file:///'
Defense
If one must use str_replace for sensitization, it must be done using a loop or called recursively:
- Loop
function safe_str_replace($search, $replace, $subject) { while(strstr($subject, $search) !== FALSE) { $subject = str_replace($search, $replace, $subject); } return $subject; } |
- Recursion
function safe_str_replace($search, $replace, $subject) { if (strstr($subject, $search) !== FALSE) { return safe_str_replace($search,$replace,str_replace($search, $replace, $subject)); } return $subject; } |
However, the use of whitelists with 'positive' regex matching (i.e. does the input match /[a-z]+/) is more effective.
<center>