top of page
  • Marco Liberale

Uncovering Server Information with Broken Requests

When it comes to understanding the configuration and setup of a server, one unconventional yet effective method involves the use of broken requests. This technique involves the intentional manipulation of HTTP headers to elicit specific responses from the server.

What's a Normal Request?

A typical HTTP request might look something like this:

GET /index.html HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Cookie: sessionid=xyz123; csrftoken=abcd1234
Connection: keep-alive

This request includes several headers that provide the server with information about the request, such as the type of browser making the request (User-Agent), the types of data the client can accept (Accept), the language preference (Accept-Language), the page from which the request was made (Referer), any cookies associated with the server (Cookie), and the type of connection (Connection).

Crafting a Broken Request

A broken request intentionally alters or malforms these headers. For example:

GET /index.html HTTP/1.1
User-Agent: Moz
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Cookie: ses=xyz123; csren=abcd1234
Connection: keep-alive

In this example, the User-Agent field is shortened and the Cookie field is altered.

Interpreting the Response

When a server receives a broken request, it typically responds with a 400 Bad Request error. This response can reveal valuable information about the server. For instance:

HTTP/1.1 400 Bad Request
Date: Thu, 14 Dec 2023 12:00:00 GMT
Server: Apache/2.4.46 (Ubuntu)
Content-Length: 320
Connection: close
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html>
   <title>400 Bad Request</title>
   <h1>Bad Request</h1>
   <p>Your browser sent a request that this server could not understand.</p>
   <p>Missing or invalid headers were detected.</p>
   <address>Apache/2.4.46 (Ubuntu) Server at Port 80</address>

In this response, we can see that the server is Ubuntu based and that it is running Apache 2.4.46. This information can be invaluable for identifying potential vulnerabilities and strategizing further attacks.

This technique can be particularly useful when traditional scanning methods, such as Nmap, fail to provide the desired results.


Recent Posts

See All


Les commentaires ont été désactivés.
bottom of page