Web Application Security Fundamentals #03: Arsitektur Web & HTTP Request-Response Model

HTTP adalah protocol yang underpin web. Memahami HTTP anatomy, headers, cookies, dan same-origin policy adalah foundation untuk memahami vulnerabilities seperti XSS, CSRF, dan session hijacking.

Tujuan Pembelajaran

Setelah modul ini, Anda dapat:

• Menjelaskan HTTP request/response structure
• Memahami HTTP status codes (2xx, 3xx, 4xx, 5xx)
• Understand cookies vs localStorage vs sessionStorage
• Memahami same-origin policy & CORS
• Use developer tools untuk inspect traffic
• Use Burp Suite untuk intercept & modify requests

HTTP Request Anatomy

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Content-Length: 42

{"email":"user@example.com","password":"secret123"}

Breakdown:

• Verb (Method): POST (create), GET (read), PUT (update), DELETE, PATCH
• Path: /api/users (endpoint)
• Protocol: HTTP/1.1 (or HTTP/2, HTTP/3)
• Headers: Metadata about request (authentication, content type, etc)
• Body: Data being sent (optional untuk GET)

HTTP Response Anatomy

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 256
Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax
Cache-Control: no-store

{"id":123,"email":"user@example.com","name":"John Doe"}

Breakdown:

• Status Code: 200 (success), 400 (client error), 500 (server error)
• Headers: Metadata about response (content type, cookies, cache, security)
• Body: Data being returned

HTTP Status Codes

Cookies vs Storage APIs

Cookies

// Server sets cookie
Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax

// Browser automatically sends with every request
GET /api/users
Cookie: session_id=abc123

// JavaScript cannot access (if HttpOnly)
console.log(document.cookie);  // Empty if HttpOnly flag set

Cookie Flags:

• HttpOnly: Cookie not accessible from JavaScript (prevent XSS theft)
• Secure: Cookie only sent over HTTPS (prevent eavesdropping)
• SameSite: Cookie only sent on same-site requests (prevent CSRF)
• Max-Age: How long cookie lives (session vs persistent)
• Domain: Which domains can access cookie
• Path: Which paths can access cookie

LocalStorage vs SessionStorage

// ❌ NOT recommended for sensitive data (accessible from XSS)
localStorage.setItem('auth_token', 'secret123');

// Better: If must use storage, use with caution
const token = localStorage.getItem('auth_token');

// ❌ VULNERABLE: Token in localStorage, accessible from XSS
fetch('https://api.example.com/users', {
  headers: { 'Authorization': `Bearer ${token}` }
});

Comparison:

Recommendation:

• ✅ Use HttpOnly cookies for authentication tokens
• ❌ Avoid localStorage/sessionStorage for sensitive data

Same-Origin Policy

Origin = Combination of protocol://domain:port

https://example.com:443         ← Same origin
https://example.com/page1       ← Same origin
https://example.com/page2       ← Same origin

http://example.com              ← DIFFERENT origin (http vs https)
https://example.com:8080        ← DIFFERENT origin (port 443 vs 8080)
https://sub.example.com         ← DIFFERENT origin (subdomain)
https://attacker.com            ← DIFFERENT origin (domain)

SOP Rule: JavaScript dari origin A tidak dapat akses data dari origin B.

// ❌ BLOCKED by SOP (different origin)
fetch('https://attacker.com/steal')  // CORS error if server doesn't allow

// ✅ ALLOWED (same origin)
fetch('/api/users')  // Same origin, no issue
fetch('https://example.com/api')  // Same origin

CORS (Cross-Origin Resource Sharing)

CORS = Mechanism untuk allow cross-origin requests safely.

Vulnerable CORS Configuration

// ❌ VULNERABLE - Allow any origin
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

// Attacker can make requests from attacker.com
// Browser will send credentials (cookies) with request

Secure CORS Configuration

// ✅ SECURE - Whitelist specific origins
Access-Control-Allow-Origin: https://trusted-partner.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true  // Allow cookies only for trusted domains

Testing with curl

# Simple GET
curl https://api.example.com/users

# POST with data
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"email":"test@example.com"}'

# Include authentication
curl -H "Authorization: Bearer TOKEN" \
  https://api.example.com/users

# Follow redirects
curl -L https://example.com/old-url

# See response headers
curl -i https://api.example.com/users

# See request & response
curl -v https://api.example.com/users

Inspecting Traffic with Browser DevTools

Chrome DevTools

1. Open DevTools: F12
2. Go to "Network" tab
3. Reload page or make request
4. Click on request to inspect:
   • Headers: Request/response headers
   • Preview: Formatted response body
   • Response: Raw response
   • Cookies: Request cookies

Firefox Developer Tools

1. Open DevTools: F12
2. Go to "Network" tab
3. Same as Chrome DevTools

Burp Suite Basics

1. Configure browser proxy: 127.0.0.1:8080
2. Open Burp Suite, go to "Proxy" tab
3. Enable proxy intercept
4. Navigate website normally
5. Burp intercepts every request
6. Inspect & modify request
7. Forward or drop request
8. Analyze response

Example: Modify price before sending

1. User clicks "Buy product for $100"
2. Browser prepares request:
   POST /purchase
   {"product_id":123,"amount":100}

3. Burp intercepts request
4. Hacker modifies:
   POST /purchase
   {"product_id":123,"amount":1}

5. Server processes $1 instead of $100
   (VULNERABLE if server doesn't validate amount!)

Testing Checklist

• [ ] HTTP request/response headers inspected
• [ ] Cookies examined for HttpOnly/Secure/SameSite flags
• [ ] Same-origin policy understood
• [ ] CORS configuration reviewed (not * with credentials)
• [ ] Status codes correct (200 for success, 4xx for client error, 5xx for server error)
• [ ] Redirects working properly (prevent open redirect)
• [ ] Can modify request (test for client-side vs server-side validation)

Kesimpulan

HTTP adalah stateless protocol. Cookies, tokens, sessions digunakan untuk maintain state across requests. Understanding HTTP anatomy adalah prerequisite untuk understanding web vulnerabilities.

Modul berikutnya (#04) membahas OWASP Top 10:2025 — the most common vulnerability categories.

Baca Berikutnya: #04 - OWASP Top 10:2025 & Risk Assessment