Lab 03 HTTP, HTTPS & Web Request Analysis

Mission Overview

Welcome to Lab 03 — HTTP, HTTPS & Web Request Analysis.

In Lab 02, you mapped the application and identified its major pages, endpoints, parameters, forms, authentication boundaries, roles, APIs, and trust boundaries.

Now you will study the actual communication between the browser and the web application.

This is a critical web pentesting skill because almost every later assessment depends on your ability to understand:

what the browser sends
what the server returns
which values control state
which values carry identity
which values carry user input
which values influence application behavior
which requests require authentication
where authorization-relevant identifiers appear

Mission Goal: Capture, inspect, compare, and document HTTP and HTTPS requests and responses from an authorized training application so you can identify the fields that influence input, identity, state, routing, and access control before deeper security testing.

Mission Information

Item	Details
Difficulty	Beginner
Estimated Time	90–120 minutes
Primary Skill	HTTP Request/Response Analysis
Secondary Skill	Web Traffic Interpretation
Environment	GoHackersCloud Web Pentesting Lab
Testing Mode	Passive + Controlled Request Comparison
Primary Outcome	HTTP Request/Response Analysis Register
Safety Level	Authorized Training Application Only

Learning Objectives

By completing this lab, you will be able to:

understand HTTP request structure
understand HTTP response structure
identify HTTP methods
identify URL paths and query strings
identify headers
identify cookies
identify request bodies
recognize common content types
distinguish authentication state
distinguish application state
identify object identifiers
identify redirects
interpret response status codes
compare authenticated and unauthenticated requests
compare normal requests safely
recognize JSON and multipart traffic
identify security-relevant headers
identify session-related values
identify user-controlled fields
preserve HTTP evidence
document request behavior professionally

Core Methodology

Use:

Capture → Parse → Compare → Modify Safely → Observe → Correlate → Document

Expanded:

Generate Normal Request
        │
        ▼
Capture Request
        │
        ▼
Parse Components
        │
        ├── Method
        ├── Host
        ├── Path
        ├── Query
        ├── Headers
        ├── Cookies
        └── Body
        │
        ▼
Capture Response
        │
        ├── Status
        ├── Headers
        ├── Cookies
        ├── Body
        └── Redirect
        │
        ▼
Compare Requests
        │
        ▼
Identify Security-Relevant Fields
        │
        ▼
Document Behavior

The core principle is:

Before changing a web request, understand what every important part of that request is doing.

Part 1 — Confirm Scope

Record:

ASSESSMENT ID:
GHC-WEB-LAB03-001

APPLICATION:

BASE URL:

AUTHORIZED:
Yes

TEST ACCOUNTS:

TEST WINDOW:

EXCLUDED SYSTEMS:

All request analysis should remain inside the authorized training application.

Part 2 — Create the Lab Workspace

Create:

Web-Pentesting-Labs/
└── Lab-03/
    ├── 01-Scope/
    ├── 02-Requests/
    │   ├── Public/
    │   ├── Authenticated/
    │   └── API/
    ├── 03-Responses/
    ├── 04-Headers/
    ├── 05-Cookies/
    ├── 06-Parameters/
    ├── 07-Redirects/
    ├── 08-JSON/
    ├── 09-Multipart/
    ├── 10-Comparisons/
    ├── 11-Evidence/
    ├── 12-Notes/
    └── 13-Report/

Part 3 — Understand the HTTP Request

A request conceptually looks like:

GET /account?id=1001 HTTP/1.1
Host: training-app.example.test
User-Agent: Browser
Cookie: session=<value>
Accept: text/html

The important components are:

Method

Path

Query String

Headers

Cookies

Body

Part 4 — Understand the HTTP Response

A response may look conceptually like:

HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: session=<value>
Content-Length: ...

<html>
...
</html>

Important response components include:

Status Code

Headers

Cookies

Content Type

Body

Redirect Information

Part 5 — Capture a Public Request

Access the application home page.

Record:

REQUEST ID:
REQ-001

AUTH STATE:
Unauthenticated

METHOD:

HOST:

PATH:

QUERY:

HEADERS:

COOKIES:

BODY:

Then capture the response.

Part 6 — Create the Request Register

Request ID	Method	Path	Auth	Purpose
REQ-001	GET	`/`	No	Home
REQ-002	GET	`/login`	No	Login page
REQ-003	POST	`/login`	No	Login submission
REQ-004	GET	`/account`	Yes	Account page

