This week, we focus on the topic of API error handling and how a REST API exposed 4 million WordPress websites to account takeover attacks. We also cover the risks and best practices for designing API error responses, and we look at an article that makes a great case for API-First.
Vulnerability: 4,000,000 WordPress sites vulnerable to improper API error handling
A research team at Wordfence recently discovered a vulnerability in the REST API of a WordPress plugin called the Simple Security plugin. This vulnerability allows a hacker to log into the site as any other registered user without providing a valid security token, effectively bypassing API authentication.Ā
WordPress is a hugely popular web content management system. Itās estimated that this API vulnerability impacted over 4 million WordPress sites.Ā Ā
When an API detects an error condition, such as a missing token in a request, the API should always catch the error and respond in a controlled manner, typically returning an appropriate status code and a message describing the cause of the error:Ā
HTTP 401 { āmessageā: āinvalid credentialsā}
However, if a hacker can cause an error that is not expected or handled by the API, this flaw in error handling can cause the API to behave in unexpected ways, such as bypassing authentication. This appears to be the root cause of this incident.
Interestingly, the report indicates that this vulnerability was created in the plugin code while it was being upgraded with new security features. It is possible that the development team was so focused on delivering a working security feature that they neglected to consider error handling during API design and testing, when the vulnerability could have been prevented, or at least discovered before it went live and impacted 4,000,000 sites.
This incident highlights why API error handling is an important component of API security and should be standardized as a security requirement in API design. For reference OWASP provides helpful information and code examples for recommended error-handling practices.Ā
Article: The benefits of governance rules on API Error messages
Still on the topic of API error handling, this article from NordicAPIs shares examples of well-crafted API response messages from Stripe, Instagram, and Salesforce.Ā
These are great examples of how APIs should be designed from the perspective of the API consumer. Clear, consistent, and self-describing error messages make the API easier to understand and use, which in turn makes it easier to integrate the API and provides a better developer experience for the API consumer.Ā
Also, by carefully designing the shape of an API error response up front, the API team defines rules and constraints on the type, format, content and size of data that the API should return. Incidentally, OpenAPI can be used to precisely describe the structure of response messages.
This has obvious security benefits. Bugs in API error-handling code can easily lead to unauthorized data leakage, especially when error-handling code receives less attention during API development and testing.Ā
Weāve covered real-world examples of this in previous issues of this newsletter, such as incidents at Life360 and Cox Communications where private data was inadvertently leaked in error response messages.Ā
Itās no surprise then that hackers would attempt to intentionally invoke errors in an API as part of early reconnaissance, since error handling is considered a point of vulnerability.Ā
On the other hand, well-designed and consistent error response messages can help create APIs that are easier to use and also resilient to attacks.Ā
Article: Leaking Open Source Intelligence with API Error CodesĀ
When my youngest son comes to me asking for chocolate biscuits before dinner, I can respond in one of two ways: āThose biscuits are forbidden before dinnerā HTTP 403, or āThere are no biscuits to be foundā HTTP 404.Ā
If I respond with 403 instead of 404, the result is essentially the same (he doesnāt get the biscuit), but Iāve inadvertently given him a crucial piece of information he didnāt need to knowā¦there are chocolate biscuits in the house. This information leak will undoubtedly trigger a flood of persistent followup requests. I should have responded with 404 Not Found!Ā
This is essentially the point of a recent Cyber Security News article on API error codes.Ā
When an API returns an error response to deny a request, the choice of status code returned by the API can reveal useful open source intelligence (OSINT) to a hacker.Ā
For example, HTTP error codes 403 and 404 both indicate that access is denied, but they can also confirm the presence or absence of a requested resource. This is called a discrepancy factor. A hacker can use a discrepancy factor of a vulnerable login API, for example for a mobile app or SaaS platform, to check whether an account exists or not for a given email address.Ā
And if the vulnerable API has no usage limits, a hacker can easily launch an account enumeration attack and identify millions of registered users on your application or platform.Ā
My opinion is that 403 is an appropriate response if a user requests access to a resource that they do not have access to, but could potentially be granted access to. Otherwise, if a user should never have access to the resource, the API should behave as if that resource doesnāt exist for that user and always return 404.Ā
You can read more tips on handling error codes in this OWASP article.Ā
Article: Making a case for API-First
In an article on The New Stack, Frank Kilcommins makes a strong case for adopting API-First principles to promote better API interoperability, consistency, and reuse, especially as the number of APIs skyrockets to meet the voracious demands for input from AI-driven systems.
The article outlines the core principles of API-First and describes the typical drivers and benefits of this approach to API development, both from a technical and business perspective.Ā
When it comes to building an āAI-readyā API, the API must be easy to understand and consume automatically. This requires designing the API with the needs of the AI consumer in mind, which is one of the defining principles of the API-First approach. Additionally, using formal specifications like OpenAPI can help create a design process for producing high-quality, AI-ready APIs:
āSpecifications allow you to enforce consistency, define data structures, and provide clear constraints, all of which help machine consumers interact confidently with your APIsā
Back to this weekās main theme, the benefits of an API-First approach also help to solve the challenges of implementing secure API error handling.Ā
A carefully considered design of the API error response, with consistent structure and format for messages and a shortlist of expected status codes, will make it easier for an AI agent to predictably consume the API and gracefully handle error conditions.Ā
This is a very informative article on API-First that I highly recommend.Ā
Vulnerability: Account TakeOver of Cloud-connected IOT devicesĀ
The Claroty research team discovered critical API vulnerabilities in the OvrC platform, a cloud-based platform for remote management of smart devices in homes and businesses.Ā Ā
One vulnerability allowed a user to retrieve the status of any device registered to the Ovrc cloud, regardless of ownership. A user simply sends a valid device MAC address to the API, which can easily be guessed, and the API effectively confirms the existence of the device by returning a JSON response with the latest device status.Ā
By iterating over the vulnerable API with different MAC addresses, the research team was able to enumerate all devices connected to the cloud platform. The team estimates that over 10 million devices worldwide were affected by the vulnerability.Ā
Additional API vulnerabilities were discovered that allowed the team to take ownership of any device. The API responsible for registering ownership failed to enforce and authenticate a required device ID property in the request, allowing a user to bypass authentication and claim ownership and control over any device. Vulnerable devices included surveillance cameras used in homes and business premises.
According to an industry report from Imperva, 44% of account takeover attacks recorded last year targeted authentication APIs to exploit vulnerabilities such as authentication bypass. API teams must be vigilant in designing and testing authentication APIs with security firmly in mind.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
