Lab 03 — Web Application Penetration Testing

Mission: You are assessing an intentionally vulnerable web application in an isolated lab. Your job is to understand how the application works, map its attack surface, identify weaknesses, validate selected issues safely, and document findings without performing destructive testing.

Mission Information

Item	Details
Certification	CompTIA PenTest+
Difficulty	Intermediate
Estimated Time	3–4 hours
Primary Skills	Web enumeration, HTTP analysis, authentication testing, input validation
Attacker System	Kali Linux
Target Application	OWASP Juice Shop, DVWA, WebGoat, or similar intentionally vulnerable application
Primary Tools	Browser, Burp Suite Community, curl, Nmap
Input	Labs 01–02 findings
Output	Web Application Penetration Test Report

Learning Objectives

By the end of this lab, you should be able to:

• identify a web application’s attack surface;

• understand HTTP requests and responses;

• intercept traffic using Burp Suite;

• identify parameters, cookies, tokens, and headers;

• map application functionality;

• evaluate authentication behavior;

• evaluate session management;

• identify input-validation weaknesses;

• safely validate SQL injection;

• safely validate cross-site scripting;

• recognize directory traversal and file-related weaknesses;

• identify information disclosure;

• distinguish vulnerability discovery from impact validation;

• collect evidence suitable for professional reporting;

• recommend remediation.

1. Scenario

Your organization has completed initial reconnaissance and vulnerability scanning.

The target web application has now been approved for focused application-layer testing.

Example scope:

Authorized Application:
http://192.168.56.110

Permitted:
- Application mapping
- HTTP interception
- Parameter manipulation
- Authentication testing
- Session analysis
- Input validation testing
- Non-destructive vulnerability validation
- Testing intentionally vulnerable functionality

Not Permitted:
- Denial of service
- Destructive data modification
- Persistent compromise
- Testing systems outside the lab

Use only an intentionally vulnerable application that you control.

2. Recommended Lab Environment

A simple architecture is sufficient:

              Isolated Lab Network
                     |
             +-------+-------+
             |               |
      +-------------+   +-------------+
      | Kali Linux  |   | Vulnerable  |
      | Tester      |   | Web App     |
      +-------------+   +-------------+
             |               |
             +-------HTTP----+

Recommended applications:

• OWASP Juice Shop

• DVWA

• OWASP WebGoat

For a PenTest+ lab, DVWA or Juice Shop works very well because both expose common web vulnerability classes.

3. Prepare the Workspace

Create a directory:

mkdir -p ~/pentest-lab/web-app
cd ~/pentest-lab/web-app

Create notes:

nano web-assessment-notes.md

Use:

# Web Application Assessment Notes

## Target

URL:
IP:
Application:

## Scope

Authorized Functions:
Restricted Actions:

## Technology Stack

Web Server:
Framework:
Language:
Database:
Authentication:

## Endpoints

## Parameters

## Cookies

## Authentication Findings

## Session Findings

## Input Validation Findings

## Confirmed Vulnerabilities

## Evidence

4. Phase 1 — Confirm Web Services

Begin by validating the exposed application service.

Run:

nmap -sV -p 80,443,3000,8080 192.168.56.110

Use the actual application port.

You may identify:

80/tcp     HTTP
443/tcp    HTTPS
3000/tcp   Node.js application
8080/tcp   Alternate HTTP

Record:

Port	Protocol	Service	Product	Version

5. Inspect HTTP Headers

Use:

curl -I http://192.168.56.110

Look for:

Server
Content-Type
Set-Cookie
Location
X-Powered-By
Content-Security-Policy
Strict-Transport-Security

Do not assume a header value is always accurate.

Headers are useful clues.

Record:

Server:
Framework Indicators:
Security Headers:
Cookies:
Redirects:

6. Understand the HTTP Request

A basic request may look like:

GET /login HTTP/1.1
Host: 192.168.56.110
User-Agent: Mozilla/5.0
Cookie: session=...

Important components:

Method
Path
Headers
Cookies
Parameters
Body

A response might contain:

HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: session=abc123

For PenTest+, understand common methods:

GET
POST
PUT
PATCH
DELETE
OPTIONS
HEAD

7. Phase 2 — Configure Burp Suite

Launch:

burpsuite

Use Burp’s built-in browser where possible.

