Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 7

HTTP Request and Response Deep Dive

Recommended resources

Welcome to the next lesson in our journey into the hacker's mindset. In our last session, we saw how to establish a reliable connection to a target server using the TCP three-way handshake. That process is like dialing a phone number and waiting for someone to pick up. Now that the line is open, it's time to have the actual conversation.

This lesson focuses on the language of the web: the Hypertext Transfer Protocol (HTTP). Our goal is to deconstruct HTTP requests and responses, the fundamental building blocks of all web communication. You will learn to identify the key components—methods, status codes, headers, and the body—and understand what each part tells you. For a bug bounty hunter, being able to read and interpret this "conversation" is like being a spy who can decipher coded messages; it's an absolutely essential skill for finding vulnerabilities.

The Anatomy of a Web Conversation

HTTP is a simple, text-based request-response protocol that sits on top of the TCP connection we established in the previous lesson. The client (your browser) sends a request asking for a resource or action, and the server sends back a response.

Think of it like ordering at a restaurant:

  • You (client) make a request to the waiter (server).
  • Your request specifies what you want to do (the method, e.g., "I want to order") and what you want (the resource, e.g., "the steak").
  • You might add extra details (the headers, e.g., "medium-rare, no salt").
  • The waiter goes to the kitchen and comes back with a response.
  • The response includes a status (the status code, e.g., "The chef says okay") and your food (the body).

Let's break down the formal structure of these messages.

1. The HTTP Request

An HTTP request sent from a client to a server has three main parts:

  1. Request Line: This is the first line and it's crucial. It contains:
    • Method: The action to be performed. GET (retrieve data) and POST (submit data) are the most common.
    • Resource Path (URI): The specific file, endpoint, or resource on the server you want to access (e.g., /index.html, /api/v1/users).
    • HTTP Version: Usually HTTP/1.1.
  2. Headers: These are key-value pairs that provide additional information about the request. For example, the User-Agent header tells the server which browser you're using, and the Host header specifies the domain you're trying to reach.
  3. Body (Optional): This contains data being sent to the server. It's typically used with methods like POST (e.g., sending login credentials) or PUT (e.g., uploading a file). GET requests do not have a body.

2. The HTTP Response

After processing the request, the server sends back a response, which also has three parts:

  1. Status Line: The first line of the response. It contains:
    • HTTP Version:
    • Status Code: A three-digit code indicating the result of the request (e.g., 200 for success, 404 for not found).
    • Status Message: A human-readable phrase corresponding to the code (e.g., OK, Not Found).
  2. Headers: Key-value pairs from the server. The Content-Type header tells the browser what kind of data is in the body (e.g., text/html, application/json), and the Set-Cookie header is used to give the browser a cookie.
  3. Body (Optional): This is the main content of the response. If you requested a webpage, the body contains the HTML code. If you requested data from an API, it might contain JSON.

Seeing it in Action: Intercepting Traffic

Reading about these components is one thing; seeing them live is another. Professional bug bounty hunters use tools called "intercepting proxies," like Burp Suite, to sit between their browser and the internet. This allows them to view, modify, and analyze every single HTTP request and response.

The following video from HackerSploit provides an excellent, detailed walkthrough of a live HTTP conversation captured with a proxy.

Web App Pentesting - HTTP Headers & Methods

Watch these segments from the video "Web App Pentesting - HTTP Headers & Methods". The presenter uses Burp Suite to show you exactly what a real request and response look like.

First, watch the breakdown of an HTTP request. Pay close attention to headers like Host, User-Agent, and Cookie. The User-Agent can sometimes be used to trick a server into delivering a mobile version of a site, which might have different vulnerabilities. Next, watch the analysis of the corresponding HTTP response. Notice the Server and X-Powered-By headers. These directly tell you the web server software (e.g., Apache), backend language (e.g., PHP), and their versions. This is vital information for a hacker, as you can immediately look for known exploits for that specific software version.

Interpreting Server Feedback: HTTP Status Codes

