Web Application Security Testing - Part 5

Advertisements

 In the earlier articles of this series, we have concentrated on errors or mistakes that should be avoided at the code level and importance of data validation at client side and again on server side. If you have not read earlier articles in this series, you might find it interesting to read earlier articles covering many concepts related to web application security testing.
 
In this part we will establish the importance of securing our environment as well for providing complete security to web application. Web application is hosted in the environment, which is accessible from the out side world. Client interact with the server and database, if proper care is not taken vulnerabilities in the environment can be exploited and  as a result security will be compromised. We will discuss, different vulnerabilities related to the environment on which web applications are hosted like stored procedures, command injection, fingerprinting and Denial Of Service. 

Stored Procedure

Stored Procedures are pre-written SQL queries that are supplied by the data-base vendor or third party custom procedures written in-house and integrated into the database.  In general, Stored Procedures can be used to improve security and performance of web application, but you need to make sure that you use them with proper care and give only minimum necessary privilege to the user.

In Microsoft SQL Server, many of the stored procedures integrate the database into operating system. This can allow users with sufficient privileges to create login, schedule tasks and run command line programs which can be very dangerous. In Oracle, this functionality is not available out of the box, but developers can use either Java or PL/SQL languages supported by Oracle to build this functionality.

If you are using Microsoft SQL, one of the most dangerous stored procedure to look for is xp_cmdshell. This is an interface from database to operating system that can allow attacker to run arbitrary commands on the web server machine. To use this stored procedure, you need to pass following command as a separate query

EXEC master.. xp_cmdshell 'any command'

EXEC is the command used to execute this stored procedure and master.. is telling that this stored procedure is not part of current database. Similar to xp_cmdshell , there are many built-in stored procedures for accessing registry, file system and so on.

Protection against this vulnerability lies with the proper access permission. Ideally, every user should be granted permission for only what he needs and everything else should be restricted.

Command Injection

As suggested by the name, command injection is very much similar to the SQL injection. In SQL injection we inject any arbitrary SQL query along with the one intended. Similarly, in command injection we inject additional commands along eith the one intended. Command Injection allows an attacker to easily execute shell commands by piggybacking them off the initial command.

This target is applied mostly at places where input is directed to operating system commands or executable programs that resides on the server. Probability of this vulnerability's presence might be more on the UNIX operating systems because there are many small programs that can be executed from the command line and developers can decide to use them directly as well.

Once you identify place where commands are being passed to the operating system you can now try to piggyback commands after semi column or forcing new line characters. System will treat anything after semicolumn a different command rather than same command. You can also use | ( pipe ) and > (greater than) character to redirect the output to some file using this technique.

Proper safeguard from this attack is obviously, input validation. Along with input validation, exposure to this attack can also be minimized by running the web server as a low-level restricted user. Because all code and system call execute with the permissions of the user account that initiated them, it is wise to ensure that the web server is running as a user that can perform only limited operations.

Server Fingerprinting

Along with all the good knowledge Internet brings to everyone, it also makes it possible for everyone to know about the existing vulnerabilities in different operating system, databases and web servers. There may be chances that some one is still running older version of IIS and Apache, and most of the attackers know vulnerabilities present in these systems. There could be valid business reason for many people to still use the older version.

One of the very important piece of information for any attacker is the knowledge of your web server. If your attacker have information about the web server it can be fairly easy to find out vulnerabilities present in that particular web server.  Attack to identify what kind of web server you web application is running on is called finger printing. Idea is to find the version of the Web server and find a known exploit for it.

You might think that getting version number is fairly easy since it is specified in one of the headers for HTTP response. Fortunately, these responses can be changed by changing the configuration file on the web server. Nevertheless, you should always make sure that this is indeed changed. You can use tools like HTTPPrint to find out information about web server with some confidence. The only protection against this attack is to know what your attacker already knows and proactively make sure that your environment is protected against known vulnerabilities. It is always a good idea to keep an eye on sites like http://www.securityfocus.com  and http://www.osvdb.org to get information about the known vulnerabilities.

Denial Of Service

Every time you request some operation on your web application there are many processes which happens in the backend. Every request on the web server consume some resources. If an attacker floods web server with many requests and consumes all its resources so that web application becomes unavailable or unresponsive to new requests, it is called Denial of Service ( or DOS ) attack.

To perform this attack, you need to find out the places where web application is taking longest time to return the result. Places where your application is accessing databases or doing complex computations. Attacks like SQL injection can also be used to inject complex SQL queries which can result in Denial of Service.  Another approach could be to request a page but be slow in accepting data in response. Web server will keep connection open until it receives everything. If you can have many connections like these, eventually server will run out of the number of connections it can open and deny service to any new connection request.

It is worth noting here that according to the Internet standards, it is not possible to make more than two connections from the same browser to web server. You will need to write simple script to forks off multiple child processes to request same URL. You also need to check effect of these requests on your web application.

It is very difficult to protect against this attack. Normally clustering and load balancing is used to make sure that large number of requests are handled appropriately. Generally it is not considered a good approach to rely only only on load balancing and for sophisticated high-volume site it is not uncommon to find Intrusion Detection System and Bandwidth management solution to counter this attack.

Hope you found these articles interesting and they gave you some insight on different aspects related to web application security testing. In the next article, we will explore security aspects related to authentication and web services.

These articles are influenced by the book ( "How to Break Web Software" from Mike Andrews and James A. Whittaker ) I have recently read and should be a good read for you if you need information on web application security testing.`