Tales of API Woes From a Security Professional Part 1
APIs need securing properly, not just via obscurity.
Application programming interfaces, or APIs, are a large part of today’s world; they are a set of software functions that define the way that multiple applications communicate with each other. Whenever you use an Internet aware software application whether this is a software package, web app, or mobile app it will send data to a back-end server via a request. The server then acts on this information, interpreting it, taking some action and sending it back to the client as a response; this is received via the application and translated into a format readable by humans.
Some APIs are so large that they are more like complete products of their own, not just an intermediary.
With the increase in mobile applications and the need for these apps to talk to back-end servers, APIs have started to transform into entire products themselves rather than just a connection link between two end devices. This increase in both the additional complexity and the number of APIs around means that some of these are rushed into production too quickly, introducing various security issues.
Whether insecure APIs are a product of management pressure, or developers not understanding security boundaries; insecure APIs can greatly impact the security of the application. Perhaps some of these issues are created due to reliance on security through obscurity, general users will never see API communications, so why bother protecting them.
Average users will never see the API, but this doesn’t mean they don’t need to be secure.
This post explores several of these API shortcomings and the repercussions that a lack of security design during the API SDLC provides. All of the examples were found on real engagements within the past 12 months so this is still a modern day issue! Hosts have been redacted or changed.
Not performing user checks
One of the biggest mistakes often found in API testing is the lack of distinction between users. There is either no separation between users and what they have access to, or if there is, that validation is not implemented robustly enough and can be easily bypassed by changing the request URL or the parameters. This may allow users to perform actions such as modifying user details, or submitting new orders as if they were someone else.
My Password is Your Password
In this example we will be looking at a URL obtained from intercepting the traffic from an app. It was found that that there was no user validation between the authenticated user and the target user whose password was being changed. The URL to change our own password was the following:
json/user/update_passwordImmediately the attack vector is semi-obvious, attempt to change ‘user’ to our own username (un000123) to see if it is still a valid request; if so we can try to target another user (un000132).
json/un000123/update_passwordjson/un000132/update_password
This simple lack of separation allowed a complete takeover and control of any other user’s account on the entire platform — game over.
In both cases, us and the target, the API provides a 200 OK response and successfully updates the password on the back-end. This allows us complete control over our target’s user account. This is critical enough, but looking closer there are also a couple of other issues as well.
The Cookie in the request is blank, so this action was able to be carried out by both an authenticated and an unauthenticated user as long as they had knowledge of the API call.
There is no server-side check for the current user password, the server checks that newPassword=confirmNewPassword, and that’s all.
And…?
The issue here is that there was no validation of the users on what they could access. There was firstly no check to ensure anyone was even authenticated to the platform before being allowed to perform API calls, and secondly there were no access controls or separation mechanisms to ensure that users could not access or manipulate other accounts. There should be robust checks performed to ensure that the user who is authenticated can only access and modify their own details, straying outside your sandbox should be met with server errors.
