Most seriously engineered Internet sites deploy firewalls and other similar techniques to restrict Internet access to limited ranges of network services. Although the hacking community continues to search for sites and networks that are over generous with the services and the number of services enabled, increasing effort is being placed into discovering and exploiting security flaws and weaknesses available in commonly offered services, namely web-based applications.
What are web applications?
A web application is a program that operates in a client and server relationship using the hypertext transfer protocol (HTTP) and its more secure version (HTTPS). The client in most cases is a web browser, such as Internet Explorer or Netscape, and the server is the web server along with associated application services on the Internet site. A simple example of this relationship could be an online holiday booking site. The process starts with a user entering the site's address in their browser window. The browser connects to that address and the web server in turn makes a request to the backend database to load up the latest deals and holiday prices, and starts building the page for the user.
The user then decides he or she would like to book a holiday to go to South Africa. They choose the correct date, price, and submit their credit card details, which completes the booking. The process involves many servers operating behind the scenes.
This process may seem simple, but at any point there could have been a handful of different servers, applications and technologies all working together to perform the same function, giving customers their holiday bookings.
What is all the fuss about?
If a company is running an e-commerce web server, the firewall will need to allow all traffic from the Internet to that server, on the standard web ports 80 and 443, in order for customers to conduct business on the site. At the same time, the firewall will be dropping any traffic aimed at network services such as Telnet and FTP. One of the shortcomings of firewalls is that they do not have the capability to analyze the network traffic they allow. A firewall receives a packet aimed for the web server on port 80 and passes that packet onto the web server according to the firewall policy set in place. This means simply that the policy says the traffic is allowed through, so the firewall allows it through.
As you can imagine, attackers have an open playground when attacking applications because even the most expensive firewall lets them do whatever they want.
Understanding the problems
The main causes of today's web application vulnerabilities lie within the development structure process. Developers are under constant pressure to meet deadlines and make sure the application works from day one. With this amount of pressure, it is no surprise that shortcuts are taken, and the process of making sure that the code is secure is often overlooked. Here we will look at some of the most common problems seen with vulnerable web applications.
Data that is sent between the user's browser and the web application may be changed from the original by an attacker. Using this technique it could be possible for an attacker to change certain set options on a web site, such as the price of a holiday or the latest electronic gadget.
This is the ability to inject malicious code into a site and have a user execute that code as it was coming from the originating site. In cases of online ordering, it would be possible for an attacker to send back a page that asked for credit card information that sends it back directly to the attacker and not the site it was intended for.
Direct database commands
As web sites that are more complex are deployed, there is a requirement for a backend database to service the information on a per-session basis. The problem with this scenario may be that the web applications making database calls seldom check for user input, and by using specially crafted URLs or queries it may be possible for a user to call the database and execute commands directly using their browser.
Direct operating system commands
There are a variety of programming languages that can be used to develop web sites today. The problem with all these languages is the native ability of the code to execute system commands on the system if no validation has been incorporated into the design and code of the site. This would allow an attacker to execute commands on the server with their browser.
With any web server setup, the web root directory is a virtual root directory sitting on top of an existing operating system. If the application does not check for meta-characters such as "../" it may be possible to break out of the web root directory and start exploring the file system as if the attacker was logged on from a terminal. The attacker may then be able to gather important files.
A good example of this kind of attack belonged to Microsoft's Internet Information Server (IIS). It was discovered that IIS had multiple problems when it came to handling path traversal using the URL.
For example: www.secureonlinebanksite.com/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir
Here again you can see that the URL contains meta-characters and is breaking out of the root directory of the web site to execute "cmd.exe", Windows' command shell program.
This is an example URL that you might see when purchasing a new computer for the kids: www.superonlineelectricalstore.com/onlinepurchase/authorization/account.asp?accnumber=111223232
Here it may be possible to change one of the parameters within the URL, i.e. the account number, and see the details of another customer's order. If the application does not force session identifiers, the application will let this user see any account they want. The accounts could include details of credit cards registered on the account or home addresses, even ages and names of children, etc.
The above examples are only a small percentage of problems faced when dealing with applications.
What can be done to make web applications more secure?
As we have seen, there is a need for developers and administration staff to understand the implications of running a web application and to pay attention to the security needs of that application. Throughout the development and design process, security needs to be introduced from the beginning and not thought of as an end process in which it is bolted on.
The Open Web Application Security Project (OWASP) (www.owasp.org/testing) is in the process of creating a guideline that outlines the more common application security problems, how to test for them, and how to resolve the issues that arise.
Dan Cuthbert is a security consultant working for IDSec Network Security Consultants in London. He specializes in network and application security testing and is part of the international OWASP testing team.