GET aHEAD picoCTF 2021 Solution

Description

1. Step 1Send an HTTP HEAD request

   Observation

   The title puns on the HTTP HEAD method, and the description mentions an unfamiliar method carrying the flag. So the flag sits in a response header, reachable with a HEAD request via curl -I.

   Use curl with the -I flag to send an HTTP HEAD request to the challenge URL. The -v flag shows the full response including headers. The flag is returned in a custom response header that is invisible to a normal GET request in a browser.

   bash

   curl -I -v http://<server>/

   Copied!

   Expected output

   < HTTP/1.1 200 OK
   < flag: picoCTF{...}

   What didn't work first

   Tried: Open the challenge URL in a browser and inspect the page source looking for the flag.

   The flag lives in an HTTP response header, not the page body or the HTML source. A browser shows rendered content and markup; response headers stay invisible unless you open Developer Tools and select the request in the Network tab. View Source skips headers entirely, so the flag never shows up there.

   Tried: Use curl without the -I flag (plain GET request) and search the response body for the flag.

   A GET returns the response body, where a HEAD returns headers alone. curl does receive all the headers on a GET, but prints only the body by default, and -v would reveal them. Still, -I is the shorthand for an actual HEAD request, which is what triggers the server-side path that injects the flag header.

   Learn more

   HTTP HEAD is identical to GET but instructs the server to return only the response headers - no body. It is designed for efficiency: checking if a resource exists, reading its Content-Length or Last-Modified date, or cache validation without downloading the content. All servers are required by the HTTP spec to return the same headers for HEAD as they would for GET.

   In this challenge, the flag is placed in a custom response header (e.g., flag: or X-Flag:). Browsers only display page content, not response headers in normal view. The curl -v flag (verbose) prints the full request and response headers to stderr, making the custom header visible.

   Other HTTP methods worth knowing for CTF web challenges: OPTIONS (lists allowed methods), PUT (upload a resource), DELETE (delete a resource), and TRACE (echo the request back - useful for detecting header injection). Most web servers restrict which methods are allowed via configuration.

   Custom HTTP response headers are a common place to hide flags in web CTF challenges because browsers do not display them in normal page view. You need Developer Tools (F12 > Network tab > select a request > Headers) or a command-line tool like curl -v or curl -I to see them. The -I flag is shorthand for --head, which sends an HTTP HEAD request and prints only the response headers.

   Security implications of misconfigured HTTP methods: Leaving PUT or DELETE enabled on a web server without authentication can allow attackers to upload arbitrary files or delete content. The TRACE method can facilitate Cross-Site Tracing (XST) attacks by reflecting cookies in the response, bypassing the HttpOnly flag in some older browser configurations. Best practice is to configure web servers to only allow GET, POST, and HEAD unless other methods are explicitly needed.

   Reading headers with other tools: Python's requests library gives access to response.headers as a dictionary, making it easy to script header inspection: import requests; r = requests.head(url); print(dict(r.headers)). Browser extensions like "ModHeader" or "Requestly" can also modify and inspect headers interactively during web CTF challenges.

Flag

HTTP HEAD returns only headers with no response body - useful for checking responses efficiently; here the flag is smuggled in a response header.