API vulnerabilities - some lessons learned
A detailed report by security researcher Sam Curry made the news recently, as it described how trivial it is to get hold of sensitive PII information and even control some aspects of modern vehicles via publicly exposed web APIs. The affected brands included BMW, Kia, Honda, Hyundai, Mercedes, Ferrari, Ford, and others. The good news is the vulnerabilities have probably since been fixed, as the author(s) followed responsible disclosure practices.
The bad news is how easy it is to introduce vulnerabilities in complex web applications and API infrastructure.
However, when digging deeper into the vulnerability writeups, there are some common elements that are relevant for any organization exposing public facing web services.
Never reinvent the wheel
In case of BMW, it appears the API was implementing user authentication mechanisms within the application itself, instead of relying on Oauth2 or SAML mechanisms typically used by modern identity as a service solutions. For ex. the API was exposing endpoints used for one-time password generation and the whole password management experience (for ex. self-service password resets).
As the application handled user management actions (a big no-no), it made no difference between employees and external contractors. This means once the researchers were able to trigger password resets for any arbitrary user via API calls to the application, they could completely take over any BMW employee account and access tools used by those employees (think VPN or Email!). A staggering propagation and elevation of vulnerability impact!
Another example in the report is Mercedes-Benz's website built for vehicle repair shops: again, the web application implemented user management functions such as creation of new user accounts.
Apparently, the application relies on an LDAP backed to create user records, the same used for its employees globally. As LDAP is just a database, there are no authorization mechanisms to assign users to selected applications: in fact, once a user account has been created via the website, the researchers were able to access dozens of sensitive internal applications, including Github code repositories containing internal documentation and source code for various Mercedes-Benz projects.
Best practice
Whenever developing applications, particularly those exposed as public API endpoints, it is important not to reinvent the wheel: never build user management and authentication functions into the application. This is especially important when outsourcing application development: the project will usually specify secure user access, and so this will be implemented as reinvented functionality within the application, increasing the risk of inadvertent bugs.
Today's authentication standards such as SAML or Oauth2 provide plenty of options to delegate authentication to an external identity provider. Ideally, that should be an Identity-as-a-service (IDaaS) solution, as it's best positioned to offer functionalities such as multi-factor authentication, application assignment, conditional authentication policies (for ex. by location or device), governance, self-service, etc.
Being focused just on authentication and authorization aspects, IDaaS solutions are certainly less likely to introduce trivial bugs such as the ones described above.
Don't reinvent the wheel, delegate authentication to a provider.