Ethical Hacking

🛡️ Ethical Hacking — Day 12

Burp Suite Fundamentals: Proxy, HTTP History & Repeater

⚠️ LEARNING PURPOSE ONLY: This tutorial is strictly for educational and defensive cybersecurity learning. Use Burp Suite only with applications you own, deliberately vulnerable training applications, or systems for which you have explicit permission to test. Do not intercept or modify traffic from random websites, other people's accounts, or networks you don't control.

Welcome to Day 12.

Yesterday we learned how web applications communicate using:

HTTP/HTTPS
GET/POST
Headers
Cookies
Sessions
Authentication
Authorization
Parameters
APIs
Browser Developer Tools

Today we'll introduce one of the most important tools used in web application security:

🟠 Burp Suite

Burp Suite is a web security testing platform from PortSwigger. Its tools can be used to inspect and test HTTP(S) traffic in an authorized environment.

🎯 Day 12 Learning Objectives

Today you'll learn:

What Burp Suite is
Proxy concept
Browser → Burp → Server
Installing Burp Suite
Starting Burp
Burp Proxy
HTTP history
Intercept
Repeater
Request modification
Response analysis
Parameters
Headers
Cookies
Browser configuration
Linux setup
Windows setup
macOS setup
Safe local web-security lab

1. What Is Burp Suite?

Think of Burp Suite as a controlled inspection point between your browser and a web application.

Without Burp:

Browser
   │
   │ HTTP/HTTPS
   ▼
Web Server

With Burp:

Browser
   │
   │ HTTP/HTTPS
   ▼
┌──────────────┐
│ Burp Suite   │
│    Proxy     │
└──────┬───────┘
       │
       │ HTTP/HTTPS
       ▼
Web Server

This lets you inspect requests and responses in an authorized test environment.

2. Why Is Burp Useful?

Suppose your browser sends:

GET /products?id=25 HTTP/1.1
Host: lab.local

Burp lets you see the request clearly.

You can then understand:

Method
Path
Parameters
Headers
Cookies
Body
Response

This makes Burp extremely useful for learning web security.

3. Burp's Main Tools

Burp Suite contains several tools.

Today we'll focus on:

Proxy
   ↓
HTTP traffic interception

HTTP history
   ↓
Previously observed requests

Repeater
   ↓
Manually resend requests

Target
   ↓
Understand application scope/site structure

Later we'll explore additional features.

4. Installing Burp Suite

Use the official PortSwigger download page.

Official Burp Suite Download

There are different Burp Suite editions.

For learning, Burp Suite Community Edition is sufficient for many basic exercises.

🐧 Linux Installation

Download the Linux installer from the official PortSwigger site.

After installation, launch Burp Suite.

You can verify the application from your desktop application menu or launch it from the installation location.

If your installation provides the burpsuite command:

burpsuite

If that command isn't available, use the installed application launcher.

🪟 Windows Installation

Download the Windows installer from the official PortSwigger website.

Install it normally.

Then open:

Start Menu
   ↓
Burp Suite

🍎 macOS Installation

Download the macOS installer from the official PortSwigger website.

Install it and open:

Applications
   ↓
Burp Suite

On macOS, follow the application's prompts if additional permissions are requested.

5. Start Burp Suite

When Burp opens, you'll see options for creating/opening a project.

For learning:

Temporary Project

is sufficient.

Then choose the default configuration unless you have a specific reason to change it.

6. Burp Proxy

The Proxy is the most important feature for today's lesson.

Conceptually:

Browser
   │
   │ Request
   ▼
Burp Proxy
   │
   │ Request
   ▼
Application
   │
   │ Response
   ▼
Burp Proxy
   │
   │ Response
   ▼
Browser

7. Proxy Listener

Burp normally provides a local proxy listener.

A common default is:

127.0.0.1:8080

That means:

127.0.0.1

is your own computer.

And:

is the proxy port.

Important: Verify the actual listener shown in your Burp installation rather than assuming the default.

8. Check Burp's Proxy Listener

In Burp, go to:

Proxy
   ↓
Proxy settings
   ↓
Proxy listeners

You should see something similar to:

127.0.0.1:8080

If it is running:

Status: Running

9. Browser → Burp

Now your browser needs to send traffic through Burp.

The architecture becomes:

Browser
   │
   │ 127.0.0.1:8080
   ▼
Burp
   │
   ▼
