Web Application Security: Hands-On Practice (Chapter 13 from The Web Application Hacker’s Handbook)
Note: This write-up reflects my learning and hands-on practice based on the book The Web Application Hacker’s Handbook: Discovering and Exploiting Security Flaws by Dafydd Stuttard and Marcus Pinto.
Automating Bespoke Attacks:
This chapter focuses on using automation to improve custom web application attacks rather than introducing new vulnerabilities. Since every web application is different, attacks must be tailored and carefully planned. Manual attacks are slow and error-prone, so automation makes them faster and more efficient. The methodology combines human intelligence with computer-based brute force for stronger results.
Uses for Bespoke Automation:
Bespoke automation means creating custom automated tools to help attack a specific web application. There are three main ways this can be used:
1) Enumerating Identifiers (Finding Valid IDs)
Web applications use identifiers like usernames, account numbers, page numbers, or document IDs. Sometimes, to find useful data, you need to check many possible ID values to see which ones are valid.
For example, a website like:
https://wahh-app.com/app/showPage.jsp?PageNo=244197
uses a PageNo parameter to show content. If you want to find all valid page numbers, you would need to try thousands of numbers. Doing this manually is not practical, so automation helps cycle through all possible values quickly.
2) Harvesting Data (Collecting Large Amounts of Information)
Some vulnerabilities allow you to access sensitive information, such as user profiles. However, you may only be able to view one user’s data at a time. If there are thousands of users, manually collecting data would take too long. A custom automated attack can send many requests quickly and gather all the data efficiently.
For example, instead of just checking which page numbers are valid, automation could also extract useful details (like the page title) from each page to quickly find interesting content.
3) Web Application Fuzzing (Testing with Unexpected Inputs)
Fuzzing means sending unusual or malicious inputs (attack strings) to see how the application reacts. Large applications may have many pages and parameters to test. Manually testing each one is slow and tiring. With bespoke automation, you can automatically send thousands of different test inputs and quickly identify unusual responses that may indicate vulnerabilities.
Enumerating Valid Identifiers:
Enumerating valid identifiers means discovering which usernames, IDs, or session tokens exist in an application. This can be done by testing large numbers of possible values and observing the application’s responses. It helps attackers identify valid accounts or resources. Automation makes this process faster and more efficient.
Here are common situations where this happens:
1) Finding Valid Usernames
Some login pages give different error messages:
· “Username not found”
· “Incorrect password”
If the message changes depending on whether the username exists, an attacker can try many common usernames one by one. When the message changes to “Incorrect password,” they know the username is valid. This list of valid usernames can later be used for password guessing.
2) Finding Valid Resource IDs
Applications often use IDs for documents, accounts, employees, or logs. Sometimes, the application gives a response that shows whether an ID exists. By automatically trying many possible ID numbers (for example, from 1000 to 9999), an attacker can discover all valid resources in the system.
3) Predicting Session Tokens
Web applications create session tokens to identify logged-in users. If these tokens follow a predictable pattern, an attacker might guess or calculate other users’ tokens. To find valid ones, they may need to test many possible token values until one works.
The Basic Approach:
To enumerate valid identifiers, first find a request that contains the target ID and a response that changes clearly for valid vs. invalid values. Then send many automated requests with different ID values. By monitoring the responses for differences (“hits”), you can identify valid identifiers efficiently.
Detecting Hits:
There are numerous attributes of responses in which systematic variations may be detected, and which may therefore provide the basis for an automated attack:
1. HTTP Status code
2. Response Length
3. Response Body
4. Location Header
5. Set-Cookie Header
6. Time Delays
HTTP Status Code
Web servers send status codes with responses. These can change depending on the input:
· 200 → OK (normal response)
· 301 / 302 → Redirect to another page
· 401 / 403 → Not authorized / forbidden
· 404 → Not found
· 500 → Server error
If the status code changes when you send a certain value, that could indicate a valid identifier.
Response Length
Sometimes pages use a fixed template. If a valid ID is sent, the page contains real content (long response). If invalid, the page may be mostly empty (short response). Comparing response lengths is often a very reliable way to detect valid values.
Response Body (Page Content)
The actual content of the page may contain specific words or patterns.
Example:
· “Invalid document ID” → clearly invalid
· Normal document content → likely valid
Searching for certain keywords in the response is often very effective.
Location Header (Redirect Target)
If the server sends a redirect (302), the destination URL may differ:
· Valid input → /download.jsp
· Invalid input → /error.jsp
The redirect location can indicate whether the value is valid.
Set-Cookie Header
Sometimes the only difference is that the server sets a cookie.
Example:
· Valid login → sets a session token cookie
· Invalid login → no cookie
This small difference can reveal a hit.
Time Delays
Sometimes the response looks exactly the same, but the time taken is different.
For example:
· Invalid username → instant response
· Valid username → slight delay due to password checking
Get Aditya Kumar’s stories in your inbox
Join Medium for free to get updates from this writer.
If you can measure this delay, it can help identify valid identifiers.
Observing Scripting the Attack:
Browser:
Step1: (Goal: Testing Username Enumeration in PowerShell)
We scan see:
· 401 → invalid username
· 403 → valid username
· Slight delay for valid usernames
Now, automating it, for this we will create the wordlist:
Now, automating it:
Step2: (Goal: Document ID Enumeration)
Now, automating it:
Step3: (Goal: Detect via Response Length)
Valid IDs will have noticeably larger lengths.
Step4: (Goal: Extract Document Titles (Data Harvesting)
Step5: (Goal: Session Token Testing (Windows Version))
Login & save cookie
Access profile using saved cookie
Step6: (Goal: Token manipulation)
JAttack:
JAttack is a small Java program that automatically sends many HTTP requests to a website, changing some values each time.
Why?
Because sometimes web applications:
· Use numbers like DocID=3001
· And different numbers give access to different documents
This tool automates that process.
JAttack manually builds these HTTP requests and sends them.
Note: can’t present the JAttack code here.
Harvesting Useful Data:
What Is “Harvesting Useful Data”?
Harvesting data means: Automatically collecting a lot of information from a website by sending many requests.
Instead of manually clicking and copying data one by one, an attacker writes a small program (automation tool) that:
· Sends many requests
· Changes one value each time (like an ID number)
· Collects the responses
· Extracts useful information from them
This is called bespoke automation — meaning a custom-built script for a specific target.
Why Would This Work?
This usually works when:
Case 1: There is a vulnerability (a security flaw)
Case 2: The system works “as designed” — but badly designed
Why This Is Dangerous
This harvested data could be used for:
· Identity fraud
· Selling customer databases
· Social engineering attacks
· Password guessing
· Targeted phishing
If a website lets you access data by changing predictable IDs, you can write a custom script to automatically collect large amounts of sensitive data very quickly.
Fuzzing for Common Vulnerabilities:
What Is Fuzzing?
Fuzzing means: Sending strange, unexpected, or malicious inputs to a website to see how it reacts.
Instead of carefully targeting one parameter…
We:
· Take a list of attack strings.
· Send them into every parameter.
· Send them to every page.
· Then review all responses.
It’s like testing every door in a building to see which one opens
Contact Me
📧 Email: adii.utsav@gmail.com
🔗 LinkedIn: https://www.linkedin.com/in/aditya-kumar-3241b6286/
💻 GitHub: https://github.com/Rememberful
