Posts Tagged ‘Security’

MongoDB is vulnerable to SQL injection (in PHP at least)

Thursday, July 29th, 2010

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.

What can you do? Sanitise 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, With more and more large sites turning to MongoDB its only going to be a matter of time before a large website is found to be vulnerable to this type of attack.

Skills shortage leaves Australian Computer Society open to attack.

Friday, January 22nd, 2010

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

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.

How not to advertise for a PHP programming job

Wednesday, October 28th, 2009

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 with 'Cheese!!' being injected.

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…

Breaking a CAPTCHA – rules for good design

Sunday, June 7th, 2009

A CAPTCHA is a challenge and response test used to verify that the end-user is a human and not a computer – CAPTCHA is an acronym standing for a Completely Automated Public Turing test to tell Computers and Humans Apart.

Captchas seem to have become increasingly popular as a method to prevent the submission of spam and automated responses. You can see a captcha generated by the popular reCAPTCHA service when you post a comment on this blog.

The main problem with the Captcha is that sometimes the people who implement them are lazy or have no knowledge about how create an image that a computer would find hard to decode. Captchas must be generated server side and over the last few months I have seen an increase in the number of client-side captchas generated by software such as Adobe Flex. If you generate a Captcha client side it is not secure.

When designing a Captcha its important to understand what computers find it hard to do.

Its hard for a computer to segment an image. Computers need to segment an image in order to classify each character of text. Anything you can do – such as running letters together – that makes the image harder to segment will make it much harder for a computer to segment your image.

Lets look at the following example to see how easy it is to segment the text from a badly designed captcha.

Image segmentation in 3 steps, (1) Capture the image, (2) Apply thresholding (3) Convolution Matrix

Image segmentation in 3 steps, (1) Acquire the image, (2) Apply thresholding (3) Apply a simple Convolution Matrix

Two very simple algorithms have been applied to the Captcha above. Firstly thresholding and secondly a convolution matrix to remove the vertical and horizontal lines. If we look at the captcha below we can see that some captchas can be segmented just by using thresholding alone.

Even worse - The background can easily be removed by just simple thresholding

Even worse - The background can easily be removed by just simple thresholding

Once the image has been segmented the computer then has to then classify each character. The more options there are for each character the higher the chance of the computer classifying the letter incorrectly – so when your designing your captcha it pays to use the entire alphabet and not restrict yourself to just numbers or letters – It follows that the longer your captcha the more chance there is of the computer making a mistake in classification. Google makes its captchas between 8 and 11 characters in length.

Both of the captchas we have seen so far are easy to segment – they are also easy to classify. This is due to the similarity of the characters within the image (both 4’s look the same in the second captcha) – if we want to make it tricky for the computer to classify each character we need to use different fonts for each character or warp each character by applying rotation or other image morphing operators. The following Captcha from Yahoo! is much harder to segment due to there being little space between each character, the captcha also uses both upper and lower case characters and has been morphed so that the string is harder to classify.

A set of captchas from Yahoo! that are very hard to segment

A set of captchas from Yahoo! that are hard to segment and classify

Sadly as captchas become harder for computers to read they also become harder for humans to read – there is a fine line between providing the necessary security and frustrating a user with a captcha that is impossible to read.

Google has an interesting solution to this using Markov Chains – here random strings that appear to be words are generated using a statistical method known as a Markov Chain. These words are much easier for a human to read because they seem to be a normal word, however they are not words and this is important. If dictionary words were use then a dictionary could be introduced to improve captcha classification rates.

Google captchas use markov chains to make them easier to read

Google captchas use Markov chains to make them easier to read

Its pretty easy to design and write a good captcha using PHP GD or something similar. If you cant be bothered to write a captcha then services such as reCAPTCHA exist which can provide you with an effective captcha solution (although this is vulnerable to the “penis flood attack“)

No captcha will ever be 100% secure, rumor has it that even google’s captcha has been broken with a classification rate of 20%; there are even stories of captcha sweatshops emerging around the world where people are paid  to solve Captchas – a kind of mechanical Turk.

As algorithms become more sophisticated an alternative to captchas need to be found but until these have been found you may as well make sure that your captchas are secure.

Creating secure web applications

Thursday, November 20th, 2008

So many companies tend to think of security as an afterthought. When it comes to developing Web Applications many companies and clients in particular seem to have their priorities wrong. In order of priority they seem to go something like this:-

  • Get it done cheap
  • Get it out quick
  • Make it look nice
  • Make it really easy to use
  • Sell it to lots of people

And somewhere way down the line after 10 more seemingly insignificant priorities

  • Security

Don’t get me wrong; I can see why people order their priorities like this – if you want to make money fast then it makes sense but if you want to make money in the long term then it would probably pay to take a good look at your system security before you dive straight into designing the application.

Developing your application security as an after thought is not only a terrible idea in terms of security it’ll also cost you a lot more. Having to go back through all of your code and retrofit the security is a seriously labor intensive task. Security testing and design should always be the top of your list of priorities – especially with a web application – and its something that should continue to be tested and revised as you develop your application.

Coming up with a good security model and sticking with it will save you a lot of time and will result in a more secure application. It might be that software companies don’t see any immediate incentive in developing good security models or it might be that the client isn’t concerned about the security risks – both reasons are simply not good enough for ignoring application security.

If your company’s application gets hacked it not only reflects badly on the client but badly on the software developer. If security is an afterthought its also going to cost you as the developer to find and patch the vulnerability.

The bottom line is that security must never be an afterthought.