GET aHEAD picoCTF 2021 Solution

Description

1. Step 1

   Send an HTTP HEAD request

   Observation

   I noticed the challenge title is a pun on the HTTP HEAD method and the description mentions an unfamiliar HTTP method transmitting the flag, which suggested the flag was hidden in a response header accessible only via a HEAD request using 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 is placed in an HTTP response header, not the page body or HTML source. Browsers display only the rendered content and source markup - response headers are invisible unless you open Developer Tools (F12 > Network tab) and select the request. Viewing source skips headers entirely, so the flag will never appear there.

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

   A GET request returns the response body, not just the headers that a HEAD request produces. While curl does receive all response headers on a GET as well, it prints only the body by default. Adding -v (verbose) to a GET would show headers, but -I is the correct shorthand for sending an HTTP HEAD request, which is what the challenge specifically requires to trigger the server-side code 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.