[VipVince]

Today I am going to discuss and give several examples to how unsecured code can lead to exploitation.

Lets begin.
A very small and simple, yet vulnerable file.


All looks OK, no input forms so no xss right? Think again...

PHP Code:

<form method="post" action="<?php echo $_SERVER["PHP_SELF"];?>">

The part to note is:

PHP Code:

action="<?php echo $_SERVER["PHP_SELF"];?>">

In PHP the action attribute dictates where the form data is sent. For instance if it was:

PHP Code:

<form method="post" action="test.php">

Then the form data is processed by the test.php file.

Now, if a user enters the normal URL in the address bar like "http://www.example.com/test.php", the above code will be translated to:

PHP Code:

<form method="post" action="test.php">.

Leaving the action like:
action="<?php echo $_SERVER["PHP_SELF"];?>

Really it just says to submit the form on the page it is currently on.

How can this be dangerous? Well consider the below form:

PHP Code:

<form method="post" action="<?php echo $_SERVER["PHP_SELF"];?>">

It can be exploited with the below vector..

http://localhost/scripts/vulnfile.php/"><script>alert(/xss/)</script>

This is translated to:

PHP Code:

<form method="post" action="vulnfile.php"/><script>alert('hacked')</script>

We used "> to close the tags, and then executed our payload.

More examples on non filtered forms and input data.

As you can the $xss variable gathers our data from the form, unfortunately it is not wrapped with a security function which makes the XSS possible.



How to prevent this?

Rather simple. Use the custom htmlentities() function. This will turn known dangerous characters into their html entities form. For instance, a safe script would be:

PHP Code:

<?php $xss = htmlentities(($_POST["search"])); echo "You searched for: $xss"; ?>

The results of that script is very different:

You searched for: &lt;script&gt;alert(1)&lt;/script&gt;

Local file disclosure.

The below script allows a user to search for a file on the system, with the $_GET['file'] parameter. However, it does not perform any security checks to limit the file to a certain extension or byte size.



This can be abused like so:

SQL Injection.

Vulnerable code:

This code is vulnerable as nothing is being escaped.


Here was a quick solution to the problem.

PHP Code:

$id = mysql_real_escape_string($_GET['id']);

Above we sanitized the $id variable. Any data passing through it will be escaped. This is how it looks in action.

PHP Code:

"SELECT * FROM persons WHERE ID='{$id}'" ;

However I should stress that the mysql extension is now deprecated. Therefore should not be used. Ideally you should use PDO and bind and prepare your statements before interacting with the database. This is an effective way of preventing SQL injection. Here is an example of how I used PDO to secure my registration script.



Exploiting PHP magic-methods.

Shout out to Crysan for this code. It is vulnerable to something known as object injection.


We can inject the $_COOKIE super global and take advantage of the __wakeup() magic method.

Basically what we can do is insert our own values to the key as its public, this can lead to code execution. We are also assigning another instance of the class and changing the values inside it.



Running that gives us:

PHP Code:

O%3A7%3A%22license%22%3A1%3A%7Bs%3A1%3A%22v%22%3Ba%3A2%3A%7Bs%3A3%3A%22key%22%3Bs%3A25%3A%22NO_KEY%22%3B%2Bphpinfo%28%29%3B%2B%24b%3D%221%22%3Bs%3A4%3A%22pass%22%3Bs%3A8%3A%22h0lycr4p%22%3B%7D%7D

This is our serialized payload, injecting that in the cookie parameter like so will spawn the phpinfo(); file.

PHP Code:

Cookie:h0lycr4p=O%3A7%3A%22license%22%3A1%3A%7Bs%3A1%3A%22v%22%3Ba%3A2%3A%7Bs%3A3%3A%22key%22%3Bs%3A25%3A%22NO_KEY%22%3B%2Bphpinfo%28%29%3B%2B%24b%3D%221%22%3Bs%3A4%3A%22pass%22%3Bs%3A8%3A%22h0lycr4p%22%3B%7D%7D

The rest is up to your imagination. My advice is not to use these magic methods in your scripts.

Local File Inclusion.

Again some simple but yet vulnerable code:


What this code does is allows us to locally include files via the $_GET['page'] parameter, in lay mans terms it works like this.. vulnscript.php?page=(we can call files here).

It is poorly coded, and appends a .php extension. When I try to call file.php it fails, this is because it would look like file.php.php. However in this case, vulnscript.php?page=file is enough as it automatically appends the extension for us. I had a file on the server called phpinfo.php which contained our phpinfo() information for the server.



There is several ways to prevent this. Notable open_basedir, you can edit it to match your needs in your php.ini. In short it will prevent a script in one directory from 'mingling' with a script in a separate directory. This limits the chances of directory traversal and including files from other directory's on the file system. Other tips, do not use include() statements, and if you want a messy way you can use preg_match to filter known dangerous key words. Something like:

PHP Code:

<?php $goodfiles = array( 'index.php', 'page.php', 'safe.php'); $page = $_GET['page']; if (in_array($page, $goodfiles)) { //everything is good continue } else { die("hacking attempt"); } ?>

I wouldn't particularly recommend this way though.

Other functions to be careful of if implementing them in your scripts:

PHP Code:

exec(); system(); eval();

That is all for now, I kept this as basic as possible and appreciate to some of you this will be old news, however I am sure a majority of you will have learned something from this.

An investment in knowledge pays the best interest.

Until next time. VV.

[RogueCoder]

Good informative post. What I think is missing though is more defensive methods. An explanation for everything on different methods for how to prevent the attacks.

[VipVince]

Thank you for the feed back.