Part 7 — Analyze the Request Line

The first line often contains:

METHOD PATH PROTOCOL

Example:

GET /search?q=cloud HTTP/1.1

Identify:

Method:
GET

Path:
/search

Query:
q=cloud

Protocol:
HTTP/1.1

Part 8 — Identify HTTP Methods

Common methods include:

GET
POST
PUT
PATCH
DELETE
OPTIONS
HEAD

Interpret methods by context.

Do not assume:

POST = secure

or:

DELETE = vulnerable

A method is simply part of the application’s behavior.

Part 9 — Build the Method Register

Method	Endpoint	Purpose	Auth
GET	`/search`	Retrieve results	No
POST	`/login`	Submit credentials	No
POST	`/profile`	Update profile	Yes

Part 10 — Identify URL Components

A URL may contain:

https://training.example.test:443/product?id=1001#reviews

Break it into:

Scheme:
https

Host:
training.example.test

Port:
443

Path:
/product

Query:
id=1001

Fragment:
reviews

Remember:

Browser fragments are generally not transmitted to the server as part of the HTTP request.

Part 11 — Analyze Query Parameters

Example:

/search?q=cloud&page=2

Record:

Parameter	Value	Type
q	cloud	Search input
page	2	Numeric

Ask:

Is the value user-controlled?
Does it affect content?
Does it identify an object?
Does it affect navigation?

Part 12 — Analyze Request Headers

Common headers include:

Host
User-Agent
Accept
Accept-Language
Referer
Origin
Authorization
Content-Type
Cookie

Create:

Header	Present	Security Relevance
Host	Yes	Routing
Cookie	Yes	Session
Authorization	Maybe	Identity
Origin	Maybe	Cross-origin context
Referer	Maybe	Navigation context

Part 13 — Understand the Host Header

Example:

Host: training.example.test

This tells the server which host the client intended to reach.

In this lab:

Observe and document it.

Do not perform host-routing abuse testing yet.

Part 14 — Understand User-Agent

Example:

User-Agent: <browser information>

It identifies the client software to the application.

It may influence server behavior, but its presence alone is not a vulnerability.

Part 15 — Understand Referer

A request may contain:

Referer: https://training.example.test/account

This may help you understand navigation flow.

Do not assume the server safely enforces authorization based on Referer.

Part 16 — Understand Origin

For some requests you may observe:

Origin: https://training.example.test

This can be relevant to browser cross-origin security.

Detailed cross-origin assessment can be addressed later.

Part 17 — Analyze Cookies

A request may contain:

Cookie: session=<value>

Create:

COOKIE PROFILE

Cookie Name:

Value Type:

Observed Before Login:
Yes / No

Observed After Login:
Yes / No

Changes on Login:
Yes / No

Purpose:
Known / Suspected / Unknown

Watch for:

session
sid
sessionid
auth
token
jwt

Do not assume every cookie carries authentication.

Some cookies may be for:

preferences
analytics
localization
application state

Using the authorized test account, observe the login submission.

Record:

REQUEST ID:
REQ-LOGIN-001

METHOD:

PATH:

CONTENT TYPE:

USERNAME FIELD:

PASSWORD FIELD:

OTHER FIELDS:

COOKIES:

CSRF-LIKE TOKEN:
Observed / Not Observed / Unknown

RESPONSE STATUS:

Do not record real credentials in screenshots or reports.

Create:

Field	Before Login	After Login
Session Cookie
Authentication Cookie
Authorization Header
Accessible Path
Redirect

This comparison helps identify what changes when identity is established.

The server may return:

200 OK

or:

302 Found

followed by a redirect.

Record:

LOGIN RESPONSE

Status:

Redirect:

Set-Cookie:

New Session:

Destination:

Error Message:

Part 22 — Understand Redirects

A response may contain:

HTTP/1.1 302 Found
Location: /dashboard

This means the browser is instructed to request another resource.

Conceptually:

POST /login
     ↓
302
     ↓
GET /dashboard

The redirect is part of the workflow.

Part 23 — Build the Redirect Register

Redirect ID	From	Status	To
RED-001	`/login`	302	`/dashboard`
RED-002	`/logout`	302	`/login`

Part 24 — Interpret Status Codes

Common codes:

200 OK

Request completed successfully.

201 Created

Resource created.

204 No Content

Successful response without response body.

