The Graylog blog

When 200 OK Is Not OK – Unveiling the Risks of Web Responses In API Calls

In the ever-evolving landscape of cybersecurity, where the battle between defenders and hackers continues to escalate, it is crucial to scrutinize every aspect of web interactions. While the HTTP status code 200 OK is generally associated with successful API calls, there’s a dark side to its seemingly harmless appearance that often goes unnoticed. This blog post highlights the vulnerabilities that can emerge when the 200 OK web response reveals more information than intended and why hackers exploit this to their advantage.

Data Leakage is Not OK

HTTP status codes play a crucial role in communication between web servers and clients, conveying the success or failure of a requested operation. The 200 OK status code signals that the request has been successfully processed, providing the green light for further actions on the client’s end. However, when this status code is accompanied by unintended data leakage, it can become a powerful tool for attackers.

See in this example:

200 OK
"response_body": "REAL=false\nCOUNT=-1\nDB_USERNAME=\"Ollie\"\nDB_PASSWORD=\"p@ssw0rd\"\nBALANCE=-0.0000000000000000277555756156289135105907917022705078125\n"

 

ERROR Handling Exceptions

One of the common scenarios where this vulnerability arises is insufficient error handling. Developers may inadvertently expose sensitive information in error messages when something goes wrong during an API call. Instead of returning a generic error code, detailed error messages can unintentionally reveal internal system details, such as file paths, database structures, or even credentials.

See in this example:

200 OK
"runtime_error":"java.lang.NullPointerException: io.coinbroker.server.app.servlet.billing.GetUserBillingServlet.internalWork(GetUserBillingServlet.java:64) [GetUserBillingServlet.class:na]"

 

Hackers leverage this information to gather intelligence about the target system, enabling them to fine-tune their attacks. With insights into the system architecture, attackers can identify potential weak points, making it easier to exploit vulnerabilities and gain unauthorized access.

Another aspect of this issue lies in inconsistent error handling across different endpoints of an API. A well-secured system should provide uniform error responses, revealing minimal information about its internal workings. However, if certain endpoints divulge more details than others, attackers can selectively target the weaker links, gradually accumulating information to orchestrate a more sophisticated and successful attack.

To mitigate the risks associated with unintended data exposure in API responses, developers must adopt a rigorous approach to error handling. Error messages should be generic, avoiding specifics about the system’s internal workings. Implementing custom error codes and providing only essential information helps thwart attackers attempts to glean insights into the system’s structure.

Response is not JSON compliant

API calls and their responses play a crucial role in modern software development, but they are not without their challenges. One significant problem developers often encounter is receiving a response in a format that is not JSON-compliant.

An example here:

{ "quote_token":"null", "time_processed":"1644251287471" ,}

(do you see it?)

 

In the above example, a small error in the output can result in this data being passed to other systems with invalid formats, causing errors.

 

JSON (JavaScript Object Notation) is a lightweight data-interchange format widely used for transmitting data between a server and a client. When an API response contains data that does not adhere to the JSON standards, it can lead to parsing errors and disrupt the smooth flow of information between systems. This non-compliance might occur for various reasons, such as:

  • incorrect data types
  • malformed syntax
  • missing key-value pairs

 

Developers must meticulously handle such scenarios by implementing robust error-handling mechanisms to manage unexpected or non-compliant data gracefully. Ensuring a consistent and valid JSON format in API responses is crucial for maintaining the reliability and interoperability of software systems that rely on these API calls.

 

Graylog API Security

As the digital landscape becomes increasingly interconnected, the need for robust cybersecurity practices is more critical than ever. Understanding the nuances of seemingly innocuous elements, such as HTTP status codes, can make all the difference in fortifying the defenses against malicious actors. The next time you encounter a 200 OK response, remember that not all successes are equal, and vigilance is the key to safeguarding sensitive information in web interactions. With Graylog API Security, you can be on the lookout for the OWASP API SECURITY TOP 10

Remember, your 200 OK is not always OK. Try Graylog API Security for free now!

 

Get the Monthly Tech Blog Roundup

Subscribe to the latest in log management, security, and all things Graylog Blog delivered to your inbox once a month.