In association with heise online

30 June 2006, 09:10

Tobias Engler

Break In

Tools for testing Web applications

A great deal of testing and troubleshooting has to be performed before a Web application runs satisfactorily. To make sure that the application does not have any security holes that might even endanger the entire Web server, comprehensive safety tests (penetration tests) have to be performed. Special tools and proxies play an important role in this process.

In Web applications, sloppy programming can quickly become a security problem, especially when user interaction is desired -- possibly even allowing the server to be broken into. Even minor weak points in the code can have major consequences: hence there is much current discussion regarding XSS (Cross-Site-Scripting) [1] and SQL injection [2] methods. Techniques like directory traversals may reveal information about the server structure or may even allow access to files outside of the content directories. Software also has to be protected from "Unicode attacks," in which hackers try to trick the server by transmitting Unicode instead of ASCII characters as hexadecimals (%c0%af). The ability to prevent such attacks is part of the basic knowledge that any programmer needs to have.

While it is good to be able to rely on in-house programming abilities, it nonetheless pays to verify them. To see how well a Web application can protect itself from attacks and how it reacts to provoked errors and targeted manipulation, the application should undergo a penetration test before it is put into productive operation. In addition to knowledge about the background of weak points, the testers should also be creative and intuitive when entering form data, calling web sites, and interpreting the results gathered. Of course, special tools are also available to facilitate such tests.

image 1 [302 x 253 Pixel @ 12,7 KB]
Pen testers can even use proxies to manipulate hard-to-reach parameters in a POST request

Hidden friends

To gather information about a system or application, you can start by taking a look at the HTML source text transmitted. Often, it provides more information than the browser's output might suggest. While access data provided as clear text in HTML comments have become a rarity, copyright information at least usually tells you what modules are used and indicates where some weak points may be. For additional information, also check the INCLUDE files. HIDDEN fields are also common, and programmers occasionally forget them for validation. And yet, it is quite easy to smuggle in different values here: you can do so directly by means of a GET query (a parameter value in the URL) or in a local copy of the HTML document.

In the latter method, however, the tester also has to change the path in the ACTION tag in his local copy. It is even easier if you take advantage of a special proxy (see below, "Toolbox"): the value shown there can simply be overwritten before the query is sent off.

image 2 [305 x 308 Pixel @ 20,8 KB]
A proxy presents a clear overview of the variables in a GET request and allows them to be edited

In general, parameters filled with values by the server are vulnerable, especially menus that offer a lot of items to choose from:

<form action"accountstatus.asp" method="get">
...
<select name="account">
<option value="12000123">12 000 123</option>
<option value="12555666">12 555 666</option>
...
</select>
...
</form>

If no authorization is necessary or if it has already been granted, you can enter any valid account number yourself. In the proxy method shown above, all you have to do is change the account parameter in the proxy's GUI to the value desired and send off the query.

Test functions stored within the HTML code, usually as JavaScript, are just as problematic. For instance, they verify credit card numbers or ensure that users have input all of the information required (means of payment, account number, etc.) before they are granted access. If subsequent validation on the server was forgotten, all you need to do is delete the appropriate JavaScript code in a local copy. If the site to be tested uses encapsulated content, such as Flash, to handle login and similar events, packet sniffers such as Ethereal can help you check which connection data and passwords are transmitted over the wires.

Print Version | Permalink: http://h-online.com/-747167
  • Twitter
  • Facebook
  • submit to slashdot
  • StumbleUpon
  • submit to reddit
 


  • July's Community Calendar





The H Open

The H Security

The H Developer

The H Internet Toolkit