301 / 302

Redirect.

400

Request invalid or rejected.

401

Authentication required or failed.

403

Request understood but access denied.

404

Resource not found.

500

Server error.

Do not interpret a code without application context.

Part 25 — Professional Distinction: 401 vs 403

Conceptually:

401
Often relates to authentication.

403
Often relates to authorization/access denial.

But applications do not always implement these consistently.

Observe actual behavior.

Part 26 — Capture an Authenticated Request

After login, access a user page.

Record:

REQUEST ID:
REQ-AUTH-001

METHOD:

PATH:

AUTH COOKIE:

OBJECT ID:

USER INPUT:

HEADERS:

BODY:

Then compare it with a public request.

Part 27 — Identify Identity-Carrying Fields

Potential examples:

Cookie

Authorization Header

Bearer Token

Session Identifier

Record:

IDENTITY FIELD REGISTER

Field:

Location:

Appears After Login:

Changes Between Accounts:

Role Related:
Unknown / Suspected

Detailed session testing comes later.

Part 28 — Identify Application State

Applications may store state in:

Cookies

Hidden fields

Tokens

Query parameters

Server-side session

Client storage

Your objective is simply to understand where state appears.

Part 29 — Analyze POST Body

A request may contain:

username=lab-user&password=<redacted>

or:

name=student&email=student@example.test

Record:

field names
content type
which values are user-controlled
which values appear security-sensitive

Part 30 — Understand Content Types

Common request/response content types include:

application/x-www-form-urlencoded

application/json

multipart/form-data

text/html

text/plain

application/xml

Create:

Endpoint	Content Type	Purpose
`/login`	form-urlencoded	Authentication
`/api/profile`	JSON	API
`/upload`	multipart/form-data	File upload

Part 31 — Analyze JSON Requests

Example:

{
  "name": "lab-user",
  "email": "lab@example.test"
}

Document:

JSON ENDPOINT:

Method:

Fields:

Field Types:

Authentication:

Object Identifier:

Role-Related Fields:

Do not change sensitive fields beyond what the current lab requires.

Part 32 — Analyze JSON Responses

Example:

{
  "id": 1001,
  "name": "lab-user",
  "role": "user"
}

Record:

returned identifiers
role data
status information
nested objects
sensitive data exposure observations

An identifier in the response does not prove an access-control issue.

Part 33 — Analyze Multipart Requests

File upload forms may produce:

Content-Type: multipart/form-data

Observe:

Filename

Form Field

Declared Content Type

Additional Parameters

This prepares you for the dedicated file-handling lab.

Part 34 — Create the Multipart Register

Field	Value
Endpoint
Method
File Field
Filename
Content Type
Auth Required

Part 35 — Identify Object Identifiers

Look for:

id=1001

user_id=42

order=5002

/api/profile/42

Create:

Object ID	Endpoint	Location	Expected Owner
OBJ-001	`/order`	Query	User
OBJ-002	`/api/user/42`	Path	User

This prepares for Lab 07.

Part 36 — Distinguish Identifier from Authorization

Always remember:

Object ID Present
      ≠
IDOR / Authorization Vulnerability

You must later validate whether another identity can access that object without authorization.

Part 37 — Identify Hidden Fields

Example:

<input type="hidden" name="user_id" value="42">

Record:

FIELD:
user_id

TYPE:
Hidden form input

USER-CONTROLLED:
Client-side yes

SECURITY SIGNIFICANCE:
Requires later validation

Hidden does not mean trusted.

Part 38 — Identify Security Headers in Responses

Observe whether responses contain headers such as:

Content-Security-Policy

Strict-Transport-Security

X-Content-Type-Options

Referrer-Policy

Permissions-Policy

Record what is present.

Do not automatically classify absence as a high-severity vulnerability.

Part 39 — Create the Security Header Register

Header	Present	Value	Observation
CSP
HSTS
X-Content-Type-Options
Referrer-Policy

A response may include attributes such as:

Secure

HttpOnly

SameSite

Create:

Cookie	Secure	HttpOnly	SameSite
session

Detailed session assessment comes later.

Part 41 — Compare Anonymous vs Authenticated Request

Take the same logical application area where appropriate and compare.

Example:

Anonymous request
      ↓
/account
      ↓
Redirect to login

Authenticated:

Authenticated request
      ↓
/account
      ↓
200 OK

Record the observed behavior.

