Mapping an application: pages, forms and parameters

A burglar who wants to know where the weak points of a building are begins by walking around it. A tester does the same with an application: before looking for flaws, you list every door, window and letterbox. This step is called mapping, and it determines how good the rest of your audit will be.

Why map first?

A vulnerability can only be exploited through an entry point: a place where data from the outside enters the application. If you miss an entry point, you cannot test it, and the flaw behind it stays hidden. The WSTG calls this phase information gathering, and it has two goals:

• Build the inventory of pages, features and technologies.
• Understand the behaviour: who can do what, and how data flows from one step to the next.

Walk through it like a user first

With Burp running and intercept off, simply use the application as a normal user would. Register an account, log in, browse products, add something to the basket, change your profile, log out. This manual exploration, sometimes called spidering by hand, produces a site map in Burp that reflects real usage, including pages that only appear after specific actions.

As you go, ask yourself about each feature: what does it do, what data does it accept, and what would be the worst thing that could happen if this feature were misused? These questions guide your later tests.

The anatomy of an entry point

Data can reach an application in many places. Learn to spot all of them.

Where	Example	Why it matters
URL path	/products/42	The number may identify a record; we will test access to others in chapter 5.
Query string	/search?q=juice&page=2	Search terms and filters are classic places for input handling flaws.
Form fields	Login, registration, comment forms	User-supplied text that the server will process and often store.
Hidden fields	An invisible price or role field	Hidden does not mean protected: the user can see and change it.
Cookies	session, preferences	Hold session identity and sometimes sensitive settings.
HTTP headers	Referer, User-Agent, custom headers	Controlled by the client, and sometimes trusted or logged by the server.
File uploads	Avatar or document upload	Files bring name, type and content, all controllable.
API calls	/api/orders returning JSON	Modern front ends rely on APIs that expose data directly.

Methods and responses

Take note of the HTTP method used by each request. GET normally reads, POST creates or submits, PUT and PATCH modify, DELETE removes. A feature that should only read data but accepts a DELETE is a finding in itself. Also note the status codes: 200 success, 301/302 redirection, 401 not authenticated, 403 forbidden, 404 not found, 500 server error. A 500 response often means the application did not expect your input, which is worth a closer look.

Reading what the site tells you

Applications leak useful information in many small ways. None of these needs any special skill, just attention.

• Page source and JavaScript files. Front-end code often reveals API paths, parameter names and comments left by developers. Open the browser’s developer tools and look in the network and sources panels.
• Response headers. The Server header or a framework-specific header may reveal the technology in use. Knowing the stack helps you decide which weaknesses to look for.
• Error messages. A detailed error page can reveal file paths, database engines or library names.
• Standard files. Many sites publish robots.txt, meant to guide search engines, and sitemap.xml. They can list paths that the owner would prefer not to be indexed, which makes them interesting for you to read. Remember that robots.txt is a request to crawlers, not an access control.
• Cookies. Their names often show the framework, and their attributes tell you about session handling, which we cover in chapter 2.

Technologies can be identified passively through headers, file names and page structure. Browser extensions and tools exist to do this, but your own eyes and the developer tools get you far.

Using Burp’s site map

As you browse, Burp fills the Target > Site map tree. Expand it to see hosts, directories and files. Items shown in grey were referenced by pages but not yet requested: they are leads. Filter the view to show only your in-scope target, and sort the HTTP history by status code or by method to spot unusual requests quickly.

Automated crawling can complement manual browsing, but it cannot understand business logic: it will not fill in a checkout the way a human would. Combine both, with manual exploration first.

Producing the inventory

The output of the mapping phase is a document in your notebook. A useful structure is one line per feature:

Feature: product search
URL: /search
Method: GET
Parameters: q (text), page (number)
Needs login: no
Notes: reflects the search term back in the page, to review in chapter 4

Notice the last line. During mapping you are not testing yet, but you start forming hypotheses. Reflecting user input in a page is a signal that tells you what to examine later. These notes will connect directly to chapters 3 to 6.

Roles and privileges

If the application has several roles (visitor, customer, administrator), repeat the exploration for each one you have an account for. Record which features each role can see. This role matrix is invaluable for testing access control in chapter 5.

Feature	Visitor	Customer	Admin
Browse products	Yes	Yes	Yes
View own orders	No	Yes	Yes
Manage users	No	No	Yes

Your turn: inventory your lab application

Using your lab application and Burp, explore at least five features as a normal user. Create an inventory entry for each one with URL, method, parameters, login requirement and one note. Then identify two entry points that are not visible form fields (for example a cookie or a path segment).

See a solution

For a shop application you might end up with entries such as: login (POST, two fields), search (GET, query parameter), product page (GET, numeric identifier in the path), basket (POST/PUT, product id and quantity), profile update (POST, several fields and possibly a hidden one).

Non-visible entry points: the session cookie sent with each request, the numeric identifier in the product path, the Referer header, and any JSON body sent by the front end to an API. The more of these you list, the more complete your later testing will be.

You now have a lab, a proxy and a map. Chapter 2 starts testing the front door of any application: authentication.