This avoids manually configuring your browser proxy.

Navigate to:

Proxy
→ Intercept
→ Open Browser

Visit your vulnerable application.

Burp now sits between:

Browser
   ↓
Burp Proxy
   ↓
Web Application

8. Intercept Your First Request

Enable:

Intercept is ON

Refresh the application.

You should see something similar to:

GET / HTTP/1.1
Host: 192.168.56.110
User-Agent: Mozilla/5.0
Accept: text/html

Identify:

Method:
Path:
Host:
Parameters:
Cookies:
Headers:

Click:

Forward

until the page loads.

9. Burp HTTP History

Go to:

Proxy
→ HTTP history

This provides a record of application traffic.

Look for endpoints such as:

/login
/register
/account
/api
/search
/profile
/admin

Create an endpoint inventory:

Endpoint	Method	Authentication	Parameters	Notes
/login	POST	No	username, password	Authentication
/profile	GET	Yes	—	User data
/search	GET	No	q	Input handling

10. Phase 3 — Map the Application

Browse every visible application function.

Visit:

Home
Login
Register
Search
Profile
Password Reset
Account
Uploads
Administration
API functions

Do not immediately attack inputs.

First understand the application.

Think:

Application
    ↓
Pages
    ↓
Functions
    ↓
Endpoints
    ↓
Parameters
    ↓
Trust Boundaries

11. Identify Input Points

Common input points include:

Login forms
Search fields
Registration forms
URL parameters
Cookies
HTTP headers
JSON fields
File uploads
API parameters
Hidden fields

Examples:

/search?q=test

/product?id=10

/profile?user=5

Record all discovered inputs.

12. Phase 4 — Test Client-Side vs Server-Side Validation

Suppose a form requires a specific value.

Browser validation may prevent certain input.

Inspect the request using Burp and modify it after the browser has accepted the form.

This demonstrates a critical concept:

Client-Side Validation
        ≠
Security Control

Security decisions must be enforced server-side.

13. Phase 5 — Authentication Testing

Identify the application’s login endpoint.

Example:

POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded

username=user@example.com&password=password123

Analyze:

Does the application use HTTPS?

Does it reveal whether a username exists?

Does it provide different error messages?

Does login create a session cookie?

Does logout invalidate the session?

Avoid high-volume password attacks unless the lab explicitly requires them.

14. Authentication Error Analysis

Try two invalid scenarios manually.

Example:

Known username + wrong password

Unknown username + wrong password

Compare responses.

If the application says:

User does not exist

for one case, but:

Incorrect password

for another, it may enable username enumeration.

Record this as a potential information-disclosure issue.

15. Phase 6 — Session Management

Log in using your lab account.

Inspect:

Set-Cookie

Example:

Set-Cookie: session=abc123; HttpOnly

Evaluate flags such as:

Secure
HttpOnly
SameSite

Understand their purpose:

Attribute	Security Purpose
Secure	Restricts cookie transmission to HTTPS
HttpOnly	Reduces JavaScript access to cookie
SameSite	Helps reduce cross-site request risks

16. Test Logout Behavior

Capture an authenticated request.

Log out.

Then replay the old request using Burp Repeater.

If the application still accepts the old session after logout, this may indicate weak session invalidation.

Record:

Session before logout:
Session after logout:
Old token accepted?:

17. Burp Repeater

Select a request in HTTP history.

Right-click:

Send to Repeater

In Repeater, you can modify requests manually and resend them.

This is one of the most useful tools in web application testing.

Use it for controlled testing of:

Parameters
Cookies
Headers
Request bodies
Authentication tokens

18. Phase 7 — Input Validation Testing

Choose a simple parameter, such as:

/search?q=test

Begin with harmless changes:

test
123
special-characters
'
"
<
>

Observe:

Does the application return an error?
Does the page reflect input?
Does behavior change?
Does the server reject malformed input?

Avoid immediately jumping into complex payloads.

The goal is to understand input handling.

19. SQL Injection Concepts

SQL injection can occur when untrusted input is incorporated into a database query unsafely.

Conceptually:

User Input
    ↓
Application
    ↓
SQL Query
    ↓
Database

An unsafe application might conceptually create:

SELECT * FROM users WHERE username = '<input>';

If input is handled incorrectly, an attacker may alter query logic.

