Блог xcedz

xcedz

source code audit PHP
Filed under: (in)secure — code, how to, research — custom | Tags: $http_get_vars, $http_post_vars, $_cookie, $_GET, $_post, $_request, $_server, $_session, audit, exec, header location, include, include_once, passthru, proc_open, readfile, require, require_once, shell_exec, source code, system, virtual |

What source code audit is?
It’s a primary technique by which someone can find vulnerabilities of the website, just by inspecting the code.

Consider the following scenarios:
find a ftp service exploit and you can download the entire website in it’s unparsed form
have the source of the web application used by the website

What has to be done?
Instead of emulating the real website (setting up a webserver, database, etc) you can just start and analyze the code for common known vulnerable code.

User input
Most of the time user input is passed to the web application via requests, like:
—
$_GET
$_POST
$_REQUEST
$HTTP_POST_VARS
$HTTP_GET_VARS
—
And if register globals in php.ini are activated, user input can be retrieved via <input> names, for example the following html form:
—
<form name=”basic” method=”post” action=”">
<input type=”text” name=”myname”>
<input type=”text” name=”age”>
<input type=”submit” value=”age & name”<
</form>
—
…would create and set the following variables:
—
$myname=”user input”;
$age=”user input”
—
This request should be always searched for input validation, or xss/sql injection possibility.

Internal inclusion
As imagined I’m talking about file inclusion which could lead to lfi/rfi; the php functions that need to be exploited for a lfi/rfi attack are:
—
include()
include_once()
require()
require_once()
virtual()
readfile()
—
Not much to check here, only the parameters origins, validation…

Indirect User Input
Indirect user input? That sounds wierd, but don’t get confused about it; I’m speaking about user-agent information, http referer, cookie reading/writing/printing, session?. The all together could lead to xss/sql injection/http response splitting and why not (remote) code execution/file inclusion. Things to look for:
—
$_SERVER["REFERER"];
$_SERVER["HTTP_USER_AGENT"]
$_SERVER["REQUEST_URI"]
$_COOKIE
$_SESSION
—
Also here a non used Referer would mean CSRF ways of exploitation, keep that in mind; might come handy!

Redirections
Maybe you are not aware of this but after each header redirection there should be a script termination like exit() die(), so the following code would be vulnerable:
—
if($password!=$pass) { header(“Location: noadmin.php”); }
—
Because if the page would be requested via a telnet connection (for example) which wouldn’t understand header information, would skip the redirection phase and see the rest of the page.

Remote code execution
We already mentioned about remote code execution, but it would be better to also note the functions which should be look upon for code execution:
—
exec()
passthru()
proc_open()
shell_exec()
system()
—

The rest, the ugly, the not so common
Besides of the above mentioned vulnerabilities, which are more common, you could also check image upload scripts for proper type/extension validation, and every other shit that I can’t think of….

Go and analyze source code
I pointed out everything that you need to know before auditing PHP code, but if you think I missed something out, don’t bother thinking about it, just drop me a comment…
(http://insanesecurity.wordpress.com)

xcedz