Internet / Local Lab

For today's exercises, I strongly recommend using a separate browser profile or a dedicated browser for your lab.

This prevents your normal browsing traffic from accidentally being captured.

10. Why Use a Separate Browser Profile?

Suppose you configure your everyday browser to use Burp.

Then you visit:

Email
Banking
Social Media
Company applications

Those requests could appear in Burp.

That's unnecessary and potentially dangerous.

Instead:

Dedicated Lab Browser
        ↓
       Burp
        ↓
 Local Training Application

Keep your personal browsing separate.

11. Browser Proxy Configuration

You need to configure the browser to use:

Proxy host:
127.0.0.1

Proxy port:
8080

The exact UI differs between Chrome, Firefox, Edge, and Safari.

For security-training purposes, Firefox is often convenient because it provides its own proxy settings, rather than relying entirely on the operating-system proxy.

12. Firefox Lab Configuration

Open Firefox settings.

Find:

Settings
   ↓
Network Settings
   ↓
Configure Proxy

Select:

Manual proxy configuration

Enter:

HTTP Proxy:
127.0.0.1

Port:
8080

You may also need to configure HTTPS proxy behavior depending on your lab setup.

For a local HTTP-only training application, HTTPS certificate configuration isn't necessary.

13. Start With HTTP, Not HTTPS

This is important for beginners.

If your lab application is:

http://127.0.0.1:8080

you don't need to deal with TLS interception yet.

You can first learn:

HTTP
 ↓
Burp
 ↓
Request
 ↓
Response

Later we'll configure Burp's CA certificate for authorized HTTPS testing.

14. Build a Local Training Target

Before intercepting anything, we want a safe target.

Use:

127.0.0.1

and a deliberately vulnerable application.

Good training applications include:

OWASP Juice Shop
OWASP WebGoat
DVWA

For example:

Your Computer
     │
     ├── Browser
     │
     ├── Burp Suite
     │
     └── Training Application

Everything stays under your control.

15. Check for a Local Application

🐧 Linux

ss -tuln

🪟 Windows

netstat -ano

🍎 macOS

lsof -nP -iTCP -sTCP:LISTEN

Look for a service running on a local port.

For example:

127.0.0.1:8080

If nothing is running, that's fine.

We can install a training application later.

16. Test Burp With HTTP

Suppose your local application is available at:

http://127.0.0.1:8080

Configure your lab browser to use:

127.0.0.1:8080

as the proxy.

Then visit:

http://127.0.0.1:8080

The request should appear in Burp.

17. Intercept

Go to:

Proxy
   ↓
Intercept

You may see:

Intercept is ON

When interception is enabled, Burp pauses requests.

Conceptually:

Browser
   │
   │ Request
   ▼
Burp
   │
   │ ⏸ PAUSED
   │
   ▼
Application

18. Forward

Once you've inspected the request, Burp allows you to forward it.

Conceptually:

Browser
   ↓
Burp
   ↓
[Forward]
   ↓
Server

This is a core Burp workflow.

19. Drop

Burp can also discard a request.

Browser
   ↓
Burp
   ↓
[Drop]
   ✕
Server

This is useful for understanding how requests affect application behavior.

For today's lesson, only experiment with your local training application.

20. HTTP History

Turn interception off when you don't want every request paused.

Then use:

Proxy
   ↓
HTTP history

You'll see requests such as:

GET /
GET /css/style.css
GET /js/app.js
GET /favicon.ico
POST /login

This gives you an overview of the application's traffic.

21. Why HTTP History Matters

Suppose a web application has:

/login
/products
/profile
/api/users
/api/orders

HTTP history can help you understand how the browser communicates with those endpoints.

Think of it as:

A network diary for your authorized web application testing.

22. Inspect a Request

Click a request.

You may see:

GET /products?id=25 HTTP/1.1
Host: 127.0.0.1:8080
User-Agent: Mozilla/5.0
Accept: text/html

Now you can identify:

Method
Path
Host
Headers
Parameters

23. Inspect the Response

The response might look like:

HTTP/1.1 200 OK
Content-Type: text/html

<html>
...
</html>

Look for:

Status code
Headers
Cookies
Body

24. Request and Response

Remember:

REQUEST
Browser → Server

RESPONSE
Server → Browser

Burp lets you inspect both.

This is why understanding HTTP from Day 11 is essential.

25. Repeater