The status code in a response is your primary feedback from the server. Understanding what they mean is critical for diagnosing how a web application behaves. They are grouped into five categories:

  • 1xx (Informational): The request was received, and the process is continuing. These are rare.
  • 2xx (Success): The action was successfully received, understood, and accepted.
    • 200 OK: The standard success response.
    • 201 Created: The request has been fulfilled and resulted in a new resource being created (e.g., after a successful file upload).
  • 3xx (Redirection): Further action must be taken to complete the request.
    • 301 Moved Permanently: The requested page has moved to a new URL.
    • 302 Found: The page is temporarily at a different URL.
  • 4xx (Client Error): The request contains bad syntax or cannot be fulfilled.
    • 400 Bad Request: The server couldn't understand the request.
    • 401 Unauthorized: You need to authenticate to get a response.
    • 403 Forbidden: You are authenticated, but you do not have permission to access this resource.
    • 404 Not Found: The server can't find the requested resource.
  • 5xx (Server Error): The server failed to fulfill an apparently valid request.
    • 500 Internal Server Error: A generic error message. This is often a goldmine for bug hunters, as it can indicate an unhandled error in the application's code, which might be exploitable.

Web App Pentesting - HTTP Headers & Methods

To solidify your understanding, watch this next section from the same HackerSploit video.

The presenter clearly explains the status code categories with practical examples, showing how requesting a non-existent file yields a 404 and a successful request returns a 200.

The Verbs of HTTP: Methods and Their Abuse Potential

The HTTP Method tells the server what action you want to perform on the resource. While you mostly interact with GET and POST in daily browsing, several others exist, and testing for them is a key part of a security assessment.

  • GET: Retrieve a resource.
  • POST: Submit data to a resource to be processed.
  • HEAD: Same as GET, but it only returns the headers and not the response body. Useful for quickly checking if a resource exists without downloading it.
  • OPTIONS: Asks the server which HTTP methods are allowed on a specific resource. This is a powerful reconnaissance tool.
  • PUT: Uploads a resource to the server. If it exists, it's often replaced.
  • DELETE: Deletes the specified resource.
  • TRACE: Echoes back the received request. Can sometimes be used to bypass certain security protections.

Misconfigured servers might leave dangerous methods like PUT or DELETE enabled on directories where they shouldn't be. An attacker who discovers this using the OPTIONS method could potentially upload a malicious file (like a web shell) or delete critical application files.

This is not just theoretical. Let's see how a hacker uses this knowledge to gain control.

Web App Pentesting - HTTP Headers & Methods

This final video segment is the most important part of the lesson. It demonstrates how to use these methods for a practical attack.

Watch carefully as HackerSploit uses the command-line tool curl to test for HTTP methods. The key steps are: He uses the OPTIONS method on a directory (/dav/). The server responds, revealing that dangerous methods like DELETE and POST (and implicitly PUT in this case) are allowed. He then uses curl with the PUT method to upload a PHP backdoor (a web shell). He confirms the file is on the server, giving him the ability to execute commands. Finally, he uses the DELETE method to clean up and remove the file. This sequence is a classic example of how a bug bounty hunter moves from reconnaissance (OPTIONS) to exploitation (PUT).

Conclusion

Today, you've moved beyond the connection and into the conversation itself. You now understand that every interaction on the web is a structured HTTP request and response. Being able to deconstruct these messages is fundamental to web hacking.

Key Takeaways:

  • HTTP is a text-based, request-response protocol. Requests ask, and responses answer.
  • Every request and response has a start line (containing the method/status code), headers (metadata), and an optional body (the data).
  • Headers are a rich source of information for reconnaissance, revealing server technologies and versions.
  • Status Codes are the server's feedback, telling you if your request succeeded (2xx), failed because of you (4xx), or failed because of the server (5xx). Server errors (5xx) are often worth investigating.
  • HTTP Methods define the action to be performed. Testing for allowed methods with OPTIONS can reveal dangerous configurations that allow you to PUT or DELETE files.

In our next lesson, we will explore a core security concept of the web: the Same-Origin Policy (SOP). Now that you understand how a browser talks to a server, we need to examine the fundamental rule that prevents a website from one origin (e.g., evil.com) from interfering with a website from another origin (e.g., your-bank.com). This will lay the groundwork for understanding a whole class of critical vulnerabilities like Cross-Site Scripting (XSS).