Posts Tagged ‘Security’

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.

When usability and security meet

Sunday, October 26th, 2008

Nearly always when your writing a website or web application usability and security clash – this clash is normally brought about by the client or designer insisting on specific features. As a Web Applications Developer and Linux administrator it is my opinion is that usability should never interfere with security.

Consider a basic login system, there are a lot of ways that a client or designers can request features that can interfere with the security of the system and sometimes no matter how hard you try to convince them that its a bad idea they still want the feature implemented. I’ve come up a list of frequently requested features from designers and a few solutions to try and keep both the programmer and designer happy.

Weak Password Policy

Many websites don’t seem to have any sort of password policy other than a one line statement stating that “the password must be 6 characters or more in length”. I cant emphasize how important it is to have a good password security policy. Brutus has made a name for itself as a web-based password cracker, it can run through a dictionary of words incredibly quickly. If you allow dictionary words to be used as a password then it should come no surprise when your system is compromised.

There’s not much you can do if a user or designer requests a weak password policy other than try to point out the reasons as to why its a bad idea. You could lock the users account after a specific number of failed attempts. Of course users wont be happy when their account is suspended and they cant log in

CAPTCHAs provide a solution which can prevent automated programs from guessing the password. There is no need to present the CAPTCHA straight away – after 4 or 5 failed attempts would be suitable. Its worth mentioning that many CAPTCHAs (including google’s) have been broken, though if they are designed correctly they will significantly increase the time needed for an attacker to carry out an attack. I’ll be posting soon about weak CAPTCHAs and methods for designing strong CAPTCHAs

Password reminders

When users forget their password some insist on being able to request a copy of their password via email. With the increase in password fatigue its more than likely that a user will use the same password for multiple websites. If your website gets breached and you store the password as plain text your website the breach could soon turn in to the least of your problems as other accounts belonging to the user become compromised.

Its best to store passwords as SHA1 hashes in the database, preferably with a unique salt for each password (this will help prevent rainbow table attacks). It means you cant request a password reminder, but you can always request a new password by email. The system can use this opportunity to set them a new password that compiles with the password policy.

It always worries me when I’m on the phone talking to a large company and they prompt me for my password – its a worry that I have to tell someone at the company my password and even more worrying when they suggest that I’m quite close.

Data leakage

Some websites kindly prompt you when you have entered an invalid and return a different message telling you when your password is invalid. Nice on the usability front for when the user forgets their username but horrible when it comes to security. It leaves a potential hacker the scope to guess the users who are registered with the system and then launch an attack on each one of those user accounts hoping to find an account with a weak password. Having a username reminder feature which works via email or even using the users email as their username helps to prevent the user forgetting their login details.

Conclusion

Usability and Security are clearly Orthogonal and you tread a fine line when trying to satisfy all the stakeholders. It continues to amaze me that designers and clients are still requesting that programmers forfeit security at the price of slightly better usability even when the consequences have been clearly explained. It amazes me more when programmers go ahead and implement their suggestions without confronting the other stakeholders about their security concerts. It might well keep someone happy in the short term, but in the long term its a disaster waiting to happen.