Now we reach one of Burp's most useful tools:

🔁 Repeater

Repeater lets you take an HTTP request and manually resend it.

Conceptually:

Browser
   ↓
Burp
   ↓
Request
   ↓
Repeater
   ↓
Modify
   ↓
Send
   ↓
Response

This is extremely useful for understanding how an application responds to different inputs.

26. Sending a Request to Repeater

In Burp HTTP history:

Select a request.
Right-click it.
Choose the option to send it to Repeater.
Open the Repeater tab.

You'll see the request.

27. Example Repeater Request

Suppose you have:

GET /products?id=25 HTTP/1.1
Host: 127.0.0.1:8080

You could change:

id=25

to another valid test value in your own lab:

id=26

Then click:

Send

Observe the response.

This is a safe way to learn how parameters affect application behavior.

28. Compare Responses

Suppose:

Request 1:
id=25

Response:
200 OK

Then:

Request 2:
id=26

Response:
200 OK

You can compare:

Status
Length
Headers
Body

This is the beginning of structured web application testing.

29. Don't Start With Exploit Payloads

At this stage, don't immediately try:

SQL injection
XSS
Command injection
Path traversal

First learn:

Normal request
       ↓
Normal response
       ↓
Change one input
       ↓
Observe
       ↓
Understand

This makes later vulnerability testing much easier.

30. Parameters in Repeater

Parameters can appear in:

URL

?id=25

Form body

username=student

JSON

{
  "id": 25
}

Headers

X-Test: example

Cookies

Cookie: lab_session=example

For your own lab, you can modify one parameter at a time and observe the result.

31. Request Modification Exercise

Use your local training application.

Suppose the request is:

GET /products?id=1 HTTP/1.1
Host: 127.0.0.1:8080

Send it to Repeater.

Change:

id=1

to:

id=2

Send.

Then change it to:

id=3

Send again.

Record:

Parameter	Status	Response Length	Observation
`id=1`	___	___	___
`id=2`	___	___	___
`id=3`	___	___	___

This teaches you how controlled input changes can affect an application.

32. Headers in Repeater

You can also inspect headers:

User-Agent: Mozilla/5.0
Accept: text/html

For your local lab, you can change a harmless header:

X-Lab-Test: Day12

Send the request.

Then observe whether the server:

Ignores it
Reflects it
Logs it
Returns it
Rejects it

This is a good introduction to HTTP header behavior.

33. Cookies in Burp

You may see:

Cookie: session=...

Treat real cookies as credentials.

For the lab, use only training session values.

Never copy real cookies into:

Screenshots
GitHub
Blog posts
Chat messages
Public documentation

34. Burp Scope

One of the most important habits is defining scope.

Burp lets you work with a target scope.

Conceptually:

IN SCOPE
│
└── 127.0.0.1
      └── Training Application

OUT OF SCOPE
│
├── Personal websites
├── Banking
├── Email
├── Social media
└── Other users' applications

Always keep your testing target clearly defined.

35. Why Scope Matters

Imagine your browser sends:

Google
Email
Cloud services
Social media
Local application

If Burp captures everything, you may unintentionally collect sensitive traffic.

Therefore:

Use a dedicated browser profile and local lab whenever possible.

36. Burp and HTTPS

HTTPS introduces an additional concept.

Your browser normally verifies the server's TLS certificate.

Burp, when configured as an authorized interception proxy, acts between the browser and server.

Conceptually:

Browser
   │
   │ TLS
   ▼
Burp
   │
   │ TLS
   ▼
Server

To inspect HTTPS traffic in a lab, the browser needs to trust Burp's local CA certificate.

We'll cover this carefully in the next lessons.

⚠️ Never Disable TLS Verification Globally

You may encounter tutorials telling you to:

"Disable certificate verification."

Don't make this a normal practice.

For a controlled lab, install and trust the Burp CA certificate only in the dedicated lab browser/profile.

Do not weaken security settings in your normal browsing environment.

37. Linux Practical Session

Check Burp

Launch Burp Suite.

Then:

curl http://127.0.0.1:8080/

If your training application is listening on port 8080, note that this command targets the application directly unless you explicitly configure curl to use Burp as a proxy.

To send HTTP traffic through a local Burp proxy, the conceptual command is:

curl -x http://127.0.0.1:8080 http://YOUR-LAB-HOST/

Use this only with your local training application.

