Web applications are vastly more complex and pervasive than most people realize. Today, they serve as the front door for critical business logic, financial transactions, and sensitive personal data. From a cybersecurity perspective, this makes them one of the primary target vectors for attackers worldwide.
To secure or ethically hack web applications, you must master the fundamental protocols, mechanisms, and tools that govern the web. This guide walks you through web application architecture, HTTP/HTTPS protocols, session management, security policies, and hands-on proxy manipulation with Burp Suite.
1. Introduction to Web Applications
A web application is a client-server computer program that runs inside a web browser. Unlike traditional static websites that merely display HTML documents, modern web applications rely on complex server-side scripts (e.g., Node.js, Python, PHP) interacting with databases, APIs, and client-side JavaScript execution frameworks.
+----------------+ HTTP / HTTPS +-------------------+
| Client / | <=======================> | Web Application |
| Web Browser | Request / Response | Server & DB |
+----------------+ +-------------------+From an attack perspective, every input point—URL parameters, headers, cookies, and POST bodies—represents a potential entry point for exploitation (such as SQL Injection, Cross-Site Scripting, or Broken Access Control).
2. HTTP/HTTPS Protocol Basics
The Hypertext Transfer Protocol (HTTP) is an application-layer protocol that powers communication across the World Wide Web. HTTP is inherently stateless, meaning each request sent to the server is processed independently without implicit memory of previous requests.
2.1. HTTP Requests
An HTTP request is sent by the client (browser) to request a resource or perform an action on the server.
Structure of an HTTP Request:
- Request Line: Contains the HTTP Method (Verb), URI path, and HTTP version.
- Request Headers: Key-value pairs providing metadata about the client and request.
- Message Body (Optional): Data sent to the server (e.g., form submissions or JSON payloads).
Practical HTTP GET Request Example:
GET /login.php?user=admin HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml
Accept-Language: en-US,en;q=0.9
Connection: closeCommon HTTP Methods:
- GET: Retrieves data from a server. Should not alter server state or carry sensitive data in the query string.
- POST: Submits data to the server (often resulting in state change or record creation).
- PUT: Replaces or updates a targeted resource.
- DELETE: Removes a specified resource.
- OPTIONS: Queries the server for allowed HTTP methods on a targeted resource.
2.2. HTTP Responses
After receiving and processing an HTTP request, the web server returns an HTTP response back to the client.
Structure of an HTTP Response:
- Status Line: HTTP version, numerical Status Code, and Reason Phrase.
- Response Headers: Metadata detailing server characteristics, content type, and security policies.
- Response Body: HTML markup, JSON payloads, images, or raw binary data.
Practical HTTP Response Example:
HTTP/1.1 200 OK
Date: Mon, 03 Aug 2026 12:00:00 GMT
Server: Apache/2.4.50 (Unix)
Content-Type: text/html; charset=UTF-8
Content-Length: 184
Set-Cookie: PHPSESSID=d9a8c7b6a54321; path=/; HttpOnly; Secure
<!DOCTYPE html>
<html>
<head><title>Dashboard</title></head>
<body><h1>Welcome back, Admin!</h1></body>
</html>Primary HTTP Status Code Categories:
- 1xx (Informational): Request received, continuing process.
- 2xx (Success): Action successfully received, understood, and accepted (e.g., 200 OK, 201 Created).
- 3xx (Redirection): Further action needed to complete request (e.g., 301 Moved Permanently, 302 Found).
- 4xx (Client Error): Request contains bad syntax or cannot be fulfilled (e.g., 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found).
- 5xx (Server Error): Server failed to fulfill an apparently valid request (e.g., 500 Internal Server Error, 502 Bad Gateway).
2.3. HTTPS (HTTP Secure)
HTTP transmits data in cleartext, exposing traffic to Man-in-the-Middle (MitM) eavesdropping and tampering. HTTPS encapsulates standard HTTP traffic inside an encrypted TLS (Transport Layer Security) tunnel.
HTTP Traffic: [ Client ] ------ Cleartext HTTP -------> [ Server ]
HTTPS Traffic: [ Client ] === TLS Encrypted Tunnel ===> [ Server ]Key Security Guarantees of HTTPS:
- Encryption: Data cannot be read in transit.
- Data Integrity: Data cannot be altered without detection.
- Authentication: Digital certificates verify the authentic identity of the web server.
3. Deep Dive into HTTP Cookies
Because HTTP is a stateless protocol, servers use HTTP Cookies—small pieces of data stored in the user’s browser—to persist information across multiple requests.
3.1. Cookie Protocol & Workflow
- Issue: The server sends a response header: Set-Cookie: session_id=xyz123.
- Store: The browser stores the cookie locally.
- Transmit: On subsequent requests to that domain, the browser automatically attaches: Cookie: session_id=xyz123.
Client Server
| |
| -------------- 1. POST /login HTTP/1.1 -------------> |
| |
| <--- 2. HTTP/1.1 200 OK (Set-Cookie: SID=998877) ---- |
| |
| -------------- 3. GET /dashboard HTTP/1.1 -----------> |
| (Cookie: SID=998877) |3.2. Cookie Attributes & Security Settings
Security flags within the Set-Cookie response header directly dictate how browsers handle and expose cookies.
Set-Cookie: token=a8f9c2e1; Domain=example.com; Path=/app; Expires=Wed, 21 Oct 2026 07:28:00 GMT; Secure; HttpOnly; SameSite=Strict| Cookie Attribute | Function & Security Impact |
|---|---|
| Domain | Specifies which hosts can receive the cookie (e.g., .example.com includes all subdomains). Unrestricted domain scopes risk cross-subdomain leaking. |
| Path | Restricts the cookie to a specific URL path hierarchy (e.g., /admin). |
| Expires / Max-Age | Defines the lifespan of the cookie. If omitted, the cookie is treated as a non-persistent Session Cookie and destroyed when the browser closes. |
| HttpOnly | Critical Security Flag. Prevents client-side scripts (e.g., JavaScript) from accessing document.cookie. Mitigates cookie-stealing via Cross-Site Scripting (XSS). |
| Secure | Restricts cookie transmission exclusively over encrypted HTTPS connections. Prevents cleartext leaking over unencrypted HTTP. |
| SameSite | Protects against Cross-Site Request Forgery (CSRF). Options: Strict (never sent in cross-site requests), Lax (sent with top-level navigations), or None. |
4. Sessions & Session Management
Authentication mechanisms use Sessions to track user identity after a successful login.
4.1. How Web Sessions Work
Since servers cannot keep an open TCP connection for every user, they assign a unique, unpredictable identifier called a Session ID.
- User submits credentials via POST /login.
- Server validates credentials and creates a session record in its backend state database.
- Server issues the Session ID to the browser.
- The client presents this Session ID on every request to prove authentication.
4.2. Session Storage Mechanisms: Cookies vs GET Requests
| Storage Mechanism | Method | Penetration Testing Risk Assessment |
|---|---|---|
| Session Cookies | Header-based transmission (Cookie: SID=123) | Standard & Secure: Managed automatically by browser security contexts. Risk reduced if HttpOnly and Secure attributes are applied. |
| GET Requests | URL-based transmission (/profile?session_id=123) | High Vulnerability Risk: URL session parameters leak into web server logs, proxy logs, browser history, and HTTP Referer headers when clicking external links. |
Penetration Testing Note: Session tokens passed via GET parameters are prone to Session Fixation and Session Hijacking. Always recommend moving authentication tokens into secure, HttpOnly HTTP response headers.
5. Same-Origin Policy (SOP)
The Same-Origin Policy (SOP) is a fundamental web browser security mechanism that restricts scripts on one origin from interacting with or reading sensitive data from another origin.
5.1. Definition of an Origin
An Origin is strictly defined by three components:
If any of these three elements differ, the request is considered Cross-Origin.Origin Verification Matrix (Target Base: http://example.com/dir/page.html):
Target URL Same Origin? Reason http://example.com/dir/other.html Yes Scheme, Host, and Port (80) match. http://example.com/dir2/index.html Yes Path changes do not alter Origin. https://example.com/dir/page.html No Different Protocol (https vs http). http://sub.example.com/page.html No Different Host (sub.example.com). http://example.com:8080/page.html No Different Port (8080 vs 80). 5.2. HTML Tags & SOP Exceptions
SOP primarily blocks cross-origin reading of data via JavaScript (e.g., fetch() or XMLHttpRequest), but browsers permit certain cross-origin write and embedding behaviors via specific HTML tags:
HTML tags:
- <img> / <script> / <link>: Allowed to load and render cross-origin assets (e.g., images, JavaScript libraries, CSS files).
- <iframe>: Allowed to display external sites, but JavaScript in the host window cannot directly access or read the DOM contents inside the <iframe> unless explicitly allowed via cross-document messaging or CORS headers.
6. Practical Tooling: Hands-On with Burp Suite
Burp Suite (developed by PortSwigger) is the industry-standard toolkit used by ethical hackers and security consultants to conduct web application security testing.
6.1. Intercepting Proxies Explained
An intercepting proxy sits as an intermediary between the web browser and the web application target.
- +—————-+ Intercepted HTTP +——————+ Forwarded HTTP +——————–+
- | Web Browser | =======================> | Burp Suite | =====================> | Target Web Server |
- | (User Agent) | <======================= | (Proxy Listener) | <===================== | (Remote Endpoint) |
- +—————-+ +——————+ +——————–+
By routing all traffic through an intercepting proxy, security testers can inspect, stop, modify, and replay raw HTTP traffic in real-time before it hits the target server.
6.2. Burp Proxy Configuration & Setup
- Configure Proxy Listener: Set Burp Proxy to listen on 127.0.0.1:8080.
- Configure Browser: Direct browser network traffic through 127.0.0.1:8080 (or use Burp’s embedded browser).
- Install Burp CA Certificate: Import Burp’s Root Certificate (PortSwigger CA) into the browser’s Certificate Store to allow SSL/TLS inspection without security warnings.
6.3. Hands-On Workflow: Burp Proxy & Burp Repeater
Step 1: Intercepting Traffic
Enable Intercept is on in the Burp Proxy tab. Submit a action in the browser (e.g., logging in). Burp holds the raw packet, allowing you to alter parameter values before sending it to the server.
POST /login HTTP/1.1
Host: target-app.local
Content-Type: application/x-www-form-urlencoded
username=admin’ OR ‘1’=’1&password=password123
Step 2: Utilizing Burp Repeater
Right-click any captured request and select Send to Repeater (or press Ctrl+R).
Burp Repeater allows security testers to:
- Tweak parameters, headers, or payloads manually.
- Re-issue requests repeatedly to study server responses line-by-line.
- Rapidly test for security bugs such as SQL Injection, Cross-Site Scripting (XSS), IDOR (Insecure Direct Object Reference), and Authentication Bypass.
Conclusion & Core Takeaways
- Understand HTTP: Web security starts with understanding headers, verbs, and status codes.
- Harden Cookie Security: Always apply HttpOnly, Secure, and strict SameSite flags to sensitive user tokens.
- Enforce Same-Origin Rules: Maintain clear boundary controls against cross-site exploitation vectors.
- Master Intercepting Proxies: Tools like Burp Suite are essential for inspecting traffic and discovering business logic flaws.
Leave a Reply