This repository contains notes and the Session 1 plan for a workshop series on web exploitation. The goal of Session 1 is to give participants a solid foundation in how web applications communicate, the tools used to inspect those communications, and the basic architecture of the web.
Duration: 45–60 minutes (adjustable)
- Your Motivation
By the end of this session, participants will understand the fundamental concepts of the Web, how web applications function, and the structure of HTTP requests and responses. They will also understand the difference between HTTP and HTTPS, the importance of encryption, and how to distinguish between Front-end and Back-end components as well as different web architectures. Additionally, participants will learn to differentiate between Blackbox, Whitebox, and Greybox security testing methodologies and understand the purpose of essential tools like Browser DevTools, cURL, and Burp Suite.
- 0. What are Web Applications
- 1. HTTP Protocol Fundamentals
- 2. HTTPS and Security
- 3. Tools Overview
- 4. HTTP Requests and Responses
- 5. HTTP Headers
- 6. Web Application Architecture
- 7. Front End vs Back End
- 8. Security Testing Approaches
- 9. Challenge
- 10. Resources and Next Steps
The Web is a system that lets users access and share information over the internet through websites and web applications using protocols like HTTP and HTTPS.
Here's a simplified overview of the process (we'll dive into more details later):
- Browser sends a request → The user's browser creates and sends a request to a server
- Server processes and responds → The server receives the request and sends back data (HTML, CSS, JavaScript, images, etc.)
- Browser renders the page → The browser interprets the received data and displays it as a web page
Web applications are interactive applications that run on web browsers. Web applications use a client-server architecture where:
- Front-end components (the website interface - "what the user sees") run in the browser
- Back-end components (application logic and data) run on remote servers
- Globally Accessible: Available to attackers worldwide 24/7
- Large Attack Surface: Multiple entry points (forms, APIs, authentication)
- Valuable Data: Often connected to databases with sensitive information
- Complexity: Modern apps have many components that can contain flaws
Web application testing is critical because:
- Applications evolve constantly with new features
- Each update can introduce new vulnerabilities
- Many apps connect to sensitive backend systems
HTTP (HyperText Transfer Protocol) is the application-layer protocol used to access resources on the Web. It defines how clients (usually browsers) request resources from servers and how servers respond.
- DNS Resolution: Browser resolves domain to IP (checks
/etc/hostsfirst, then DNS servers) - HTTP Request: Client sends request line, headers, and optional body
- Server Processing: Web server and application process the request
- HTTP Response: Server returns status line, headers, and body
- Browser Rendering: Browser interprets response and may make additional requests
Resources are identified by URLs with the following components:
http://example.test.com:80/dashboard?login=true#status
| Component | Example | Description |
|---|---|---|
| Scheme | http:// or https:// |
Protocol identifier |
| Subdomain | example |
Optional prefix to the main domain (e.g., www, api, admin) |
| Second-Level Domain (SLD) | test |
The main domain name, located directly left of the TLD |
| Top-Level Domain (TLD) | com |
Highest level of the domain hierarchy (e.g., com, org, net, io) |
| Full Domain / Hostname | example.test.com |
Complete domain including subdomain, SLD, and TLD |
| Port | :80 |
Defaults: 80 (HTTP), 443 (HTTPS) |
| Path | /dashboard |
Resource location on server |
| Query | ?login=true |
Parameters for server-side processing |
| Fragment | #status |
Client-side navigation (not sent to server) |
HTTPS (Hypertext Transfer Protocol Secure) is HTTP layered over TLS (Transport Layer Security), which adds three critical protections for web communication:
All data exchanged between the client (browser) and server is encrypted, preventing attackers from reading sensitive information such as passwords, tokens, or personal data.
TLS ensures that data cannot be tampered with or altered while in transit. Any modification by an attacker will be detected by the browser or server.
HTTPS verifies the identity of the server using a digital certificate issued by a trusted Certificate Authority (CA), ensuring that the user is connecting to the legitimate site and not a malicious impostor.
Essential tools every web security tester should know:
Primary Tool: Chrome/Firefox DevTools
- Access:
Ctrl+Shift+IorF12 - Network Tab: View all HTTP requests, inspect headers, copy as cURL
- Console Tab: Run JavaScript, view errors and logs
- Elements Tab: Inspect and modify DOM/HTML
- Application Tab: View cookies, localStorage, session data
- Sources Tab: Debug JavaScript, set breakpoints
HTTP client for terminal-based testing
# Common flags
curl -I # Headers only
curl -v # Verbose (full details)
curl -X POST # Specify method
curl -d # Send data
curl -H # Custom headers
curl -b # Send cookiesIndustry-standard proxy for web security testing
- Intercept and modify requests/responses
- Repeater for manual testing
- Intruder for automated fuzzing
- Scanner for vulnerability detection
Fast web fuzzer (directories, parameters, vhosts)
ffuf -u https://example.com/FUZZ -w wordlist.txtSimilar tools: gobuster, dirb, etc.
An HTTP request consists of:
- Request Line: Method, Path, Version
- Headers: Key-value metadata pairs
- Blank Line: Separates headers from body
- Body: Optional data (for POST, PUT, etc.)
Example:
POST /api/users/update-password HTTP/1.1
Host: test.com
User-Agent: Mozilla/5.0
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U
Cookie: session_id=a7f3d9e2c8b4a1f6e9d3c7b2a5f8e1d4
Content-Type: application/json
Content-Length: 60
{
"old_password": "oldpass",
"new_password": "newpass"
}Common HTTP Methods:
| Method | Purpose |
|---|---|
| GET | Retrieve resource |
| POST | Submit data/create resource |
| PUT/PATCH | Update resource |
| DELETE | Remove resource |
| HEAD | Get headers only |
| OPTIONS | Get allowed methods |
An HTTP response consists of:
- Status Line: Version, Status Code, Reason Phrase
- Headers: Response metadata
- Blank Line
- Body: Response content (HTML, JSON, etc.)
Example:
HTTP/1.1 200 OK
Date: Thu, 02 Jan 2026 14:35:22 GMT
Server: nginx/1.24.0
Set-Cookie: session_id=b9e4f7a3d6c2e8f1a7b5d9c3e6f2a8d1; HttpOnly; Secure; SameSite=Strict
Content-Type: application/json; charset=UTF-8
Content-Length: 89
{
"success": true,
"message": "Password updated successfully",
"user_id": 12345
}Common Status Codes:
| Code Range | Category | Examples |
|---|---|---|
| 1xx | Informational | 100 Continue, 101 Switching Protocols |
| 2xx | Success | 200 OK, 201 Created, 204 No Content |
| 3xx | Redirection | 301 Moved Permanently, 302 Found, 304 Not Modified |
| 4xx | Client Error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found |
| 5xx | Server Error | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable |
HTTP headers pass metadata between client and server. They are key-value pairs that provide context about the message, entity, or connection.
Apply to both requests and responses; describe the message itself.
Date: Wed, 16 Feb 2022 10:38:44 GMT— Message timestampConnection: keep-alive— Connection persistence (keep-alive/close)
Describe the content being transferred.
Content-Type: text/html; charset=UTF-8— Media type of entityContent-Length: 1234— Size in bytesContent-Encoding: gzip— Applied transformations (compression)
Sent by client to provide context about the request.
| Header | Example | Purpose |
|---|---|---|
| Host | Host: www.example.com |
Target host (required in HTTP/1.1) |
| User-Agent | User-Agent: Mozilla/5.0 |
Client software identifier |
| Referer | Referer: https://google.com |
Origin of request |
| Accept | Accept: application/json |
Acceptable response formats |
| Cookie | Cookie: session=abc123 |
Client-stored data |
| Authorization | Authorization: Bearer token |
Authentication credentials |
| Content-Type | Content-Type: application/json |
Body format (for POST/PUT) |
Sent by server to provide metadata about the response.
| Header | Example | Purpose |
|---|---|---|
| Server | Server: Apache/2.4.41 |
Server software info |
| Set-Cookie | Set-Cookie: id=abc; Secure |
Instruct client to store cookie |
| Location | Location: /new-url |
Redirect target |
| Cache-Control | Cache-Control: max-age=3600 |
Caching directives |
Critical headers that enhance security:
| Header | Example | Purpose |
|---|---|---|
| Content-Security-Policy | script-src 'self' |
Restrict resource loading (XSS mitigation) |
| X-Frame-Options | DENY |
Prevent clickjacking |
| X-Content-Type-Options | nosniff |
Prevent MIME sniffing |
| Referrer-Policy | no-referrer |
Control referrer information |
| Access-Control-Allow-Origin | https://trusted-site.com |
Specify allowed origins for CORS requests |
| Access-Control-Allow-Credentials | true |
Allow credentials (cookies, auth) in CORS requests |
Understanding web application architecture helps identify attack surface, data flows, and potential security weaknesses.
- Client: Browser or mobile app (UI/UX layer)
- Web Server: Handles HTTP connections (Nginx, Apache, IIS)
- Application Server: Business logic and request processing
- Database: Persistent data storage (MySQL, PostgreSQL, MongoDB)
- Services: Microservices, APIs, third-party integrations
| Tier | Components | Responsibilities |
|---|---|---|
| Presentation | HTML, CSS, JS, Mobile Apps | User interface and client-side logic |
| Application | Web frameworks, APIs | Business logic, authorization, validation |
| Data | Databases, File storage | Data persistence and retrieval |
Benefits:
- Clear separation of concerns
- Independent scaling of each tier
- Easier to maintain and secure
- Single unified codebase with all components tightly integrated
- Traditional approach where UI, business logic, and data access are packaged together
- Example: A blog platform where user management, post creation, comments, and media uploads all run in a single application. When you deploy or update, the entire application restarts.
- Clear separation between client (frontend) and server (backend)
- Client handles presentation, server handles logic and data
- Example: A todo list app with a React frontend that sends HTTP requests to a Node.js API backend. The frontend handles UI rendering while the backend manages database operations, authentication, and business logic.
- Application divided into small, independent services
- Each service handles a specific business function (auth, payments, search)
- Services communicate via APIs (REST, gRPC, message queues)
- Example: An e-commerce platform split into: User Service (authentication/profiles), Product Service (catalog/inventory), Order Service (cart/checkout), Payment Service (transactions), Notification Service (emails/SMS). Each service has its own database and can be deployed independently.
- Single Point of Failure: A compromise in one module can impact the entire application
- Difficult to Patch: Updates require redeploying the full application, increasing downtime and risk
- No Isolation: Vulnerabilities in one feature can expose the entire system and all data
- API Exposure: Backend APIs may lack proper authentication or authorization checks
- Client-Side Trust: Validation done on the client can be bypassed, leading to manipulation of requests
- Session Management Risks: Susceptible to session hijacking, replay attacks, or unauthorized session access
- Expanded Attack Surface: Many independent services mean more endpoints and potential vulnerabilities
- Inter-Service Trust: Services may implicitly trust each other, creating risks if one service is compromised
- Distributed Authorization: Inconsistent access control across services can allow unauthorized access to data or functionality
Definition: Client-side components that run in the user's browser.
Technologies:
- HTML: Structure and content
- CSS: Styling and layout
- JavaScript: Interactivity and dynamic behavior
- Frameworks: React, Vue, Angular, Svelte
Responsibilities:
- Rendering user interface
- Client-side validation
- User experience (UX)
- Local storage and cookies
Definition: Server-side components that process requests and manage data.
Components:
| Layer | Technology Examples | Purpose |
|---|---|---|
| Operating System | Linux, Windows Server | Host environment |
| Web Server | Nginx, Apache, IIS | Handle HTTP connections |
| Application Framework | Django, Laravel, Express, Spring | Business logic |
| Database | MySQL, PostgreSQL, MongoDB | Data persistence |
Responsibilities:
- Business logic execution
- Authentication and authorization
- Data processing and validation
- API endpoints
- Session management
- Database operations
Understanding different testing methodologies helps you choose the right approach based on available information and testing goals.
- Access Level: No source code or internal documentation
- Approach: Test through public interface only
- Perspective: Simulate real external attacker
- Tools: Web scanners, fuzzing, manual testing
- Limitations: Limited visibility into logic, may miss complex vulnerabilities
- Best For: External penetration testing, compliance assessments
- Access Level: Full source code and documentation access
- Approach: Code review combined with testing
- Perspective: Complete understanding of architecture
- Tools: Static analysis tools (SAST), code review, manual testing
- Advantages: Find logic flaws, understand root causes, verify fixes
- Best For: Pre-release security audits, comprehensive assessments
- Access Level: Partial information (credentials, documentation, some code)
- Approach: Authenticated testing with limited internal knowledge
- Perspective: Insider threat or authenticated user perspective
- Tools: Mix of dynamic and static analysis
- Common Scenarios: User credentials provided, API documentation available
- Best For: Most professional security assessments
| Scenario | Recommended Approach | Reason |
|---|---|---|
| External penetration test | Blackbox | Mimics real attacker without inside knowledge |
| Pre-release security audit | Whitebox | Maximum vulnerability coverage |
| Post-authentication testing | Greybox | Test authenticated user attack surface |
| Bug bounty programs | Most of the time Blackbox | Limited access, public perspective |
| SDLC integration | Whitebox | Early detection in development |
i made a small challenge you can find it here challenge
- MDN Web Docs — Comprehensive documentation for HTTP, HTML, CSS, and JavaScript
- PortSwigger Web Security Academy — Learn about vulnerabilities and practice exploitation techniques (arguably the best resource)
- TryHackMe — Interactive learning platform with numerous hands-on labs
- HackTheBox Academy — Structured learning paths with practical exercises
- Practice using cURL to fetch pages and inspect headers
- Use Browser DevTools to analyze different websites
- Install and explore Burp Suite Community Edition
- Install and explore FFUF
- https://academy.hackthebox.com/module/details/35
- https://academy.hackthebox.com/module/details/110
- https://tryhackme.com/room/websecurityessentials
- https://tryhackme.com/room/httpindetail
- https://play.picoctf.org/practice/challenge/142?category=1&page=1&search=who%20are
End of Session 01 Content
Stay curious, and keep working hard!