38. Windows Practical Session

Check local services:

netstat -ano

Then, if your local training application is running:

curl.exe http://127.0.0.1:8080/

To explicitly use Burp as the proxy:

curl.exe -x http://127.0.0.1:8080 http://YOUR-LAB-HOST/

Again, replace YOUR-LAB-HOST only with your authorized local training target.

39. macOS Practical Session

Check listening services:

lsof -nP -iTCP -sTCP:LISTEN

Test the local application:

curl http://127.0.0.1:8080/

Send traffic through Burp:

curl -x http://127.0.0.1:8080 http://YOUR-LAB-HOST/

40. A Note About Port Conflicts

A common beginner mistake is:

Burp → 127.0.0.1:8080
Application → 127.0.0.1:8080

Both cannot normally listen on the same IP/port combination.

You might instead use:

Burp:
127.0.0.1:8080

Training App:
127.0.0.1:3000

Then:

Browser
   │
   │ Proxy → :8080
   ▼
Burp
   │
   ▼
Training App → :3000

The exact ports can be different.

🧪 Day 12 Main Lab

Objective

Intercept and modify your own local web application's request.

Step 1

Start your local training application.

For example:

http://127.0.0.1:3000

Step 2

Start Burp Suite.

Verify the proxy listener.

Example:

127.0.0.1:8080

Step 3

Use a dedicated browser profile.

Configure:

Proxy:
127.0.0.1

Port:
8080

Step 4

Visit:

http://127.0.0.1:3000

Step 5

Turn:

Proxy → Intercept → ON

Step 6

Reload the page.

You should see a request similar to:

GET / HTTP/1.1
Host: 127.0.0.1:3000

Step 7

Inspect:

Method
Path
Host
Headers

Step 8

Click:

Forward

Step 9

Turn interception off.

Go to:

Proxy → HTTP history

Step 10

Find your request.

Send it to:

Repeater

Step 11

Modify a harmless value.

For example:

X-Lab-Test: Day12

Step 12

Send the request.

Compare:

Original Response
        vs
Modified Response

📊 Day 12 Lab Report

Create:

Item	Result
Training application	______
Local URL	______
Burp proxy	______
HTTP method	______
Endpoint	______
Status code	______
Request headers	______
Response headers	______
Parameter tested	______
Modified value	______
Response difference	______

Never include actual passwords, authentication tokens, session cookies, or API keys.

🧪 Practical Exercise — Request Lifecycle

Draw this diagram yourself:

┌───────────┐
│  Browser  │
└─────┬─────┘
      │
      │ HTTP Request
      ▼
┌───────────┐
│    Burp   │
│   Proxy   │
└─────┬─────┘
      │
      │ Forward
      ▼
┌───────────┐
│   Local   │
│ Training  │
│    App    │
└─────┬─────┘
      │
      │ HTTP Response
      ▼
┌───────────┐
│    Burp   │
└─────┬─────┘
      │
      ▼
┌───────────┐
│  Browser  │
└───────────┘

This diagram is worth remembering.

🔬 Burp vs Developer Tools

You learned Developer Tools yesterday.

Now compare them.

Feature	Browser DevTools	Burp Suite
View requests	✅	✅
View responses	✅	✅
View headers	✅	✅
View cookies	✅	✅
Intercept requests	Limited	✅
Modify requests	Limited	✅
Re-send requests	Limited	✅
Repeater	❌	✅
Security testing workflow	Basic	Advanced

Developer Tools are excellent for understanding browser behavior.

Burp provides a dedicated platform for controlled security testing.

🧠 Security Mindset

When you see:

GET /profile?id=25

don't immediately think:

"How do I exploit this?"

Instead ask:

What does id mean?
       ↓
Who is allowed to access id=25?
       ↓
Does authentication matter?
       ↓
Does authorization matter?
       ↓
Does changing the value change access?
       ↓
What should the secure behavior be?

This leads naturally into access-control testing, which we'll study later.

📝 Day 12 Assignment

Answer these questions:

1.

What is Burp Suite?

2.

What is a proxy?

3.

What is Burp Proxy used for?

4.

What is HTTP history?

5.

What does Intercept do?

6.

What does Forward do?

7.

What does Drop do?

8.

What is Repeater?

9.

Why is Repeater useful?

10.

What is the difference between Browser Developer Tools and Burp Suite?

11.