Part 42 — Compare Two Authorized User Accounts

Where the lab provides two user accounts, compare legitimate requests from each.

Do not attempt access-control bypass yet.

Record differences in:

Session cookie

User ID

Object identifiers

Role

Returned content

This builds a baseline for later authorization testing.

Part 43 — Build the Account Comparison Register

Field	User A	User B
Session Value	Different	Different
User ID
Role	User	User
Account Path
Response Data

Part 44 — Identify CSRF-Like Tokens

You may encounter values such as:

csrf_token

_token

request_token

Record:

TOKEN NAME:

LOCATION:

REQUEST TYPE:

CHANGES BETWEEN REQUESTS:
Yes / No / Unknown

SECURITY PURPOSE:
Suspected / Known

Do not test bypass behavior yet.

Part 45 — Understand Idempotent vs State-Changing Behavior

Some requests retrieve data.

Others modify state.

Examples:

GET /profile
→ Read

POST /profile
→ Update

Create:

Endpoint	Action	State Change
`/search`	Search	No
`/profile` POST	Update	Yes
`/logout`	Session change	Yes

State-changing endpoints deserve careful testing later.

Part 46 — Build the State-Changing Request Register

Request ID	Endpoint	Method	Action	Auth
SCR-001	`/profile`	POST	Update profile	Yes
SCR-002	`/password`	POST	Change password	Yes

Part 47 — Observe Application Error Responses

Use only normal, controlled variations in the authorized lab.

Record:

STATUS:

ERROR MESSAGE:

SERVER DETAILS:

STACK INFORMATION:
Observed / Not Observed

INPUT REFLECTED:
Yes / No

Do not intentionally induce destructive server failures.

Part 48 — Distinguish Error from Vulnerability

Remember:

Application Error
      ≠
Exploitable Vulnerability

An error may become relevant if it exposes sensitive information or reveals unsafe behavior, but that requires validation.

You may observe:

Cache-Control

Pragma

Expires

Record behavior on sensitive pages.

Do not yet overstate security impact.

Part 50 — Observe HTTPS

If the training environment uses HTTPS, recognize that:

HTTPS protects data in transit between client and server.

It does not automatically protect against:

broken authentication
access-control weaknesses
injection
business-logic problems

Always distinguish:

HTTPS
   ≠
Secure Application Automatically

Part 51 — Understand HTTP vs HTTPS

Conceptually:

HTTP
Client ───────── Server

versus:

HTTPS
Client ═Encrypted Channel═ Server

HTTPS protects the transport.

Application logic must still enforce security.

Part 52 — Identify Mixed Protocol Behavior

Record whether the application:

redirects HTTP to HTTPS
uses HTTPS consistently
references resources with a different scheme

Do not test external resources outside scope.

Part 53 — Compare Normal Requests

For one safe function, generate two legitimate requests.

Example:

/search?q=cloud

and:

/search?q=security

Compare:

which values changed
which values remained constant
whether session data changed
whether response structure changed

This teaches controlled request analysis.

Part 54 — Build the Request Difference Register

Component	Request A	Request B	Changed
Path	`/search`	`/search`	No
q	cloud	security	Yes
Session	same	same	No
Response content	results A	results B	Yes

Part 55 — Identify User-Controlled Values

Mark every important field as:

User Controlled

Application Generated

Server Generated

Unknown

Create:

Field	Location	Control
q	Query	User
session	Cookie	Server-generated
user_id	Body	Unknown
CSRF token	Body	Application-generated

Part 56 — Identify Security-Relevant Request Fields

Prioritize fields related to:

Identity

Session

Role

Object Ownership

Redirects

Files

URLs

Search

Account Changes

These will become targets in later labs.

Part 57 — Build the Request Security Map

Example:

POST /profile
   │
   ├── session cookie → Identity
   ├── user_id        → Object reference
   ├── email          → User input
   └── csrf_token     → Request integrity control

This is the type of understanding you want before deeper testing.

Part 58 — Correlate Requests into Workflows

A single action may involve multiple requests.

Example login flow:

GET /login
     ↓
POST /login
     ↓
302 /dashboard
     ↓
GET /dashboard

Create workflow diagrams for key application functions.

Part 59 — Build the Request Workflow Register

Workflow	Requests
Login	GET login → POST login → redirect → dashboard
Logout	request → session update → login
Profile Update	GET profile → POST profile → response

