Web Fundamentals

HTTP — The Protocol Under Everything

HTTP (HyperText Transfer Protocol) is a request/response protocol. Client sends a request, server returns a response. Stateless — each request is independent.

HTTP Request Structure

POST /api/login HTTP/1.1
Host: target.com
Content-Type: application/json
Authorization: Bearer eyJhbGc...
Cookie: session=abc123
User-Agent: Mozilla/5.0 ...
Content-Length: 42

{"username": "admin", "password": "hunter2"}

The blank line separates headers from the body. The body is only present on POST, PUT, and PATCH requests.

HTTP Response Structure

HTTP/1.1 200 OK
Content-Type: application/json
Set-Cookie: session=new_token; HttpOnly; Secure
X-Content-Type-Options: nosniff
Content-Length: 28

{"status": "authenticated"}

HTTP Methods

HTTP Status Codes

HTTPS and TLS

HTTPS = HTTP + TLS (Transport Layer Security). TLS provides:

• Encryption — data is unreadable to network observers
• Authentication — server certificate proves identity
• Integrity — data cannot be modified in transit

Certificate Chain

TLS Attack Surface:

• Expired/self-signed certificates > user trust issues
• Weak cipher suites (RC4, DES, export ciphers)
• TLS 1.0/1.1 > BEAST, POODLE attacks
• Certificate pinning bypass in mobile apps

# Check TLS certificate details
openssl s_client -connect target.com:443 </dev/null
openssl s_client -connect target.com:443 </dev/null 2>/dev/null | openssl x509 -noout -text

# testssl.sh — comprehensive TLS audit
testssl.sh target.com

HTTP Headers — The Security Controls Layer

Headers control browser behaviour, caching, authentication, and security policies.

Security Headers (What Good Looks Like)

Request Headers That Matter

Cookies — Session Management

Cookies are key-value pairs the server sets in the browser. Every subsequent request includes them automatically.

Cookie Flags

# Check cookies with curl
curl -c cookies.txt -b cookies.txt -L https://target.com/login \
  -d "user=admin&pass=admin" -v 2>&1 | grep -i "set-cookie"

Same-Origin Policy (SOP)

SOP is the browser's core security boundary. A page from https://attacker.com cannot read responses from https://bank.com — even if the victim's browser is authenticated to the bank.

Origin = scheme + hostname + port

SOP blocks JavaScript from reading cross-origin responses. It does not block cross-origin requests from being sent (which is why CSRF is possible).

CORS — Controlled SOP Relaxation

CORS (Cross-Origin Resource Sharing) lets a server explicitly permit cross-origin requests.

CORS Misconfigurations:

# Dangerous — reflects Origin header back:
Access-Control-Allow-Origin: https://attacker.com
Access-Control-Allow-Credentials: true

# Wildcard + credentials (browsers block this, but it reveals intent):
Access-Control-Allow-Origin: *

URL Structure — Every Component Matters

• Credentials in URL — logged in server logs, browser history, Referer headers. Never.
• Path traversal — ../../../etc/passwd in path parameters
• Query parameters — prime injection point (SQLi, XSS, SSRF)
• Fragment — never sent to server, only in browser

HTTP/2 and HTTP/3

HTTP/2 introduces new attack surface: request smuggling (H2.CL, H2.TE) where a front-end proxy and back-end server disagree on request boundaries.

Operational Notes

• Burp Suite Proxy sits between your browser and the target. Every HTTP/HTTPS request passes through it. This is your primary tool for web testing.
• `curl -v` shows full request and response headers. Use it to replicate Burp requests from the terminal.
• HTTP/2 downgrade — some servers accept HTTP/1.1 and HTTP/2. Try both. Some protections only apply to one.
• Parameter pollution — send the same parameter twice (?id=1&id=2). Different frameworks pick different values — can bypass input validation.

What to Read Next

• Web Application Analysis — put these fundamentals to work attacking OWASP Top 10 vulnerabilities
• How Authentication Works — sessions, cookies, and tokens as attack targets
• Reconnaissance — HTTP response headers and JavaScript files leak infrastructure details