20. Phase 8 — Controlled SQL Injection Validation

Perform this only against your intentionally vulnerable application.

Start with a simple syntax probe in an injectable lab field:

'

Observe the response.

Possible indicators include:

SQL error
Database exception
500 response
Different application behavior

If the training application is explicitly designed for SQL injection practice, you can test a basic authentication-bypass pattern such as:

' OR '1'='1

Use this only in the local intentionally vulnerable lab.

Your goal is to demonstrate:

Input
   ↓
Changes Query Logic
   ↓
Application behaves unexpectedly

Document what changed.

21. SQL Injection Evidence

Record:

Endpoint:
Parameter:
Original Input:
Test Input:
Response Difference:
Database Error:
Authentication Impact:
Validation Status:

Do not collect unnecessary data from the database.

Proving that the weakness exists is sufficient for this lab.

22. SQL Injection Remediation

Recommended controls include:

Parameterized queries
Prepared statements
Input validation
Least-privilege database accounts
Generic error handling

The most important defense is generally avoiding dynamic query construction with untrusted input.

23. Phase 9 — Cross-Site Scripting

Cross-site scripting occurs when untrusted content is rendered in a browser without appropriate encoding or sanitization.

There are commonly:

Reflected XSS
Stored XSS
DOM-based XSS

For PenTest+, understand the difference.

24. Test Reflection

Find a harmless input such as search.

Enter:

GHC_TEST_123

Determine whether the exact value appears in the response.

If it is reflected, inspect where it appears:

<p>Search: GHC_TEST_123</p>

Reflection alone does not prove XSS.

25. Controlled XSS Validation

On an intentionally vulnerable XSS training function, you can test a harmless browser-execution payload:

<script>alert(1)</script>

If the training application’s intended exercise executes the JavaScript, the vulnerability is demonstrated.

Do not use payloads that steal cookies, credentials, or data.

Record:

Endpoint:
Input:
Where reflected:
Execution observed:
Stored or reflected:

26. Reflected vs Stored XSS

Reflected

User input
   ↓
Immediate server response
   ↓
Browser executes

Typically requires the victim to access a crafted request.

Stored

Input submitted
      ↓
Stored by application
      ↓
Later delivered to users
      ↓
Browser executes

Stored XSS may affect multiple users.

27. XSS Remediation

Recommendations include:

Context-aware output encoding
Input validation
HTML sanitization
Content Security Policy
Secure framework templating

Avoid recommending only “block <script>.”

XSS has many contexts and possible representations.

28. Phase 10 — Directory Traversal Concepts

Directory traversal can occur when a user-controlled file path allows access outside the intended directory.

Conceptually:

Application expects:

/files/report.txt

But unsafe input handling may allow navigation outside that directory.

Indicators include application parameters such as:

?file=report.txt
?page=home.html
?template=default

29. Controlled Traversal Testing

Use only the intentionally vulnerable application’s dedicated traversal exercise.

Begin with harmless path manipulation.

Observe whether the application normalizes or rejects unexpected path values.

Do not access sensitive host files beyond what the training exercise explicitly expects.

Record:

Parameter:
Normal request:
Test request:
Application behavior:
Validation status:

30. File Upload Assessment

If your application includes file upload functionality, examine:

Allowed extensions
MIME-type checks
File renaming
Storage location
Direct accessibility
Maximum size
Executable handling

For this lab, use harmless files such as:

test.txt
test.jpg

Do not upload executable web shells.

The objective is to understand upload validation.

31. Phase 11 — IDOR and Authorization Testing

Applications frequently use identifiers:

/profile?id=101
/order?id=200
/document?id=300

An authorization weakness may exist if changing an identifier exposes another user’s resource without proper permission checks.

In your lab, create two test accounts if supported.

Example:

Student-A
Student-B

Log in as Student-A.

Capture a request for Student-A’s resource.

Change only the test resource identifier to one belonging to Student-B.

If the intentionally vulnerable application returns another user’s lab data without proper authorization, record the issue.

This demonstrates Broken Object Level Authorization / IDOR-type behavior.

32. Authentication vs Authorization

Know this distinction.

Authentication:
Who are you?

Authorization:
What are you allowed to do?

A user can be successfully authenticated but still gain unauthorized access because of broken authorization.

33. Phase 12 — HTTP Method Testing

