Has anyone else noticed now much Julian Assange (founder of wiki leaks) looks like Max Zorin – founder of the evil Zorin Empire and former KGB agent?

Julian Assange (left) Max Zorin (Right)
Has anyone else noticed now much Julian Assange (founder of wiki leaks) looks like Max Zorin – founder of the evil Zorin Empire and former KGB agent?

Julian Assange (left) Max Zorin (Right)
Its a misconception amongst some PHP programmers that because MongoDB doesn’t use SQL (all queries are passed in as either BSON or PHP objects which have been converted into BSON) it isn’t vulnerable to SQL injection. It is pretty easy to show that if your lazy and complacent when you code you can leave yourself just as vulnerable to attack.
Lets assume we have a table of users with a username and password field. In MySQL you’d be asking for trouble if in your authentication function you did the something along the lines of the following:
if (mysql_query(“SELECT * FROM users WHERE username=’$_GET['username']‘ AND password=’” . $_GET['password'] . “’”)) {
do_auth();
}
And someone passed in
‘ OR ‘1′=’1
into your password field. If you simply checked the response and authenticated the user based on if a row was received from the MySQL Database the user would authenticate as the $_GET['username'] every time. The correct approach would be to sanitize your $_GET parameters before you pass them into MySQL.
In MongoDB you might be tempted to do something like
if ($result = $mongo->test->users->findone(array(”username” => $_GET['username'], “password” => $_GET['password']))) {
do_login();
}
No query language no SQL injection right? Wrong. Epic fail. Don’t forget in PHP when you append [] to a $_GET['variable'] it turns into an array within php.
http://woot.php?variable[]=hello
$_GET['variable'] is now a PHP array(0 => ‘hello’). We can even assign the key of the array like this
http://woot.php?variable[$ne]=hello
Now $_GET['variable'] is a PHP with array with a key array(’$ne’ =>’hello’). When you pass this to mongo db as your password paramater it evaluates to “Password does not equal ‘hello’” which will pass every time.
Update: Simply filtering out $ne strings from the array keys isn’t good enough as it appears that the mongo driver is also vulnerable to null byte injection. array(’$ne\0wootwoot’ => ‘hello’) will evaluate to array(’$ne’ => ‘hello’);
What can you do? Sanitize your input. Don’t allow multi dimensional arrays to be passed as a input parameters to mongo. Surprisingly there isn’t a function built into the mongodb pecl extension to do this. The function below called “MongoSanatize” should make all user input for MongoDB safe.
<?php
function MongoSanatize($var) {if (is_array($var)) {
$newVar = array();
foreach($var as $key => $value)
{
$newKey = $key;if (is_string($key))
$newKey = str_replace(array(chr(0), '$'), '', $key);if (is_array($value))
$newVar[$newKey] = MongoSanatize($value);
else
$newVar[$newKey] = $value;
}return $newVar;
}return $var;
}
The function strips out all dollar signs and null characters from the key values on the array. If its run on a string or integer it should just return the string or integer
According to the Australian Computer Society and DIAC (The department for immigration) there is a massive shortage in Australia of “Computing Professionals specialising in Network Security/Firewall/Internet Security”.
No surprise there, whats more of a shocker is that the very people who assess the skills of would be migrants to Australia can’t even secure their own website against the most basic types of Injection attacks – namely cross site scripting (I’m guessing its down to the skills shortage)

Security flaw
The ACS however don’t seem to be concerned – I’ve emailed them twice at the beginning of the week about the fault and they’ve yet to reply to my email or even fix it. The carefully crafted link below will generate the above screen shot.
http://www.acs.org.au/index.cfm?action=load&temID=search&searchtxt="><h1>hello</h1><script>alert(document.cookie);</script><input type="hidden"&pageno=1&display=1&searchbtn.x=53&searchbtn.y=16
The code is not malicious, the above script will just output the current cookie to the screen. With security flaws like this lets hope the ACS aren’t “shaping our future”…
Update 27th January It appears that someone at the ACS has fixed the issue, but only to the extent of filtering the <script></script> tags from the input string… HTML injection is still possible, wouldn’t it have been easier just to use html_entities() or similar asp.net function to sanitize the string before displaying it? HTML injection is still a big security risk.
So I got an email today for a job in Tower Hill (thats central london). The job came with a simple programming test to write a script that parsed a tab separated file and produced a batch script as the output. They kindly provided a working copy of their solution on their website so you could validate the output of your code.
If I was going to advertise a job in a company and provide an online example of my own code I’d make darn sure that, unless the sole purpose of my online code was to find someone who knew what an XSS flaw was, that the link to the script I sent a prospective employee to wasnt vunerable to Cross Site Scripting attacks. Eeek. Worse still as their script seemed to accept either GET or POST variables as inputs (they were probably checking $_REQUEST rather than $_POST or $_GET in their code) it was possible to format a link that injected HTML code straight into their website.

Screenshot of the flaw
You can mitigate the threat from these types of attacks by properly sanitizing your variables before they are displayed. If this is on a HTML page and you are expecting an integer value then intval might be a good function to use, if its a text field you might try htmlentities. If any data is going into a database then you need to be using mysql_escape_string on all of your variables.
As I’ve not alerted the company to the flaw I wont post the URL to the exploit. Luckily the page in question can’t be found within googles’ indexes. I wonder if anyone else will notice…
Being ultra paranoid about using other peoples Wifi connections I’ve come up with a solution to make things a little safer. Its by no means new having been around for quite a while but it works well. Ive setup Apache on my web server to act as a proxy server for connections originating from 127.0.0.1. I then create a secure tunnel from my local machine using SSL and direct my web browser to connect using my new secure Proxy. This is great for extra security when browsing the internet and checking emails on insecure wifi networks.
If you want to setup your own Proxy you’ll need Apache installed with mod_proxy, mod_proxy_http and mod_proxy_ftp, you’ll also need ssh access to a server thats secure. Once Apache and mod_proxy are installed you need to add the following lines to your Apache config file.
ProxyRequests Off
Listen 127.0.0.1:80
<VirtualHost 127.0.0.1>
ProxyRequests On
ProxyPreserveHost On
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog /tmp/proxy_log common
</VirtualHost>
The proxy requests off line is very important as you dont want anyone else who cant connect to 127.0.0.1 from using your proxy server.
Once you’ve done that you just need to setup your SSH tunnel
ssh -p 22 user@yourserver.com -N -f -L 127.0.0.1/4444/127.0.0.1/80
This will connect from your computer to the sshd server on port 22, listen on the local port 4444 and connect to your proxy running on port 80 on 127.0.0.1 on your server. Once that has been done just change your Browser Proxy Settings to connect to 127.0.0.1:4444
Your setup will go from looking like this where your data is being sent over an insecure wifi connection

A normal browsing using a WiFi enabled laptop
To this setup where your data is encrypted via a tunnel and passed to a server that is connected to the internet.

Browsing using an SSH tunnel and Proxy server via WiFi
Now your crummy wifi connection is a little bit more secure (for all requests over the proxy at least)…