Part 60 — Preserve HTTP Evidence

For important requests preserve:

Request

Response

Timestamp

Account / Role

Application State

Evidence ID

Avoid including passwords or reusable secrets unnecessarily.

Part 61 — Create the Evidence Register

Evidence ID	Description
EV-001	Public home request
EV-002	Login page response
EV-003	Redacted login request
EV-004	Login response
EV-005	Authenticated account request
EV-006	API JSON request
EV-007	Multipart request
EV-008	Security header response

Part 62 — Create the HTTP Analysis Register

Use:

REQUEST ID:

PURPOSE:

AUTH STATE:

ROLE:

METHOD:

PATH:

QUERY PARAMETERS:

HEADERS:

COOKIES:

CONTENT TYPE:

BODY FIELDS:

OBJECT IDENTIFIERS:

STATE-CHANGING:
Yes / No

RESPONSE STATUS:

REDIRECT:

SET-COOKIE:

SECURITY HEADERS:

USER-CONTROLLED VALUES:

SECURITY-RELEVANT VALUES:

EVIDENCE:

NOTES:

Part 63 — Build the HTTP Assessment Matrix

Area	Status
Public Requests	Mapped
Authenticated Requests	Mapped
Methods	Mapped
Query Parameters	Mapped
Body Parameters	Mapped
Cookies	Mapped
Session Values	Identified
Redirects	Mapped
JSON	Mapped
Multipart	Mapped
Security Headers	Reviewed
State-Changing Requests	Identified

Part 64 — Mission Challenge

Complete:

HTTP / HTTPS REQUEST ANALYSIS

Assessment ID:

Analyst:

Date:


APPLICATION

Base URL:

HTTP / HTTPS:

Authorized:
Yes / No


PUBLIC REQUEST

Method:

Path:

Query:

Headers:

Cookies:

Status:

Content Type:


LOGIN FLOW

Login Page Request:

Login Submission Method:

Login Endpoint:

Credential Fields:

Additional Fields:

Login Response:

Redirect:

New Cookie / Token:


AUTHENTICATED REQUEST

Path:

Method:

Session Field:

Object Identifier:

Body:

Response:


COOKIES

Cookie 01:

Purpose:

Secure:

HttpOnly:

SameSite:


HEADERS

Authorization:

Origin:

Referer:

Content-Type:

Security Headers:


PARAMETERS

Query:

Form:

JSON:

Header:

Cookie:

Path:


JSON

Endpoint:

Fields:

Authenticated:
Yes / No


MULTIPART

Endpoint:

File Field:

Filename:

Content Type:


REDIRECTS

From:

Status:

To:


STATE-CHANGING REQUESTS

Request 01:

Action:

Request 02:

Action:


USER-CONTROLLED VALUES

Field 01:

Location:

Field 02:

Location:

Field 03:

Location:


OBJECT REFERENCES

Object 01:

Endpoint:

Location:


WORKFLOWS

Login:

Profile:

Logout:


EVIDENCE

Request Evidence:

Response Evidence:

Evidence Register:
Complete / Incomplete


FINAL ASSESSMENT

HTTP Structure Understood:
Yes / No

Authenticated Traffic Identified:
Yes / No

Session Values Identified:
Yes / No

User Inputs Identified:
Yes / No

Object Identifiers Identified:
Yes / No

State-Changing Requests Identified:
Yes / No

Ready for Endpoint Discovery:
Yes / No

What Not to Do

Do not:

Send requests to systems outside scope

Use real user credentials

Store passwords in screenshots

Assume HTTPS means the application is secure

Assume HTTP 200 means authorized access

Assume HTTP 403 means access control cannot be bypassed

Assume a cookie is an authentication cookie without evidence

Assume a hidden field is trusted

Assume a user ID means IDOR

Assume JSON means API vulnerability

Assume missing security header means critical vulnerability

Treat every server error as exploitable

Perform destructive request modifications

Change sensitive state without authorization

The professional rule is:

Capture the baseline first. Understand normal application behavior before testing abnormal behavior.

Professional Distinctions

Always distinguish:

HTTP Request
      ≠
Security Finding

HTTP 200
      ≠
Authorized Access Automatically

HTTP 403
      ≠
Secure Authorization Automatically

Cookie
      ≠
Authentication Token Automatically

Hidden Field
      ≠
Trusted Server Value

Object Identifier
      ≠
IDOR

POST Request
      ≠