Check supported methods where appropriate:

curl -i -X OPTIONS http://192.168.56.110/

A response might show:

Allow: GET, POST, OPTIONS

Do not assume every listed method is vulnerable.

Your job is to determine whether dangerous functionality is unnecessarily available.

34. Information Disclosure

Look for information such as:

Software versions
Stack traces
Database errors
Internal paths
Debug messages
Internal IP addresses
API keys in frontend code
Developer comments
Backup files

Example:

Fatal error:
Database connection failed at /var/www/app/config.php

This may expose valuable internal information.

35. Security Headers Review

Use:

curl -I http://192.168.56.110

Look for:

Content-Security-Policy
X-Content-Type-Options
Strict-Transport-Security
Referrer-Policy
Permissions-Policy

Missing headers do not automatically mean severe vulnerability.

Treat them as part of the application’s broader security posture.

36. Phase 13 — API Enumeration

Modern applications often communicate with backend APIs.

In Burp HTTP history, identify endpoints such as:

/api/users
/api/login
/api/products
/rest/account

Inspect:

HTTP method
JSON body
Authorization header
Tokens
IDs
Parameters

Example:

POST /api/login HTTP/1.1
Content-Type: application/json

{
  "email": "student@example.com",
  "password": "..."
}

37. JSON Parameter Manipulation

Send an API request to Repeater.

Modify only one field at a time.

For example:

{
  "productId": 10
}

change to:

{
  "productId": 11
}

Observe whether authorization checks are enforced.

Controlled single-variable changes make analysis much clearer.

38. Build the Web Attack Surface Map

Your final map might look like:

Web Application
│
├── Authentication
│   ├── /login
│   ├── /register
│   └── /reset
│
├── User Functions
│   ├── /profile
│   └── /account
│
├── Input Functions
│   ├── /search
│   ├── /feedback
│   └── /upload
│
└── API
    ├── /api/login
    ├── /api/users
    └── /api/products

This is far more useful than simply saying:

Port 80 is open.

39. Phase 14 — Prioritize Findings

Create a table:

Finding	Impact	Exploitability	Authentication Required	Priority
SQL Injection	High	High	Depends	Critical/High
Stored XSS	Medium/High	Medium	Depends	High
IDOR	High	Low/Medium	Yes	High
Information Disclosure	Low/Medium	Low	No	Medium

Use the actual context of your lab.

40. Create Finding Files

Create:

findings/
├── WEB-01.md
├── WEB-02.md
├── WEB-03.md
└── WEB-04.md

Use this template:

# WEB-01 — Vulnerability Name

## Severity

## Endpoint

## Parameter

## Description

## Preconditions

## Steps to Reproduce

## Evidence

## Security Impact

## Likelihood

## Remediation

## Validation Status

41. Example Finding Structure

# WEB-01 — Reflected Cross-Site Scripting

## Severity

Medium

## Endpoint

/search

## Parameter

q

## Description

User-controlled input is returned in an executable browser context
without sufficient output encoding.

## Evidence

A controlled JavaScript test executed within the intentionally
vulnerable training application.

## Impact

An attacker who can convince another user to access a crafted request
may be able to execute attacker-controlled JavaScript in that user's
application context.

## Remediation

Apply context-aware output encoding and use secure framework templating.
Consider Content Security Policy as an additional defense.

42. Student Challenge

Without following the step-by-step commands, identify and document at least four different vulnerability classes in your intentionally vulnerable application.

Try to include:

1 Authentication or session weakness

2 Input validation weakness

3 Authorization weakness

4 Information disclosure or security misconfiguration

For each one, answer:

Where is the vulnerability?

What input triggers it?

What behavior proves it?

What is the potential impact?

How should it be remediated?

43. Required Deliverables

Submit:

01-web-service-scan.txt
02-endpoint-inventory.md
03-http-analysis.md
04-authentication-session-notes.md
05-web-vulnerability-register.md
06-web-application-report.md

Also include your individual finding files.

44. Web Vulnerability Register

Create:

# Web Vulnerability Register

| ID | Finding | Endpoint | Severity | Validation |
|---|---|---|---|---|
| WEB-01 | | | | |
| WEB-02 | | | | |
| WEB-03 | | | | |
| WEB-04 | | | | |

45. Final Report Structure

