-
PHP Security Primer Part 2
Posted on March 28th, 2009 1 commentIt is important to note that the use of the magic quotes settings is often discouraged, and it definitely makes outputting the values more difficult (as you need
to call stripslashes() on all affected variables). In some situations, though, it can provide a level of fool proofing that is not normally achievable. It boils down to a choice between whether it is easier to escape (no magic quotes, just addslashes()) when needed, or unescape (magic quotes, stripslashes()) when needed.
Outputtting data
At this point, let’s assume that the data you received has been validated and decontaminated. But it isn’t that easy. Escaping input for safe SQL insertion is not the same as encoding input for safe output to the browser.
Let’s consider the following HTML snippet:
<html><body>
<textarea>
<?php echo $_POST[‘content’]; ?>
</textarea>
</body></html>
At first sight, it may seem like there is nothing wrong with this snippet. But imagine if somebody gives $POST[‘content’] a value like
<script language=”Javescript”>
document.location.href=http://www.example.com
</script>
If this content is simply inserted into the textarea as is, the page will automatically redirect to the given site. Most often in this situation the output ($_POST[‘con-
tent’]) should be encoded in such a way that the HTML is not evaluated. By using htmlspecialchars() or htmlentities() on the content, the HTML in the content
will appear in the textbox as HTML markup. So the corrected snippet looks something like this:
<html><body>
<textarea>
<?php echo htmlspecialchars($_POST[‘content’]); ?>
</textarea>
</body></html>
Don’t forget to check for magic quotes (using get_magic_quotes_gpc()), as you may need to run stripslashes() on the content as well. It is a good idea to use tmlspecialchars() on any output that you don’t want to be evaluated as HTML.
This may also include value parameters in form elements, for example:
<input type=”text” name=”email” value”<?php echo htmlspecialchars($email); ?> “>
Safe URLs
Often you want to produce dynamic hyperlinks on a page, and usually these links are composed of a path with GET parameters. Care must be taken when using arbitrary string data in these links. Suppose you create a link to another page like so:
<?php
echo “<ahref=\”otherscript.php?search={$_GET[‘search’]}\”>Search</a>”;
?>
If $_GET[‘search’] contains any binary data or characters such as &, +, ?, etc, we may run into problems where the link is not formed properly when the browser
follows it, etc. The urlencode() function encodes each unacceptable character in the GET request by using the appropriate hex character code prefixed by a
percent sign. So our script becomes:
<?php
echo “a href=\”otherscript.php?search=”. urlencode($_GET[‘search’]).”\”>Search</a>”;
?>
Again, be careful to note whether magic quotes are on, and take the appropriate action. The output of our script could be as follows (for a $_GET[‘search’] of “hello= world”):
<a href=”otherscript.php?search=hello%3D+world”>Search</a>
There is no need to worry about urldecodeding these values on the other side, by the way, as PHP will take care of that for us.
Shell commands
PHP’s ability to execute shell commands makes it that much more powerful, and dangerous. For example:
<?php
echo “Directory index of<b>” .
htmlspecialchars($_GET[‘dir’]) .”</b>\n”;
system(”ls {$_GET[‘dir’]}”);
?>
In this case it is of extreme importance that $_GET[‘dir’] be free of dangerous input. If, for instance, $_GET‘dir’ = “/ ; rm –rf *”, then we get the
following command:
ls / ; rm –rf *
This not only gives us the directory listing of the root, but everything in our current directory will be deleted. This can be prevented by using the escapeshellarg()
function. This special function binds the text from $dir into one argument by placing single quotes around it and escaping all of the single quotes.
<?php
echo “Directory index of <b>” .
htmlspecialchars($_GET[‘dir’]) . “</b>\n”;
$_GET[‘dir’]=escapeshellarg($_GET[‘dir’])
system(“ls {$_GET[‘dir’]}”);
?>
Instead of injecting shell commands, the above script now gives us the following command:
ls ‘/ ; rm – rf*’
Which will spit out an error, rather than wiping out a whole directory.
.htaccess files
We’ll now turn our attention to a little file that can save you a lot of headaches if you use it properly: .htaccess. This file serves many purposes—all directory based—
including HTTP authentication, access restriction, Apache error handling, and PHP configuration.
How can this help you with security? Access restriction
can help prevent unforeseen injection attacks on your configuration files. Some of the PHP configuration options that can be set on a per-directory basis can help protect you further against other types of attacks by automatically prepending authentication files to
your scripts or changing your session configurations.
A number of webhosting companies have some sort of control panel where you can easily configure .htaccess.
If your web host does not have a control panel like this, you should consult the Apache website at http://www.apache.org for more information on what you can do with .htaccess files, and how to use them.
Conslusion:
Hopefully this article has helped you become more aware of some of the common security challenges that as developers we have to deal with every day, and has
armed you with some practical techniques for dealing with them.
One response to “PHP Security Primer Part 2”
-
Child http://naviavbunx.ALLSTOCKSPORT.INFO/tag/Child+chair+desk/ : Child…
chair…
Leave a reply
-



Recent Comments