Analyzing the Application
Enumerating as much of the application’s content as possible is only one element of the mapping process. Equally important is the task of analyzing the application’s functionality, behavior, and technologies employed, in order to identify the key attack surfaces that it exposes, and begin formulating an approach to probing the application for exploitable vulnerabilities.
Some key areas to investigate are:
■ The core functionality of the application — the actions that it can be leveraged to perform when used as intended.
■ Other more peripheral behavior of the application, including off-site links, error messages, administrative and logging functions, use of redirects, and so on.
■ The core security mechanisms and how they function, in particular management of session state, access controls, and authentication mechanisms and supporting logic (user registration, password change, account recovery, etc.).
■ All of the different locations at which user-supplied input is processed by the application — every URL, query string parameter, item of POST data, cookie, and the like.
■ The technologies employed on the client side, including forms, client- side scripts, thick-client components (Java applets, ActiveX controls, and Flash), and cookies.
■ The technologies employed on the server side, including static and dynamic pages, the types of request parameters employed, use of SSL, web server software, interaction with databases, email systems and other back-end components.
■ Any other details that may be gleaned about the internal structure and functionality of the server-side application — the mechanisms it uses behind the scenes to deliver the functionality and behavior that is visible from the client perspective.
Identifying Entry Points for User Input
The majority of ways in which the application captures user input for server-side processing should be obvious when reviewing the HTTP requests that are generated as you walk through the application’s functionality. The key locations to pay attention to are:
■ Every URL string up to the query string marker.
■ Every parameter submitted within the URL query string.
■ Every parameter submitted within the body of a POST request.
■ Every cookie.
■ Every other HTTP header that in rare cases may be processed by the application, in particular the User-Agent , Referer , Accept , Accept-Language , and Host headers.
Some applications do not employ the standard query string format but employ their own custom scheme, which
may use nonstandard query string markers and field separators, may embed other data schemes such as XML within the query string, or may effectively place the query string within what appears to be the directory or filename portion of the URL. Here are some examples of nonstandard query string formats that the authors have encountered in the wild:
■ /dir/file;foo=bar&foo2=bar2
■ /dir/file?foo=bar$foo2=bar2
■ /dir/file/foo%3dbar%26foo2%3dbar2
■ /dir/foo.bar/file
■ /dir/foo=bar/file
■ /dir/file?param=foo:bar
■ /dir/file?data=
%3cfoo%3ebar%3c%2ffoo%3e%3cfoo2%3ebar2%3c%2ffoo2%3e
If a nonstandard query string format is being used, then you will need to take account of this when probing the application for all kinds of common vulnerabilities. For example, when testing the final URL in this list, if you were to
ignore the custom format and simply treat the query string as containing a single parameter called data , and so submit various kinds of attack payloads as the value of this parameter, you would miss many kinds of vulnerability that may exist in the processing of the query string. If, conversely, you dissect the format and place your payloads within the embedded XML data fields, you may immediately discover a critical bug such as SQL injection or path traversal.
A final class of entry points for user input includes any out-of-band channel by which the application receives data that you may be able to control. Some of these entry points may be entirely undetectable if you simply inspect the HTTP traffic generated by the application, and finding them usually requires an understanding of the wider context of the functionality that the application implements. Some examples of web applications that receive user-controllable data via an out-of-band channel include:
■ A web mail application which processes and renders email messages received via SMTP.
■ A publishing application that contains a function to retrieve content via HTTP from another server.
■ An intrusion detection application that gathers data using a network sniffer and presents this using a web application interface.
NEXT is..Identifying Server-Side Technologies……….,
