Ethical Hacking Lesson 36 – Web Architecture | Dataplexa

Web Hacking & Real World · Lesson 36

Web Architecture

Before attacking web applications, you need to understand exactly how they work — how a browser communicates with a server, what happens between clicking a link and seeing a page, and where in that chain the vulnerabilities that fill the next nine lessons actually live.

Why web security is its own discipline

The techniques in Section III targeted operating systems, network protocols, and infrastructure. Web application security targets something different — the logic of software that developers write, the trust boundaries that applications enforce, and the assumptions baked into HTTP that were never designed with security in mind.

HTTP was designed in 1989 to share academic documents. The authentication, session management, input validation, and access control requirements of a modern banking application were nowhere in the original design. Every web vulnerability in the next nine lessons traces back to that fundamental gap — trying to build secure, stateful, authenticated applications on top of a protocol that was designed to be simple, stateless, and open.

The HTTP request-response cycle

Everything in web security starts with understanding what actually travels between a browser and a server. When you type a URL and press Enter, a carefully structured HTTP request goes to the server. The server processes it and sends back an HTTP response. That exchange — request and response — is the unit of interaction that web attacks manipulate.

The request contains far more information than most users realise. The method (GET, POST, PUT, DELETE) tells the server what action to perform. The path tells it which resource to act on. Headers carry authentication tokens, session cookies, browser information, and content negotiation preferences. The body — present in POST requests — carries form data, file uploads, and JSON payloads. Every one of these components can be manipulated by an attacker.

HTTP REQUEST — anatomy of a POST login request

        Request line
        POST
         /login 
        HTTP/1.1
      
          Headers
          Host:
           targetapp.com
        
          Cookie:
           PHPSESSID=abc123def456ghi789
        
          Content-Type:
           application/x-www-form-urlencoded
        
          Content-Length:
           38
        
          User-Agent:
           Mozilla/5.0 (X11; Linux x86_64)...
        
          Body
          username=admin&password=password123

Request line

Method + path + protocol version. Tells the server what to do and where. Attackers manipulate the method (GET→POST) and path (path traversal).

Headers

Metadata about the request. Cookie header carries session tokens — stealing these enables session hijacking. Host header manipulation enables virtual host confusion attacks.

Body

The payload — form data, JSON, file uploads. SQL injection, XSS, and command injection attacks are injected here. Never trusted on the server side.

HTTP responses — what the server sends back

Every HTTP response begins with a status code — a three-digit number that summarises the outcome of the request. Pen testers read status codes the way a doctor reads vital signs — they reveal the state of the application without needing to read the full response body. A 200 means success. A 302 means redirect. A 403 means the resource exists but access is denied. A 500 means the server threw an error — often a sign that something unexpected happened, which is frequently the result of a successful injection attempt.

HTTP STATUS CODES — what pen testers watch for

Code	Meaning	What it tells a pen tester
200 OK	Success	Request processed normally. Useful as a baseline — a login form returning 200 on failure (instead of 401) may be poorly designed.
301/302	Redirect	Redirects can bypass access controls if followed blindly. Open redirect vulnerabilities redirect to attacker-controlled URLs — used in phishing.
401	Unauthorised	Authentication required. Confirms the resource exists and is protected. Different from 403 — suggests valid credentials would grant access.
403	Forbidden	Resource exists but access denied. Confirms the path is valid — worth probing with different methods (PUT vs GET) or from different session contexts.
404	Not Found	Resource does not exist — or the application is deliberately returning 404 to hide 403s. Consistent 404s during directory enumeration confirm missing paths.
500	Server Error	Application threw an unhandled exception. Frequently triggered by injection payloads — a 500 where a 200 was expected suggests the input caused unexpected behaviour.

Response headers carry their own intelligence — the Server header announces what software is running and often its version, X-Powered-By reveals the backend language, and security headers like Content-Security-Policy, X-Frame-Options, and Strict-Transport-Security tell you immediately what protections the application has or has not implemented. Reading response headers is one of the fastest ways to assess an application's security posture before touching a single input field.

How web applications are structured

Modern web applications are not a single piece of software. They are a stack of components — each with its own attack surface — that must all work correctly for the application to be secure. A vulnerability in any layer of the stack is a vulnerability in the application.

Client — browser

HTML, CSS, JavaScript. Renders the interface. Handles user input. Sends requests. Attack surface: XSS, CSRF, clickjacking, client-side logic bypass.

Web server — nginx / Apache

Receives HTTP requests, serves static files, passes dynamic requests to the application. Attack surface: directory traversal, server misconfiguration, exposed admin interfaces, default pages.

Application layer — PHP / Python / Node.js

Business logic. Authentication and authorisation. Session management. Input processing. The richest attack surface — SQL injection, command injection, file upload vulnerabilities, broken access control, insecure deserialisation.

