In web application security testing, simply enumerating the application's content — finding all its pages and links — is only a small part of the job. Equally important is deeply analyzing the application's functionality, behavior, and the technologies it employs. This analysis is what helps us understand the application's key attack surfaces and formulate a proper approach for probing it for vulnerabilities.
Here are some of the key areas worth investigating:
- Core functionality — the actions the application performs when used as intended
- Peripheral behavior — off-site links, error messages, administrative and logging functions, and the use of redirects
- Core security mechanisms — session state management, access controls, and authentication logic (registration, password change, account recovery)
- All locations where user input is processed — every URL, query string parameter, POST data item, and cookie
- Client-side technologies — forms, client-side scripts, thick-client components (Java applets, ActiveX controls, Flash), and cookies
- Server-side technologies — static and dynamic pages, types of request parameters used, SSL usage, web server software, database interaction, and email systems
- Any additional details about the server's internal structure — the behind-the-scenes mechanisms used to deliver the functionality visible from the client side
Together, these points build a complete picture of the application — not just its visible functionality, but the logic operating behind it.
Identifying Entry Points for User Input
Most of the ways an application captures user input for server-side processing become clear when you review the HTTP requests generated while walking through the application's functionality. Here are the key locations to pay attention to:
- 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 the application might process — particularly the User-Agent, Referer, Accept, Accept-Language, and Host headers
Let's look at each of these entry points in more detail.
URL File Paths
The parts of a URL that precede the query string are often overlooked as entry points, since they're assumed to simply be directory and file names on the server. However, in applications using REST-style URLs, these components actually function as data parameters — just as important as the query string itself.
For example: http://eis/shop/browse/electronics/iPhone3G/ — here, "electronics" and "iPhone3G" shouldn't be treated as simple path segments, but as parameters to a search function.
Similarly, a URL like http://eis/updates/2010/12/25/my-new-iphone/ may also be handled in a RESTful manner, where each component following "updates" acts as dynamic data.
Most REST-style URLs can be identified by their structure and application context. However, no fixed rule should be assumed, since it's entirely up to the application's developers how users are meant to interact with it.
Request Parameters
Parameters submitted within the URL query string, message body, and cookies are the most obvious entry points for user input. But not every application follows the standard name=value format — some use custom schemes, such as nonstandard separators or embedded XML data.
Some real-world examples of nonstandard parameter formats:
/dir/file;foo=bar&foo2=bar2/dir/file?foo=bar$foo2=bar2/dir/file/foo%3dbar%26foo2%3dbar2/dir/foo.bar/file/dir/file?data=%3cfoo%3ebar%3c%2ffoo%3e...
If a tester ignores these nonstandard formats and simply performs generic testing, many vulnerabilities can be missed. But if the format is properly dissected and payloads are placed within the embedded fields (like XML data), critical bugs such as SQL injection or path traversal can be uncovered immediately.
HTTP Headers
Many applications use the Referer and User-Agent headers for logging purposes — which means these headers should always be considered potential entry points for attacks.
Some applications inspect the Referer header to detect that a user arrived via a search engine, then echo or highlight the user's search term within the response. If this isn't properly sanitized, a crafted Referer value could enable persistent content injection.
Applications also use the User-Agent header to serve different interfaces to different devices (mobile, tablet, laptop). Spoofing this header to access the mobile version can expose an entirely different code path — one that may not have received as much security testing — potentially revealing issues like cross-site scripting.
Similarly, the X-Forwarded-For header is a risky point. When an application sits behind a load balancer or proxy, it may rely on this header to determine the client's IP address. Developers often mistakenly trust this value, when in fact it can be manipulated to deliver attacks such as SQL injection or persistent XSS.
Out-of-Band Channels
There's another class of user input that doesn't show up directly in HTTP traffic — these are called out-of-band channels. Identifying them requires understanding the application's broader business context. Some examples:
- A webmail application that processes emails received via SMTP
- A publishing tool that fetches content from another server via HTTP
- An intrusion detection system that collects data through network sniffing
- An API interface built for non-browser clients like mobile apps, whose data is later shared with the main web application
These channels are often missed during traditional testing, so uncovering them requires a solid understanding of the application's full functionality and architecture.
RECAP
Top comments (1)
please give any suggestion if any improvement