Lab 16: Web Security Basics

🎯 Objective

Analyze HTTP request/response headers, understand security headers, explore cookie security attributes, demonstrate the Same-Origin Policy, and create a simple HTTP server that implements security best practices.

📚 Background

The web is the largest attack surface in modern computing. Every web application handles user input, authenticates users, stores data, and communicates over HTTP — each step presenting potential vulnerabilities. Understanding HTTP at a protocol level is essential for both building secure applications and testing existing ones.

HTTP security headers are directives sent by the web server to the browser that control how the browser handles the page content. Headers like Content-Security-Policy (CSP), HTTP Strict Transport Security (HSTS), and X-Frame-Options dramatically reduce the risk of XSS, protocol downgrade attacks, and clickjacking. Yet many websites fail to implement them correctly or at all.

Cookies are the primary mechanism for maintaining session state in HTTP (which is inherently stateless). Cookie attributes like HttpOnly, Secure, and SameSite are critical security controls that prevent common attacks like XSS-based cookie theft, MITM attacks on session cookies, and CSRF attacks.

⏱️ Estimated Time

45 minutes

📋 Prerequisites

  • Basic understanding of HTTP

  • Lab 07: SSL/TLS (helpful)

🛠️ Tools Used

  • curl — HTTP client

  • python3 — web server and analysis

  • openssl — HTTPS

🔬 Lab Instructions

Step 1: HTTP Request/Response Analysis with curl

📸 Verified Output:

💡 What this means: Lines starting with > are the request (what you send); lines with < are the response (what the server returns). The Host header tells the server which website you want (multiple sites can share an IP via virtual hosting).

Step 2: Analyze HTTP vs HTTPS Security Headers

📸 Verified Output:

💡 What this means: These headers are free to implement and dramatically improve security. CSP alone can prevent 90% of XSS attacks by controlling which scripts are allowed to run. Check your sites at securityheaders.com for a free automated scan.

📸 Verified Output:

💡 What this means: Adding Secure; HttpOnly; SameSite=Strict to all session cookies is a one-line code change that prevents session hijacking via MITM, XSS cookie theft, and CSRF attacks. Every web application should implement all three.

Step 4: Same-Origin Policy Demo

📸 Verified Output:

💡 What this means: SOP is a foundational browser security mechanism that prevents malicious sites from reading your banking cookies or making unauthorized API calls. XSS attacks are so dangerous precisely because they execute code in the legitimate origin, bypassing SOP.

Step 5: Create a Secure HTTP Server

📸 Verified Output:

💡 What this means: These security headers are straightforward to implement — just a few lines of code in your server configuration. They give you substantial protection against XSS, clickjacking, MIME sniffing, and other browser-based attacks for free.

Step 6: Common Web Vulnerabilities Quick Demo

📸 Verified Output:

💡 What this means: XSS, CSRF, and clickjacking are preventable with proper output encoding, cookie attributes, and security headers. Most web frameworks have built-in protections — understand what they are and make sure they're not accidentally disabled.

Step 7: Check Real Website Security Headers

📸 Verified Output:

💡 What this means: GitHub implements all recommended security headers — it's a good reference for what a well-secured site looks like. Check your own applications at securityheaders.com for a free, automated grade.

Step 8: Security Checklist for Web Applications

📸 Verified Output:

💡 What this means: This checklist covers the most impactful web security controls. Use it as a starting point for security reviews of your applications. Many items are one-line configuration changes that prevent entire classes of attacks.

✅ Verification

🚨 Common Mistakes

  • Missing HttpOnly on session cookies: Without HttpOnly, any XSS can steal session tokens

  • CORS wildcard (*): Access-Control-Allow-Origin: * on authenticated endpoints is dangerous

  • No CSP: Sites without Content-Security-Policy are vulnerable to XSS attacks

  • HTTP for sensitive pages: Any form with credentials must use HTTPS

  • Revealing server version: Server: Apache/2.4.51 tells attackers exactly what to exploit — hide it

📝 Summary

  • HTTP security headers (CSP, HSTS, X-Frame-Options) are free, simple to implement, and prevent entire vulnerability classes

  • Cookie attributes (Secure, HttpOnly, SameSite) protect session tokens from MITM, XSS theft, and CSRF

  • Same-Origin Policy is the browser's built-in security mechanism; XSS bypasses it by executing in the legitimate origin

  • Output encoding (HTML-escaping user input) is the primary XSS defense; parameterized queries are the primary SQLi defense

  • Regular audits using tools like securityheaders.com, SSL Labs, and Mozilla Observatory maintain security posture

🔗 Further Reading

Last updated