Database — MySQL / PostgreSQL / MongoDB

Stores application data, user credentials, session tokens, and business records. Attack surface: SQL injection grants direct database access, excessive privileges allow data exfiltration, weak credentials allow direct connection.

Infrastructure — OS, cloud, containers

The platform the application runs on. Misconfigured cloud storage buckets, exposed metadata endpoints, container escape vulnerabilities, and OS-level weaknesses from Section III all apply here.

Sessions and cookies — how HTTP fakes statefulness

HTTP is stateless — every request is independent and the server has no memory of previous requests. This creates an immediate problem for applications that need to remember who a user is across multiple requests. Sessions solve this problem: when a user authenticates, the server creates a session record and sends a session identifier to the browser in a cookie. The browser includes that cookie in every subsequent request, allowing the server to look up the session and know who is making the request.

The session cookie is therefore the key to the user's authenticated identity. Whoever holds the session cookie is, from the server's perspective, the user. This makes session cookies the most high-value target in web application attacks. Stealing a session cookie — through XSS, network interception, or log access — means taking over the authenticated session without ever knowing the user's password.

Cookies have security flags that affect how they are handled. The Secure flag ensures the cookie is only sent over HTTPS — not HTTP. The HttpOnly flag prevents JavaScript from reading the cookie — defeating most XSS-based cookie theft. The SameSite attribute controls whether the cookie is sent with cross-site requests — blocking most CSRF attacks. A cookie missing any of these flags has a specific, testable attack surface. Reading the Set-Cookie header in an application's response tells a pen tester immediately what protections the session management is missing.

Using browser developer tools for reconnaissance

Every browser includes built-in developer tools that expose the full HTTP exchange for every request made. For web pen testing, the Network tab is the starting point — it shows every request, its headers, its body, and the full server response. This is how you inspect what a login form actually sends, what cookies an application sets, what API endpoints a JavaScript-heavy application calls, and what security headers the server includes in its responses.

The developer tools Console tab reveals JavaScript errors that can point to insecure client-side logic, hardcoded API keys, and exposed internal endpoint paths. The Application tab shows all cookies, local storage, and session storage — with their flag settings visible. These three tabs alone can surface multiple findings before a single specialised tool is opened.

Network tab

All HTTP requests and responses. Filter by XHR to see API calls. Right-click any request to copy it as a curl command — useful for replaying requests from the terminal. The Response tab shows the full server reply including Set-Cookie headers with their flag attributes.

Console tab

JavaScript errors and console output. Look for hardcoded API keys, internal endpoint URLs, and error messages that reveal server-side behaviour. Developers who leave debug console.log() statements in production code regularly expose credentials and internal paths this way.

Application tab

All cookies with their attribute flags clearly visible — Secure, HttpOnly, SameSite. Local storage and session storage often contain JWT tokens, user IDs, and other data that applications store client-side. A JWT stored in localStorage (rather than an HttpOnly cookie) is readable by any JavaScript running on the page — including injected XSS payloads.

Burp Suite — the web pen tester's primary tool

Browser developer tools show you what requests are being made. Burp Suite lets you intercept, modify, and replay them. Burp sits between the browser and the server as an intercepting proxy — every request passes through it before reaching the server, and every response passes through it before reaching the browser. This interception capability is the foundation of web application testing.

The Burp Proxy intercepts requests for manual inspection and modification. The Repeater lets you send modified versions of any captured request and read the full response. The Intruder automates payload insertion for fuzzing and brute forcing. The Scanner (Pro only) passively and actively identifies vulnerabilities. The Decoder converts between encoding formats — URL encoding, Base64, HTML entities — which is essential when payloads need to bypass input filters that reject obvious attack strings.

Burp Community Edition is free and sufficient for the techniques covered in Lessons 37 through 43. The paid Pro version adds the automated scanner — useful for coverage in large applications but not necessary for understanding web security fundamentals. Install Burp Community from portswigger.net/burp/communitydownload and spend time getting comfortable with the proxy setup and Repeater before moving to the next lesson. PortSwigger's Web Security Academy — at portswigger.net/web-security — provides free hands-on labs for every web vulnerability covered in this section. It is the best free web security training available and is specifically designed to accompany Burp usage.

Teacher's Note: The single most important habit to build before starting web application testing is reading the full HTTP request and response for every action you take manually on the application. Do it in Burp, do it in browser developer tools — but build the discipline of seeing the raw exchange rather than just the rendered page. Every web vulnerability in the next eight lessons is visible in that raw exchange if you know what to look for.

Quiz

Up Next · Lesson 37

OWASP Top 10

The ten most critical web application security risks — what they are, how they are exploited, and why they appear so consistently across every type of web application.

← Previous Course Index Next →