Why should you use a dedicated browser profile for security testing?

12.

Why should you never publish session cookies?

13.

Why should HTTPS certificate trust be configured only for your controlled lab?

14.

Why is scope important?

15.

Why should you modify only one parameter at a time during controlled testing?

🏆 Day 12 Challenge

Complete:

START
  ↓
Burp Suite
  ↓
Configure Proxy
  ↓
Dedicated Browser
  ↓
Local Training App
  ↓
Intercept Request
  ↓
Inspect Request
  ↓
Forward
  ↓
HTTP History
  ↓
Send to Repeater
  ↓
Change ONE harmless value
  ↓
Send
  ↓
Compare Response
  ↓
Document
  ↓
STOP

Then write:

"I intercepted an authorized request from ______. The request used ______. I changed ______ and observed ______ in the response."

⚠️ Ethical Hacking Reminder

LEARNING PURPOSE ONLY: Burp Suite can intercept credentials, cookies, tokens, private messages, and other sensitive information. Use it only with your own applications, your own accounts, deliberately vulnerable labs, or systems for which you have explicit written permission.

Never configure Burp to capture your normal banking, email, social-media, or other private browsing traffic for practice.

Permission → Scope → Intercept → Analyze → Test → Document → Secure

✅ Day 12 Summary

Today you learned:

Burp Suite
Proxy
Proxy listener
Browser configuration
Intercept
Forward
Drop
HTTP history
Request inspection
Response inspection
Repeater
Request modification
Headers
Parameters
Cookies
Scope
HTTPS interception concepts
Linux practical commands
Windows PowerShell practical commands
macOS practical commands
Safe local web-security lab

🔑 Most Important Lesson

Burp Suite is not about randomly changing requests. It's about understanding how an application communicates and verifying whether the application behaves securely under controlled, authorized testing.

🔜 Day 13 — Burp Suite Deep Dive: Requests, Responses & Parameters

Tomorrow we'll go deeper into:

Request anatomy
Response anatomy
Query parameters
Form parameters
JSON parameters
Cookies
Headers
Repeater
Comparing responses
URL encoding
Basic input validation
Safe parameter manipulation
Linux, Windows & macOS practical exercises
Building a structured web-security testing workflow

🔐 LEARN → INTERCEPT → ANALYZE → TEST SAFELY → UNDERSTAND → SECURE.

Author Description

Author Social Links

Post Page Advertisement [Top]

Ethical Hacking Burp Suite Fundamentals: Proxy, HTTP History & Repeater | Day 12

🛡️ Ethical Hacking — Day 12

Burp Suite Fundamentals: Proxy, HTTP History & Repeater

🟠 Burp Suite

🎯 Day 12 Learning Objectives

1. What Is Burp Suite?

2. Why Is Burp Useful?

3. Burp's Main Tools

4. Installing Burp Suite

🐧 Linux Installation

🪟 Windows Installation

🍎 macOS Installation

5. Start Burp Suite

6. Burp Proxy

7. Proxy Listener

8. Check Burp's Proxy Listener

9. Browser → Burp

10. Why Use a Separate Browser Profile?

11. Browser Proxy Configuration

12. Firefox Lab Configuration

13. Start With HTTP, Not HTTPS

14. Build a Local Training Target

15. Check for a Local Application

🐧 Linux

🪟 Windows

🍎 macOS

16. Test Burp With HTTP

17. Intercept

18. Forward

19. Drop

20. HTTP History

21. Why HTTP History Matters

22. Inspect a Request

23. Inspect the Response

24. Request and Response

25. Repeater

🔁 Repeater

26. Sending a Request to Repeater

27. Example Repeater Request

28. Compare Responses

29. Don't Start With Exploit Payloads

30. Parameters in Repeater

URL

Form body

JSON

Headers

Cookies

31. Request Modification Exercise

32. Headers in Repeater

33. Cookies in Burp

34. Burp Scope

35. Why Scope Matters

36. Burp and HTTPS

⚠️ Never Disable TLS Verification Globally

37. Linux Practical Session

Check Burp

38. Windows Practical Session

39. macOS Practical Session

40. A Note About Port Conflicts

🧪 Day 12 Main Lab

Objective

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Step 11

Step 12

📊 Day 12 Lab Report

🧪 Practical Exercise — Request Lifecycle

🔬 Burp vs Developer Tools

🧠 Security Mindset