 |
| Ethical Hacking |
🛡️ Ethical Hacking — Day 13
Burp Suite Deep Dive: Requests, Responses, Parameters & Repeater
⚠️ LEARNING PURPOSE ONLY: This tutorial is strictly for educational and defensive cybersecurity learning. Perform practical exercises only against applications you own, deliberately vulnerable training applications, or systems for which you have explicit permission to test. Never test random public websites, accounts, APIs, or infrastructure.
Welcome to Day 13.
Yesterday you learned the basic Burp Suite workflow:
Browser
↓
Burp Proxy
↓
Training Application
Today we're going deeper into HTTP request/response analysis.
The goal is not to blindly modify requests. The goal is to understand:
What data does the application receive, how does it process that data, and what does it return?
🎯 Today's Learning Objectives
By the end of Day 13, you'll understand:
HTTP request anatomy
HTTP response anatomy
Query parameters
Form parameters
JSON parameters
HTTP headers
Cookies
URL encoding
Repeater
Comparing responses
Request modification
Basic input validation
API requests
Browser → Burp → Application workflow
Practical exercises on Linux, Windows and macOS
1. HTTP Request Anatomy
Consider:
GET /products?id=25 HTTP/1.1
Host: 127.0.0.1:3000
User-Agent: Mozilla/5.0
Accept: text/html
Break it down:
GET
↓
HTTP Method
/products?id=25
↓
Path + Query Parameter
HTTP/1.1
↓
HTTP Version
Host
↓
Target host
User-Agent
↓
Client information
Accept
↓
Accepted response type
2. The Four Main Parts of a Request
A request can be thought of as:
┌──────────────────────────────┐
│ Request Line │
├──────────────────────────────┤
│ Headers │
├──────────────────────────────┤
│ Blank Line │
├──────────────────────────────┤
│ Optional Body │
└──────────────────────────────┘
For example:
POST /login HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/x-www-form-urlencoded
username=student&password=example
3. Request Line
The first line contains:
METHOD PATH VERSION
Example:
GET /products HTTP/1.1
So:
Method = GET
Path = /products
Version = HTTP/1.1
4. Query Parameters
Example:
/products?id=25
Here:
id=25
is a query parameter.
Multiple parameters can appear:
/products?id=25&category=books
Conceptually:
/products
│
├── id=25
│
└── category=books
🧪 Practical Lab 1 — Query Parameters
Use your local training application.
Suppose it has:
http://127.0.0.1:3000/products?id=1
Open it through your dedicated lab browser.
In Burp:
Proxy
↓
HTTP history
Find the request.
Send it to:
Repeater
Change only:
id=1
to:
id=2
Click:
Send
Record:
| Request | Status | Length | Result |
|---|---|---|---|
id=1 | ___ | ___ | ___ |
id=2 | ___ | ___ | ___ |
This is controlled parameter analysis.
5. Multiple Parameters
Suppose:
/products?id=25&sort=price
There are two parameters:
id = 25
sort = price
Change only one:
/products?id=26&sort=price
Then compare the response.
This teaches an important testing principle:
Change one variable at a time.
6. Why Change One Variable?
Suppose you change:
id
sort
category
page
all at once.
If the response changes, you don't know which input caused it.
Instead:
Original
↓
Change ID
↓
Observe
↓
Restore
↓
Change sort
↓
Observe
This produces much better evidence.
7. POST Parameters
POST requests commonly contain data in the body.
Example:
POST /login HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/x-www-form-urlencoded
username=student&password=example
The body contains:
username=student
password=example
8. JSON Parameters
Modern APIs frequently use JSON.
Example:
POST /api/products HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/json
{
"name": "Laptop",
"price": 50000
}
Parameters:
name
price
9. Form vs JSON
Form
username=student&password=example
JSON
{
"username": "student",
"password": "example"
}
Both can carry application input.
The server determines how that input is processed.
🧪 Practical Lab 2 — JSON
If your local training application provides an API endpoint that accepts JSON, send a legitimate request through Burp Repeater.
For example:
POST /api/test HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/json
{
"name": "Day13",
"value": "learning"
}
Send it only if that endpoint exists in your local lab.
Observe:
Status
Response headers
Response body
Do not invent requests against public APIs.
10. HTTP Response Anatomy
A response might look like:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 52
{
"status": "success"
}
The response contains:
Status line
Headers
Blank line
Body
11. Status Line
Example:
HTTP/1.1 200 OK
Breakdown:
HTTP/1.1
↓
Version
200
↓
Status Code
OK
↓
Reason phrase
12. Response Headers
Examples:
Content-Type: application/json
Content-Length: 52
Cache-Control: no-cache
Set-Cookie: ...
These provide information about the response.
13. Response Body
The body might contain:
HTML
<html>
<body>
<h1>Hello</h1>
</body>
</html>
JSON
{
"id": 10,
"name": "Student"
}
Plain text
Operation successful
14. Compare Request vs Response
Always think:
REQUEST
What did I send?
↓
SERVER
↓
RESPONSE
What did I receive?
This is the foundation of Burp-based testing.
15. URL Encoding
Some characters have special meanings in URLs.
For example:
space
may be encoded as:
%20
And:
&
has a special meaning for separating parameters.
Example:
/search?q=hello%20world
means approximately:
q = hello world
16. Why Encoding Matters
Suppose an application receives:
/search?q=hello%20world
The server may decode it before processing.
Conceptually:
Encoded Input
↓
URL Decoder
↓
Application
Security testing often requires understanding exactly when and how input is decoded.
17. Common Encoded Characters
| Character | Encoding |
|---|---|
| Space | %20 |
? | %3F |
& | %26 |
= | %3D |
/ | %2F |
# | %23 |
You don't need to memorize all of them.
Burp can help you inspect and manipulate encoded values.
18. Cookies
A request may contain:
Cookie: session=example-session
The cookie can identify a browser session.
Burp lets you see cookies in requests.
But remember:
A real session cookie should be treated like a credential.
For your lab, use only lab-generated cookies.
19. Cookie Attributes
A server might send:
Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax
Here:
Secure
HttpOnly
SameSite
are security-related attributes.
20. Authentication
An authenticated request may contain:
Cookie: session=LAB_SESSION
or:
Authorization: Bearer LAB_TOKEN
For learning, use dummy or training credentials/tokens.
Never copy production tokens into your notes.
21. Authorization
Suppose a lab application has:
GET /profile/10
The security question is not simply:
"Does this URL work?"
Instead:
"Should the currently authenticated user be allowed to access profile 10?"
This is an authorization question.
We'll study authorization testing in much greater depth later.
22. Repeater Workflow
Remember this workflow:
HTTP History
↓
Select Request
↓
Send to Repeater
↓
Inspect
↓
Change ONE value
↓
Send
↓
Observe
↓
Compare
↓
Document
23. Repeater Example
Original:
GET /products?id=1 HTTP/1.1
Host: 127.0.0.1:3000
Modified:
GET /products?id=2 HTTP/1.1
Host: 127.0.0.1:3000
Observe:
Status:
Length:
Response:
Then return to:
id=1
This gives you a baseline.
24. Baseline
A baseline is the normal behavior you compare other results against.
For example:
Baseline:
id=1
200 OK
Product 1 returned
Then:
Test:
id=2
200 OK
Product 2 returned
Now you understand normal parameter behavior.
25. Invalid Input
You can safely test ordinary invalid input in your own lab.
For example:
id=abc
instead of:
id=1
Observe whether the application returns:
400 Bad Request
or:
404 Not Found
or another response.
This is basic input validation testing.
26. Boundary Testing
Another useful technique is testing reasonable boundary values.
For example, if your local application expects:
page=1
try:
page=0
or:
page=100
only within your lab.
You're asking:
How does the application behave at the edges of its expected input?
27. Don't Confuse Errors With Vulnerabilities
Suppose:
id=abc
produces:
500 Internal Server Error
That is worth investigating in your authorized lab.
But:
An error does not automatically mean you've found a vulnerability.
You need to understand:
Why it happened
Whether sensitive information was exposed
Whether it affects security
Whether it is reproducible
How it should be fixed
28. Information Disclosure
Suppose an error response contains:
Database connection failed
Internal server path: /var/www/app/...
Framework version: ...
That may reveal unnecessary internal information.
This is an example of potentially useful security evidence.
Again:
Don't deliberately trigger errors on systems you aren't authorized to test.
29. Comparing Responses
When testing a parameter, compare:
Status
200
400
403
404
500
Length
1234 bytes
1450 bytes
Headers
Content-Type
Set-Cookie
Location
Body
Different content?
Error?
Normal response?
30. A Simple Comparison Table
| Test | Status | Length | Response Difference |
|---|---|---|---|
| Baseline | 200 | 1200 | Normal |
id=2 | 200 | 1210 | Different product |
id=abc | 400 | 350 | Validation error |
id=999999 | 404 | 280 | Not found |
This is much more useful than simply saying:
"It worked."
31. HTTP Headers Exercise
In your local lab, take a request and inspect:
Host:
User-Agent:
Accept:
Content-Type:
Cookie:
For the response:
Content-Type:
Cache-Control:
Set-Cookie:
Location:
Record what each field does.
32. Custom Header Experiment
In Repeater, add a harmless test header:
X-Lab-Day: 13
For example:
GET / HTTP/1.1
Host: 127.0.0.1:3000
X-Lab-Day: 13
Send it.
Then observe the response.
The application may ignore it.
That's perfectly fine.
The purpose is learning how HTTP headers travel.
33. API Request Analysis
If your local lab has an API, find a request such as:
GET /api/products
or:
POST /api/products
Inspect:
Method
Endpoint
Headers
Content-Type
Body
Response
Create:
API Endpoint:
________________
Method:
________________
Request format:
________________
Response format:
________________
34. Browser Developer Tools + Burp
Use both tools together.
Browser
│
├── Developer Tools
│ ↓
│ Observe browser behavior
│
▼
Burp
│
├── Proxy
├── HTTP History
└── Repeater
│
▼
Application
Developer Tools show what the browser is doing.
Burp gives you a more controlled security-testing workflow.
🐧 35. Linux Practical Session
Check curl:
curl --version
Test your local application:
curl http://127.0.0.1:3000/
Send headers:
curl -H "X-Lab-Day: 13" http://127.0.0.1:3000/
Send a query:
curl "http://127.0.0.1:3000/products?id=1"
Use verbose mode:
curl -v "http://127.0.0.1:3000/products?id=1"
Use these only with your local training application.
🪟 36. Windows Practical Session
Check:
curl.exe --version
Test:
curl.exe http://127.0.0.1:3000/
Query parameter:
curl.exe "http://127.0.0.1:3000/products?id=1"
Custom header:
curl.exe -H "X-Lab-Day: 13" http://127.0.0.1:3000/
Verbose:
curl.exe -v "http://127.0.0.1:3000/products?id=1"
🍎 37. macOS Practical Session
Check:
curl --version
Request:
curl http://127.0.0.1:3000/
Query:
curl "http://127.0.0.1:3000/products?id=1"
Custom header:
curl -H "X-Lab-Day: 13" http://127.0.0.1:3000/
Verbose:
curl -v "http://127.0.0.1:3000/products?id=1"
38. Using curl Through Burp
If Burp is listening on:
127.0.0.1:8080
and your training application is:
127.0.0.1:3000
Linux/macOS
curl -x http://127.0.0.1:8080 http://127.0.0.1:3000/
Windows
curl.exe -x http://127.0.0.1:8080 http://127.0.0.1:3000/
The flow becomes:
curl
↓
Burp :8080
↓
Lab App :3000
This is a useful alternative to configuring a browser.
🧪 Day 13 Main Practical Lab
Objective
Analyze and modify a request without exploiting anything.
Step 1
Start your deliberately vulnerable/local training application.
Example:
http://127.0.0.1:3000
Step 2
Start Burp.
Verify:
127.0.0.1:8080
or whatever listener your Burp installation actually uses.
Step 3
Send traffic through Burp.
Use your dedicated browser or:
curl -x http://127.0.0.1:8080 http://127.0.0.1:3000/
Step 4
Open:
Proxy → HTTP history
Step 5
Select a request.
Identify:
Method:
Path:
Query:
Headers:
Cookies:
Body:
Step 6
Send to:
Repeater
Step 7
Create a baseline.
Send the original request.
Record:
Status:
Length:
Content-Type:
Step 8
Modify one harmless parameter.
For example:
id=1
to:
id=2
Step 9
Send again.
Record:
Status:
Length:
Difference:
Step 10
Try a normal invalid value:
id=abc
Only if that parameter is appropriate for your local lab.
Record the result.
📊 Day 13 Lab Report
Fill this in:
Target:
127.0.0.1:_____
Request:
____________________
Method:
____________________
Endpoint:
____________________
Parameter:
____________________
Baseline Status:
____________________
Baseline Length:
____________________
Modified Input:
____________________
Modified Status:
____________________
Modified Length:
____________________
Observed Difference:
____________________
🧠 Day 13 Security Mindset
When you see:
GET /user?id=10
ask:
What is id?
↓
What does the server do with it?
↓
What type of value is expected?
↓
What happens with another valid value?
↓
What happens with invalid input?
↓
Does authorization affect the result?
↓
Is sensitive information exposed?
This is the foundation of structured web application testing.
📝 Day 13 Assignment
Answer these:
1.
What are the main parts of an HTTP request?
2.
What are the main parts of an HTTP response?
3.
What is a query parameter?
4.
What is a POST body?
5.
What is JSON?
6.
What is URL encoding?
7.
Why is a session cookie sensitive?
8.
What is a baseline response?
9.
Why should you change only one parameter at a time?
10.
Does a 500 response automatically prove a vulnerability? Why or why not?
11.
What is the purpose of Burp Repeater?
12.
What is the difference between authentication and authorization?
13.
Why should security testing use an authorized lab?
14.
What information should never be included in a public Burp screenshot?
15.
Why is response comparison useful?
🏆 Day 13 Challenge
Complete this workflow:
LOCAL LAB
│
▼
Browser/curl
│
▼
Burp Proxy
│
▼
HTTP History
│
▼
Request
│
▼
Repeater
│
┌─────┴─────┐
▼ ▼
Original Modified
Request Request
│ │
▼ ▼
Original Modified
Response Response
│ │
└─────┬─────┘
▼
Comparison
│
▼
Documentation
Then write a short conclusion:
"I tested the parameter ______ in my authorized local lab. The baseline response was ______. After changing the parameter to ______, the application returned ______. This taught me ______."
⚠️ Ethical Hacking Reminder
LEARNING PURPOSE ONLY: Burp Suite can expose passwords, session cookies, authorization tokens, API keys, personal information, and private application data. Use it only with your own systems, deliberately vulnerable labs, or explicitly authorized targets.
Never use these techniques to test random websites.
Permission → Scope → Observe → Modify Carefully → Compare → Document → Secure
✅ Day 13 Summary
Today you learned:
HTTP request anatomy
HTTP response anatomy
Query parameters
POST parameters
JSON
Headers
Cookies
Sessions
URL encoding
Baselines
Invalid input
Boundary testing
Response comparison
Burp Repeater
API request analysis
Browser DevTools + Burp
curlon LinuxPowerShell/
curl.exeon Windowscurlon macOSSending curl traffic through Burp
Structured web-security testing
🔑 Most Important Lesson
Good security testing starts with understanding normal behavior. Establish a baseline first, change one thing at a time, observe the result, and document what you can actually prove.
🔜 Day 14 — Burp Suite + OWASP Juice Shop Lab
Tomorrow we'll connect everything you've learned into a controlled local web-security lab using a deliberately vulnerable application.
We'll cover:
Setting up OWASP Juice Shop locally
Docker-based setup
Browser → Burp → Juice Shop
HTTP/HTTPS traffic
HTTP History
Repeater
Parameters
Authentication concepts
Safe reconnaissance of your local lab
First vulnerability-analysis exercise
Linux, Windows & macOS commands
How to keep the entire lab isolated from real websites
🔐 LEARN → BUILD A LAB → INTERCEPT → ANALYZE → TEST → UNDERSTAND → SECURE.
No comments:
Post a Comment