# Web Application Penetration Test Report

## 1. Executive Summary

## 2. Scope

## 3. Rules of Engagement

## 4. Methodology

## 5. Application Attack Surface

## 6. Authentication Assessment

## 7. Session Assessment

## 8. Input Validation Assessment

## 9. Authorization Assessment

## 10. Detailed Findings

## 11. Risk Prioritization

## 12. Remediation Recommendations

## 13. Evidence

## 14. Conclusion

46. PenTest+ Exam Checkpoints

Know these relationships.

Authentication vs Authorization

Authentication
"Who are you?"

Authorization
"What can you access?"

HTTP GET vs POST

GET
Commonly retrieves resources

POST
Commonly submits data or invokes processing

Do not assume POST is inherently secure.

Cookie security

Understand:

Secure
HttpOnly
SameSite

SQL Injection

Remember:

Untrusted input
      ↓
Unsafe query construction
      ↓
Database query manipulation

XSS

Remember:

Untrusted input
      ↓
Unsafe output
      ↓
Browser execution

IDOR / Broken Access Control

Remember:

Valid user
   ↓
Changes resource identifier
   ↓
Server fails authorization check
   ↓
Unauthorized resource access

47. Knowledge Check

Question 1

Why use Burp Repeater?

Answer: To manually modify and resend individual HTTP requests for controlled vulnerability analysis.

Question 2

What is the major security difference between client-side and server-side input validation?

Answer: Client-side controls can generally be bypassed by modifying the request. Security decisions must be enforced server-side.

Question 3

Why does seeing your search term in a webpage not automatically prove XSS?

Because reflection alone does not demonstrate executable browser context.

Question 4

What is the difference between authentication and authorization?

Authentication verifies identity.

Authorization determines permitted actions and resources.

Question 5

Which cookie attribute reduces direct access from client-side JavaScript?

HttpOnly

Question 6

Should a penetration tester dump an entire database to prove SQL injection?

Answer: Usually no.

Demonstrate the vulnerability with the minimum evidence necessary within the agreed Rules of Engagement.

48. Lab Completion Checklist

• I verified the authorized web application.

• I identified its exposed web services.

• I inspected HTTP headers.

• I configured Burp Suite.

• I intercepted HTTP traffic.

• I mapped major application endpoints.

• I identified application input points.

• I assessed authentication behavior.

• I reviewed session cookies.

• I tested session invalidation.

• I used Burp Repeater.

• I evaluated input handling.

• I safely validated an intended SQL injection exercise.

• I safely validated an intended XSS exercise.

• I evaluated authorization behavior.

• I inspected API requests where present.

• I reviewed information disclosure.

• I documented at least four findings.

• I created a vulnerability register.

• I produced a web assessment report.

• I stayed within the isolated authorized lab.

Key Takeaways

Web penetration testing is not simply:

Find form
   ↓
Send payload

A professional workflow is:

Understand Application
        ↓
Map Attack Surface
        ↓
Capture HTTP Traffic
        ↓
Identify Inputs
        ↓
Form Hypothesis
        ↓
Perform Controlled Test
        ↓
Compare Responses
        ↓
Validate Vulnerability
        ↓
Assess Impact
        ↓
Document Evidence

For PenTest+, pay particular attention to:

HTTP → Authentication → Sessions → Input Validation → Authorization → Evidence

You should be able to explain not only what vulnerability exists, but also:

Where does trust fail, how was the weakness validated, what could an attacker gain, and how should the organization fix it?

What’s Next?

➡️ Lab 04 — Network Exploitation and Post-Exploitation

In the next lab, you will move from discovery and vulnerability validation into controlled exploitation inside the isolated PenTest+ environment.

You will work through:

Validate Target → Select Exploit → Gain Initial Access → Verify Context → Perform Local Enumeration → Identify Privilege-Escalation Opportunity → Collect Minimal Evidence → Cleanup

The lab will cover:

• exploit selection and validation;

• Metasploit fundamentals;

• payload and session concepts;

• shell handling;

• post-exploitation enumeration;

• local privilege-escalation analysis;

• credential exposure concepts;

• lateral-movement concepts;

• maintaining scope during post-exploitation;

• evidence collection;

• cleanup and restoration.

This becomes the practical bridge between finding vulnerabilities and understanding their real security impact.