RedTeam Nexus Labs
Module 03 · Lesson 05 // Networking for CTF

HTTP

Networking for CTF · CTF

Freereading · 10 min
On this page
  1. Overview
  2. Learning objectives
  3. Core concept
  4. How it works
  5. Practical example
  6. Cybersecurity relevance
  7. Common mistakes
  8. Key takeaways
  9. Check your understanding
LESSON

Overview

HTTP (HyperText Transfer Protocol) is the language of the web, and the web is where the majority of beginner-friendly CTF challenges live. Almost every "Web" challenge comes down to sending carefully crafted HTTP requests and reading the responses closely. Understanding the anatomy of an HTTP request and response — methods, headers, status codes, and cookies — is the single most useful networking skill for CTF web challenges.

This lesson dissects HTTP as a request/response protocol and shows how each part becomes a lever during authorized web exploration.

Learning objectives

  • Describe HTTP as a stateless request/response protocol.
  • Break an HTTP request and response into their component parts.
  • Recall the meaning of common methods and status-code families.
  • Explain the role of key headers and cookies.
  • Connect HTTP structure to inspecting and manipulating web traffic in CTFs.

Core concept

HTTP is a request/response protocol: a client (usually a browser or a tool) sends a request to a server, and the server returns a response. It runs on top of TCP — classically port 80 for HTTP and 443 for HTTPS (HTTP wrapped in TLS encryption).

HTTP is fundamentally stateless: each request is independent, and the server does not inherently remember previous requests from the same client. State (like "I am logged in") is layered on top using cookies and tokens. This statelessness is why sessions, cookies, and headers matter so much in web security — they carry the context the protocol itself does not.

How it works

An HTTP request has three parts:

  1. Request line — a method, a path, and the HTTP version, e.g. GET /admin HTTP/1.1.
  2. Headers — key/value metadata, e.g. Host:, User-Agent:, Cookie:, Content-Type:.
  3. Body (optional) — data sent to the server, common with POST/PUT (e.g. form fields or JSON).

Common methods:

  • GET — retrieve a resource (parameters usually in the URL).
  • POST — submit data to the server (data in the body).
  • PUT / DELETE — create/replace or remove a resource.
  • HEAD — like GET but returns headers only.
  • OPTIONS — ask which methods the server allows.

An HTTP response also has three parts:

  1. Status line — the version, a numeric status code, and a reason phrase, e.g. HTTP/1.1 200 OK.
  2. Headers — metadata like Server:, Set-Cookie:, Location:, Content-Type:.
  3. Body — the returned content (HTML, JSON, a file, etc.).

Status code families tell you what happened at a glance:

  • 1xx informational.
  • 2xx success (200 OK, 201 Created).
  • 3xx redirection (301, 302 Found with a Location: header).
  • 4xx client error (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found).
  • 5xx server error (500 Internal Server Error) — often interesting in CTFs because errors can leak information.

Cookies implement state: the server sends Set-Cookie: in a response, and the client returns the value in a Cookie: header on later requests, letting the server recognize the session.

Practical example

You are exploring an authorized web challenge at http://ctf.local. Instead of only clicking in a browser, you send a raw request to see exactly what the server says:

# Illustrative request/response against an authorized target
$ curl -i http://ctf.local/admin

HTTP/1.1 302 Found
Server: nginx (example)
Location: /login
Set-Cookie: session=guest; Path=/
Content-Length: 0

What this tells you:

  • 302 Found with Location: /login — the /admin page is redirecting you to a login. The server is protecting /admin behind authentication.
  • Set-Cookie: session=guest — the server assigned you a guest session. That cookie value is now something you can inspect and reason about. If a challenge is about broken access control, you might explore how the session determines what you can see.

You then request the login page, submit credentials via a POST with a body, and watch for a new Set-Cookie and a 200 or another 302. Reading headers and status codes — not just the rendered page — is how you understand what the application is really doing. Every request stays within the single authorized site.

Cybersecurity relevance

  • Web challenges are HTTP challenges. Injection, broken access control, authentication flaws, SSRF, and more are all delivered and observed through HTTP requests and responses.
  • Manual request crafting (with a proxy or command-line client) lets you send requests a browser never would — changing methods, headers, cookies, and bodies to probe behavior. This is the core skill of web testing.
  • Status codes and headers are evidence. A 403 vs 401 vs 302, a leaked Server version, a verbose 500 error, or a revealing Set-Cookie all guide your next move.
  • State and sessions: because HTTP is stateless, cookies/tokens carry authentication. Understanding this is prerequisite to session and access-control topics.
  • Defense: developers set security headers, scope cookies (HttpOnly, Secure), and avoid leaking information in errors. Reading HTTP fluently helps both sides.

Common mistakes

  • Only using a browser and never inspecting the raw request/response, missing headers, cookies, and redirects.
  • Ignoring status codes, e.g. treating a 302 redirect as a 200 success or overlooking an information-rich 500.
  • Forgetting HTTP is stateless and being confused about how the server "knows" who you are (it is the cookie/token).
  • Overlooking response headers like Set-Cookie, Location, or Server that reveal how the app behaves.
  • Confusing GET and POST — where parameters live (URL vs body) changes how you interact.

Key takeaways

  • HTTP is a stateless request/response protocol over TCP (80 for HTTP, 443 for HTTPS).
  • Requests have a method + path + version, headers, and an optional body; responses have a status line, headers, and a body.
  • Status-code families (1xx–5xx) and headers (Set-Cookie, Location, Server) are key evidence during web recon.
  • Cookies/tokens supply the state HTTP lacks; inspecting and manipulating raw HTTP is the core skill for CTF web challenges.

Check your understanding

  • What are the three parts of an HTTP request and the three parts of an HTTP response?
  • If a request to /admin returns 302 Found with Location: /login, what is the server doing and what would you look at next?
  • HTTP is stateless, so how does a server recognize that a series of requests all belong to the same logged-in user?
FINISH THIS LESSON

Sign in to save your progress.

PreviousDNSNextpacket basics