Secure Request

HTTPS
      ≠
Secure Application

Application Error
      ≠
Exploitable Vulnerability

JSON Endpoint
      ≠
Insecure API

Security Header Missing
      ≠
Critical Finding Automatically

Redirect
      ≠
Open Redirect Vulnerability

Evidence Requirements

Capture:

scope record
public request
public response
request register
method register
URL component analysis
query parameter analysis
request-header inventory
cookie profile
redacted login request
login response
pre/post-login comparison
redirect register
authenticated request
identity field register
request-body analysis
content-type register
JSON request
JSON response
multipart request
object identifier register
hidden-field observation
security-header register
cookie attribute register
account comparison
request-token observation
state-changing request register
HTTPS observations
request comparison register
user-controlled value register
request security map
workflow register
evidence register
HTTP Analysis Register

Mission Deliverables

Complete:

authorization confirmed
HTTP request structure understood
HTTP response structure understood
common methods identified
URL components documented
query parameters documented
important headers identified
cookies documented
session-related values identified
login request analyzed
login response analyzed
redirects mapped
public and authenticated traffic compared
authenticated request analyzed
identity-carrying fields identified
application-state values identified
POST bodies reviewed
content types classified
JSON traffic analyzed
multipart traffic analyzed
object identifiers documented
hidden inputs identified
response security headers reviewed
cookie attributes reviewed
two authorized user sessions compared where available
state-changing requests identified
error responses documented where naturally observed
HTTPS behavior understood
normal request comparisons performed
user-controlled values identified
security-relevant fields mapped
major request workflows documented
evidence preserved
HTTP analysis register completed

Lab Report Template

# Lab 03 — HTTP, HTTPS & Web Request Analysis

## Executive Summary

## Mission Objective

## Authorization & Scope

## Application Profile

## HTTP Communication Model

## Public Request Analysis

## Public Response Analysis

## HTTP Methods

## URL Components

## Query Parameters

## Request Headers

## Cookies

## Authentication Request

## Authentication Response

## Redirect Flow

## Authenticated Request

## Session Indicators

## Application State

## Request Bodies

## Content Types

## JSON Traffic

## Multipart Traffic

## Object Identifiers

## Hidden Fields

## Security Headers

## Cookie Attributes

## Account Comparison

## State-Changing Requests

## HTTPS Observations

## Request Comparison

## User-Controlled Values

## Security-Relevant Fields

## Workflow Analysis

## HTTP Analysis Register

## Evidence Register

## Observations

## Limitations

## Areas for Further Testing

## Conclusion

Knowledge Check

Question 1 — What are the major parts of an HTTP request?

Method, path, query data, headers, cookies, and request body where present.

Question 2 — What does HTTP 200 prove?

Only that the server successfully handled the request in some manner. It does not automatically prove the user was authorized to access the underlying resource.

Question 3 — Why compare traffic before and after authentication?

To identify what values establish identity, session state, and authenticated application behavior.

Question 4 — Does the presence of a user ID prove an IDOR vulnerability?

No.

It identifies a potential authorization-relevant object reference that requires separate testing.

Question 5 — Why identify state-changing requests?

Because actions that modify accounts, data, privileges, or application state often deserve higher security-testing priority.

Question 6 — Does HTTPS make the web application secure?

No.

HTTPS protects the network transport. Application security controls must still function correctly.

Question 7 — What is the purpose of analyzing cookies?

To understand application state, session behavior, and potentially security-relevant client/server values.

Question 8 — Why preserve the baseline request before modifying it?

Because you need to understand normal application behavior and have something reliable against which modified behavior can be compared.

Question 9 — Should every missing security header automatically become a major vulnerability?

No.

Its relevance depends on application behavior, compensating controls, and demonstrated impact.

Question 10 — What is the central question?

“Can you understand a web request well enough to identify which parts control application behavior, identity, state, input, and authorization before attempting deeper security validation?”

Skills Achieved

After completing this lab, you should understand:

HTTP request anatomy
HTTP response anatomy
HTTP methods
URL parsing
query-string analysis
request-header analysis
response-header analysis
cookie analysis
login traffic analysis
redirect analysis
authenticated traffic analysis
session indicator identification
application-state identification
request-body analysis
JSON analysis
multipart analysis
object-reference identification
hidden-field identification
security-header observation
cookie-attribute observation
state-changing request identification
HTTPS interpretation
request comparison
user-input identification
application-workflow mapping
HTTP evidence preservation

