As web users, we have all encountered “404” or “500” error pages at least once. Ever wondered what these digits mean? Well, those numbers are not casual and are known as HTTP status codes!
These are designed to communicate status information between servers and clients. While they appear as seemingly innocuous codes, attackers leverage them for vulnerability exploitation in backend applications.
In this guide, you will understand what information these HTTP status codes provide and how attackers exploit them to compromise your server.
Let’s dive in!
What Are HTTP Status Codes?
HTTP response status codes are three-digit numbers that the server sets in the response to a client request. They represent a way to classify the outcome of an HTTP request and can be divided into five classes:
1xx: Informational responses2xx: Successful responses3xx: Redirection messages4xx: Client error responses5xx: Server error responses
Specifically, HTTP error codes are all status codes that go from 400 to 599. These refer to situations where the request could not be successfully processed because of a client or server error.
Each status code provides different information to the caller, and it is up to the backend developer to set the right HTTP status error code for each particular error. For instance, a 400 Bad Request response indicates an invalid request from the client, while a 500 Internal Server Error signals a generic application-level error in the server.
Can Attackers Exploit HTTP Status Codes?
TL;DR: Yes, HTTP error codes are generally exploited by attackers to perform sophisticated attacks on servers.
HTTP status codes provide information about the success or failure of a client’s request to a server. This is free information for attackers, who can monitor and study changes in HTTP response status codes to forge increasingly effective requests. This iterative process enables them to slowly bypass web application security measures and get closer to their malicious objectives.
For instance, attackers could build a bot that performs a brute force attack to automatically find all resources exposed by your server. Initial requests may result in 404 Not Found errors, but subsequent requests might produce 401 Unauthorized, 403 Forbidden, or even 200 OK responses, indicating public endpoints to attack.
Status codes, whether success or error, help attackers map out a backend application’s routes and identify potential security flaws. They reveal the server’s behavior in response to specific inputs, which is awesome feedback for attackers!
Why Returning Wrong HTTP Status Codes on Purpose Is Not A Solution
Programing a backend application to return “wrong” HTTP status codes on purpose is a possible STO (Security Through Obscurity) technique. The idea is to make the public behavior of a server application more opaque as a way to enhance its security.
Setting unexpected HTTP status codes will confuse attackers and could disrupt most automated attacks, slowing down the progress of malicious users. At the same time, this tactic will confuse developers as well. Deviating from standardized HTTP error code conventions will also complicate troubleshooting and debugging. Plus, this STO strategy cannot be applied on public endpoints, where adherence to standards is crucial.
While returning uncommon HTTP response status codes may momentarily disorient attackers, it does not address the underlying vulnerabilities in the server. In other words, it is just a temporary deterrent that does not really mitigate attack vectors. Here is why you should not rely on such an exotic approach to web application security.
Most Interesting HTTP Status Code for Attackers
Time to dig into the most interesting HTTP status codes that attackers track for malicious purposes. Let’s explore the common attacks associated with these response codes!
200
The HTTP 200 OK success status response code indicates that the server has successfully processed the request. While this status code does not carry much information by itself, it signals to attackers that their attempt—whether automated or manual—was successful. In essence, it tells attackers that they have found a way to legitimately receive responses from the server. That opens the door to a world of possibilities, from data scraping to unauthorized access.
HTTP 200 OK responses are especially valuable to attackers when they target endpoints that should be protected by authorization. The Common Weakness Enumeration (CWE) describes this scenario as “Missing Authorization.”
For example, a 200 OK response from an unknown IP on paths like /admin/ or /private/ is highly interesting to a user with malicious purposes, as it suggests that these sensitive areas of the server are accessible without proper authorization.
400
The 400 Bad Request status code indicates that the server cannot process the request due to a client error. This is generally caused by an invalid request message framing, deceptive request routing, or malformed request.
Attackers can use the 400 status code to test the robustness of a web application. By deliberately sending malformed or unexpected data in a process known as fuzzing, they can observe how the server handles such inputs. If the web application returns a 400 status code, it confirms that some input validation is in place. However, it might expose weak or inconsistent input validation behavior, which could be exploited further.
Additionally, 400 responses could include detailed error messages about the invalid input. These messages can inadvertently reveal sensitive information such as variable names used in the business logic, the data validation library in use, or even database schema details. Attackers can employ all that information to craft more specific attack vectors. This is why 400 error messages should always be as generic as possible.
A 400 status code can also be harnessed to understand whether an endpoint exists, but the request was improperly formed. This information is useful to discover API endpoints and resources on a server.
401
The 401 Unauthorized status code indicates that the request has not been processed because it lacks valid authentication credentials for the target resource. Attackers typically send automated requests to various endpoints, looking for 401 responses. This helps them identify that an endpoint exists and requires authentication.
Once an attacker identifies the existence of an authenticated endpoint, they can initiate a brute force attack by systematically trying different username and password combinations. In some cases, backend applications return different 401 responses based on whether the username or password was incorrect (e.g., “Invalid username” vs “Invalid password”). Malicious users can exploit this to detect valid usernames. Instead, send fewer details back with the 401 (e.g. “Unknown username and/or incorrect password”).
401 responses are also valuable for studying the type of authentication (e.g., basic auth, bearer tokens, etc.) used by the server and the required parameters to satisfy it. With this information, it is possible to craft more sophisticated attack vectors aimed at exploiting weaknesses in the security authentication system of a web application.
403
The 403 Forbidden error code indicates that the server understood the request but refused to authorize it. Attackers leverage this status code to identify which resources are restricted by the server. The next step involves attempting to gain unauthorized access to these resources by modifying cookies, forging authentication tokens, or tampering with URL parameters.
By analyzing how the server responds to different variations of the request, attackers may also gain insights into the application’s logic, potentially spotting weaknesses in the access control mechanism.
A 403 response could also indicate that directory listing is disabled, but the directory itself exists. This may inadvertently disclose the existence of files or directories that attackers can then target for further vulnerability exploitation.
404
The 404 Not Found status code is likely one of the most common HTTP error codes for attackers, indicating that the server cannot find the requested resource.
By utilizing directory traversal or brute-force attacks based on 404 responses, attackers can trace out the server’s directory structure. A similar mechanism can be employed for performing endpoint and/or file enumeration. Thus, 404 error codes are useful for identifying which endpoints and resources exist and are accessible on a server.
In most cases, 404 responses consist of a generic HTML page that provides more information than just the basic “Not Found” message. These predefined web pages may also provide enough information for attackers to make informed guesses about the technology stack in use by the server. The solution here is to always override these default pages.
405
The 405 Method Not Allowed status code indicates that the server does not support the HTTP method of the request.
Discovering the existence of an API endpoint means knowing its path and HTTP method (e.g., GET, POST, PUT, PATCH, or DELETE). 405 responses help an attacker find the right HTTP method after identifying a valid path the server listens to.
To hinder the attacker, in the 405 response message, do not specify the correct HTTP method the caller should use to reach the API endpoint.
429
The 429 Too Many Requests error code indicates that the client has sent too many requests to the server in a given amount of time. That means that rate-limiting measures are in place. Attackers will then adjust their attack strategies accordingly, such as routing automated requests through a residential proxy network to get fresh exit IPs and avoid blocks.
Additionally, 429 responses may include RateLimit-* or X-RateLimit-* headers. These headers inform the client about the number of requests allowed in a given time frame, which is key information for attackers. Also, based on the names of those headers, it may even be possible to guess the library employed to implement rate limiting and consequently the technology stack in use.
The solution here is to respond with a 429 status code, without including rate-limiting headers or specific information about how your server limits incoming requests. In the case of requests routed by proxy servers, there is not much you can do, especially if they provide genuine IPs from residential devices. However, if the proxy IPs come from datacenters, their numbers are usually incremental, so they can be detected and banned in bulk.
500
The 500 Internal Server Error status code is the most generic among HTTP error codes and indicates that the server failed to fulfill the request. The reason behind a 500 response may be countless, but responses might include error messages or even entire stack traces.
Those error messages typically provide useful information about the configuration or internal workings of the server. The ultimate goal of attackers is to use that information to identify vulnerabilities to exploit.
Also, keep in mind that backend frameworks and libraries typically return generic 500 Internal Server Error responses in case of server errors. The default messages in these responses can sometimes be enough to guess the server’s technology stack.
To avoid assisting the attacker, override the default message and always respond with generic errors. For example, a message like “Internal Server Error” is enough to explain any 500 errors.
Resources to Strengthen Your Security Game
Security is a cat-and-mouse game, and if you want to stay ahead, continuous learning is essential. Equip yourself with these valuable resources:
- OWASP Secure Coding Practices: A comprehensive list of community-backed best practices designed to protect against the most common security attacks. This guide is supported by The OWASP Foundation, a nonprofit organization focused on improving software security.
- TryHackMe: A collection of hands-on labs that teach you how to attack web applications through interactive, real-world exercises. By stepping into an attacker’s shoes, you can gain a deeper understanding of their tactics and strategies.
- SANS Cyber Security Training: It offers a wide range of courses and certifications covering various aspects of cybersecurity, from foundational concepts to advanced threat detection techniques. Their training is widely recognized and respected in the industry.
Conclusion
In this guide, you learned what HTTP codes are and how attackers can use them to carry out targeted attacks against your server or web application. An idea to avoid this problem is to start returning uncommon HTTP status codes on purpose. While that may seem like an effective approach against vulnerability exploitation, it is not a real solution. The real solution is to follow API security best practices.
Originally published at https://semaphoreci.com on November 7, 2024.
