Web Application Security : Harder than you think

Wednesday, July 3, 2002

I was reading an advertisement the other day, from some company offering web hosting services. They were offering their services as secure on the basis that they used "SSL Certificates", "Firewalls", and "VPNs" ( plus a few other buzzwords ). Sounds great, but does this make their websites secure ?

Not by a long shot. Read on.

A couple of months ago I was doing a security review of a New Zealand based retailer who shall remain nameless - we'll call them Acme Ltd. Now they had a nice website for which they had paid good money to a company to develop and host, we'll call the hosting company Webs'r'Us - not their real name.

I had been asked to do a review of the security of the site. The first thing I did was to skim through everything taking note on what parts of the site were static pages, what part were dynamically generated, and what parts would accept input into fields to be submitted for processing. Not very interesting stuff, in fact a lot of IT security work is pretty boring, but I digress.

One of the first things I try is to do directory listings, so I entered "/images" onto the end of the website URL - and voila! I got a directory listing of every image on their website. In this case, the images directory also had some HTML and program files in it, which I called up in my browser and soon found that I could use these to call up the details of customer orders - including customer details like Email addresses and phone numbers. Oh dear.

They had one of those 'Contact Us' forms, that are obviously calling a program on the web server to take the users' input and email it to someone at the company. From looking at the hidden fields on the form I found that I could change it to send Email to anywhere I liked.

Further digging soon showed up more goodies : I found a form that let me enter SQL statements to perform any database query that I wished. Another form let me create a file and save it anywhere on the server - overwriting any existing file. From exploiting these, accessing or changing anything on the server becomes only a minor challenge. I had gained complete control of the system and all that it contained.

These vulnerable forms and functions were a combination of faulty application code, mixed with a number of testing functions possibly left behind by the developers of the site. There was obviously little checking being performed on data which was being entered into the web site functions.

The surprising thing is that Webs'R'Us believed that the website was secure - they had bought a certificate from Verisign and set up strong 128-bit SSL encryption. They had the web server connected to a DMZ network behind a firewall to protect it, and their administrator passwords were very strong. Webs'R'Us ensured Acme Ltd that their website and the information it contained was secure. But in the end the security measures that they did put in place were ineffective when there were gaping holes in the application which allowed attackers in to access almost whatever they liked.

When securing a border the defender is always at a disadvantage. While an attacker has the choice of attacking anywhere, the defender must defend everywhere. In the case of web applications, attack is easier than defense. This makes it very hard to effectively secure a system - and the more complex the system is, the harder it will be to secure.

Common security problems in Web applications :

  • Email forms based on CGI, PHP, etc. which don't check their inputs, and have hidden fields specifying the destination of the Email message. These are just great - they can be easily exploited to send Email anywhere which appear to be sent by the web server or with a falsified From address to appear to be from any address you like.

  • Functions which don't check their input fields. As with the Email forms, many functions in general which take input from the user can be exploited by entering HTML code, system commands, and other bogus data into their fields. This can result in an attacker getting access to things they should not have access to, or even crashing the web server.

  • Directory listings available. Lots of servers allow browsers to list the contents of directories. Try directories like "images", "cgi-bin", "test", and so on. Often you will get a directory listing of things which the site owner would rather not let you see.

  • Old code left around. If I go to a website which is written in, say, PHP - then one of the first things I'll try is 
    http://www.site.com/test.php
    You would be surprised how often this can give an attacker access to test code which can be exploited.

  • Poorly designed code. One example was at another site that I looked at which had a CGI script for performing server-side includes on web servers which didn't support this functionality. Unfortunately this CGI script didn't check just what it was sending back to the browser and could be used to view any file on the server such as system configuration files.