Professional Takeaway

A weak web testing process looks like:

Capture Request
      ↓
Change Random Values
      ↓
Observe Error
      ↓
Call It Vulnerable

A professional process looks like:

Capture Baseline
      ↓
Understand Method
      ↓
Understand Path
      ↓
Understand Parameters
      ↓
Understand Headers
      ↓
Understand Cookies
      ↓
Understand Identity
      ↓
Understand Application State
      ↓
Understand Response
      ↓
Compare Normal Requests
      ↓
Identify Security-Relevant Fields
      ↓
Plan Controlled Validation

What’s Next?

➡️ Lab 04 — Web Content, Endpoint & Parameter Discovery

In the next lab, you will move from understanding individual requests to systematically expanding the application map.

You will focus on:

visible and less-obvious application content
endpoints
directories
routes
parameters
forms
API paths
archived or legacy application areas
client-side-discovered routes
access requirements
endpoint classification
attack-surface completeness
evidence-driven prioritization

The methodology becomes:

Seed → Discover → Verify → Classify → Deduplicate → Map → Prioritize

And the central question will be:

“Have I identified enough of the application’s real endpoint and parameter surface that important functionality is unlikely to remain invisible to the rest of the assessment?”

Lab 03 HTTP, HTTPS & Web Request Analysis

Mission Overview

Mission Information

Learning Objectives

Core Methodology

Part 1 — Confirm Scope

Part 2 — Create the Lab Workspace

Part 3 — Understand the HTTP Request

Part 4 — Understand the HTTP Response

Part 5 — Capture a Public Request

Part 6 — Create the Request Register

Part 7 — Analyze the Request Line

Part 8 — Identify HTTP Methods

Part 9 — Build the Method Register

Part 10 — Identify URL Components

Part 11 — Analyze Query Parameters

Part 12 — Analyze Request Headers

Part 13 — Understand the Host Header

Part 14 — Understand User-Agent

Part 15 — Understand Referer

Part 16 — Understand Origin

Part 17 — Analyze Cookies

Part 18 — Identify Session-Related Values

Part 19 — Capture a Login Request

Part 20 — Compare Pre-Login and Post-Login Traffic

Part 21 — Analyze the Login Response

Part 22 — Understand Redirects

Part 23 — Build the Redirect Register

Part 24 — Interpret Status Codes

200 OK

201 Created

204 No Content

301 / 302

400

401

403

404

500

Part 25 — Professional Distinction: 401 vs 403

Part 26 — Capture an Authenticated Request

Part 27 — Identify Identity-Carrying Fields

Part 28 — Identify Application State

Part 29 — Analyze POST Body

Part 30 — Understand Content Types

Part 31 — Analyze JSON Requests

Part 32 — Analyze JSON Responses

Part 33 — Analyze Multipart Requests

Part 34 — Create the Multipart Register

Part 35 — Identify Object Identifiers

Part 36 — Distinguish Identifier from Authorization

Part 37 — Identify Hidden Fields

Part 38 — Identify Security Headers in Responses

Part 39 — Create the Security Header Register

Part 40 — Understand Set-Cookie Attributes

Part 41 — Compare Anonymous vs Authenticated Request

Part 42 — Compare Two Authorized User Accounts

Part 43 — Build the Account Comparison Register

Part 44 — Identify CSRF-Like Tokens

Part 45 — Understand Idempotent vs State-Changing Behavior

Part 46 — Build the State-Changing Request Register

Part 47 — Observe Application Error Responses

Part 48 — Distinguish Error from Vulnerability

Part 49 — Analyze Cache-Related Headers

Part 50 — Observe HTTPS

Part 51 — Understand HTTP vs HTTPS

Part 52 — Identify Mixed Protocol Behavior

Part 53 — Compare Normal Requests

Part 54 — Build the Request Difference Register

Part 55 — Identify User-Controlled Values

Part 56 — Identify Security-Relevant Request Fields

Part 57 — Build the Request Security Map

Part 58 — Correlate Requests into Workflows

Part 59 — Build the Request Workflow Register

Part 60 — Preserve HTTP Evidence

Part 61 — Create the Evidence Register

Part 62 — Create the HTTP Analysis Register

Part 63 — Build the HTTP Assessment Matrix

Part 64 — Mission Challenge

What Not to Do

Professional Distinctions