Approaches
Two central approaches are pretty useful for discovering bugs in a web application during source code analysis: a top-down approach and a bottom-up approach. So how do we delineate the two?
We start with the concept of sources and sinks. Sources are locations where input is provided to or handled by the web application from external sources, like an API call. Sinks are locations where the information from a source stored or executed upon, like a SQL query against a database using input parameters from an API call.
A top-down approach involves us identifying the data produced by a source and following its path until it reaches a sink. A bottom-up approach involves us identifying where data is handled in privileged scenarios and tracing that data back to a source.
Both approaches have their own merits and are useful in different scenarios. If we’re looking for initial access, authentication bypasses, or the ability to do bad things without authentication, we might want to use a top-down approach. If we’re interested in command execution or abusing other administrative actions, we might want to use a bottom-up approach.
HTTP routing patterns
To assist in our web application reversing journey, we’ll have to recognize common HTTP routing patterns for web applications, web APIs, etc. so we can recognize when we’ve found a source or a sink, enabling us to better trace data flow.
File system routing is a common scheme, mapping the URL of a request to the host’s filesystem. A web server like Apache will establish a document root or web root to store externally accessible files.
Servlet mappings are used by Java applications, controlling how the application handles incoming HTTP requests. Usually, the web application maintains a web.xml file that defines the HTTP routing configuration, mapping URL patterns to particular Java servlets.
Direct mapping occurs in other web frameworks like ExpressJS, Spring MVC, or Flask where the web application explicitly defines a URL pattern and maps the URL pattern to a class or method in the source code.
Our checklist
Identifying vulnerabilities in a web application can’t just be solely based on intuition, can it? Let’s make a checklist of things to look for, in no particular order, that might uncover interesting paths to discovering a vulnerability:
- Analyze parts of the web application that receive user input without authentication.
- Review parts of the web application that are likely to receive less attention or scrutiny, like post-authentication API calls, etc.
- Investigate user input sanitization thoroughly. Is the sanitization conducted with open source libraries, or did they roll their own checkers?
- How are queries created and provided to the underlying database? Does the application parameterize query input? Does the application sanitize query input?
- Inspect the logic for account creation or password resets and recovery. Can this functionality be bypassed?
- Does the application interact with the host operating system? Can we inject commands?
- Are the programming language-specific vulnerabilities present?