Where To Find Attack Vectors | HACKING EXPOSED WEB APPLICATIONS, 3rd Edition

Every GET and POST parameter is fodder for input validation attacks. Altering arguments, whether they are generated from FORM data or by the application, is a trivial feat. The easiest points of attack are input fields. Common fields are Login Name , Password, Address, Phone Number, Credit Card Number, and Search. Other fields that use dropdown menus should not be overlooked, either. The first step is to enumerate these fields and their approximate input type.

Don't be misled that input validation attacks can only be performed against fields that the user must complete. Every variable in the GET or POST request can be attacked . The high-profile targets will be identified by an in-depth survey of the application that lists files, parameters, and form fields.

Cookie values are another target. Cookies contain values that might never be intended for manipulation by a user, but which could be used to perform SQL injection or impersonate other users.

The Cookie is simply a specific instance of an HTTP header. In fact, any HTTP header is a vector for input validation attacks. Another example of HTTP header- targeted attacks includes HTTP response splitting, in which a legitimate response is prematurely truncated in order to inject a forged set of headers (usually cookies or cache-control , which do the maximum damage client-side).

Let's take a closer look at HTTP response splitting. This attack targets applications that use parameters to indicate redirects. For example, here is a potentially vulnerable URL:

http://website/redirect.cgi?page=http://website/welcome.cgi

A good input validation routine would ensure that the value for the page parameter consists of a valid URL. Yet if arbitrary characters can be included, then the parameter might be rewritten with something like this:

http://website/redirect.cgi?page=0d%0aContent-Type:%20text/ html%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/ html%0d%0a%0d%0a%3chtml%3eHello, world!%3c/html%3e

The original value of page has been replaced with a series of characters that mimic the HTTP response headers from a web server and includes a simple HTML string for "Hello, world!" The malicious payload is more easily understood by replacing the encoded characters:

 Content-Type: text/html HTTP/1.1 200 OK Content-Type: text/html     <html>Hello, world!</html>

The end result is that the web browser displays this faked HTML content rather than the HTML content intended for the redirect. The example appears innocuous , but a malicious attack could include JavaScript or content that appears to be a request for the user's password, social security number, credit card information, or other sensitive information. The point of this example is not how to create an effective phishing attack, but to demonstrate how a parameter's content can be manipulated to produce unintended effects.