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)  and SQL injection  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.
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.
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">
<option value="12000123">12 000 123</option>
<option value="12555666">12 555 666</option>
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.