“Life in the SOC” is a Blog Series that shares experiences of the BlueVoyant SOC defending against the current and prevalent attacks encountered by our clients. The blogs discuss successful detection, response and mitigation actions that can improve your defensive capabilities.
In today's world where personal devices become ever more powerful and app-driven, Application Programming Interfaces (API) have become prevalent. An API is a software intermediary that allows two applications to talk to each other. An API is the messenger that delivers a request/ response to and from a provider.
APIs are currently used in most modern applications including:
As application rendering has moved from the backend to the frontend, so have the vulnerabilities and security issues that have traditionally resided on the server-side of transactions. In today's world the server is now used more as a proxy for the data, delivering raw data to the client device.
The good news here is that many traditional vulnerabilities are less common in API-based applications. Things like SQL injection (SQLi) or Cross-site Request Forgery (CSRF) attacks are reduced by the use of object-relational mapping (ORM) or authorization headers are used instead of cookies.
That doesn't mean security professionals are off the hook. According to Erez Yalon, a leader of the API Security Project for OWASP, "Alongside the vulnerabilities that are becoming less common, we see a rise in threats that are either specific to APIs or present a bigger risk. A lot of developers are still not aware of those, and the API Security Top 10 list looks to change that".
The following is the current release candidate for OWASP's initial API Security Top Ten:
|API 1||Broken Object Level Authorization||APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object-level authorization checks should be considered in every function that accesses a data source using input from the user.|
|API 2||Broken Authentication||Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other users' identities temporarily or permanently. Compromising system's ability to identify the client/user, compromises API security overall.|
|API 3||Excessive Data Exposure||Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user. Without controlling the client's state, servers receive more-and-more filters which can be abused to gain access to sensitive data.|
|API 4||Lack of Resources & Rate Limiting||Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.|
|API 5||Broken Function Level Authorization||Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.|
|API 6||Mass Assignment||Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.|
|API 7||Security Misconfiguration||Security misconfiguration is commonly a result of insecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.|
Injection flaws, such as SQL, NoSQL, Command Injection, etc. occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
|API 9||Improper Assets Management||
APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.
|API 10||Insufficient Logging & Monitoring||
Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
Like the non-profit’s most well-known list, the OWASP Top 10 Web Application Security Risks, the API list can be used to help CISOs and security managers to systematize fixes. The list will also help to prioritize and address new and old attack vectors and the way they affect APIs. CISOs can get a better understanding of how and where to invest resources to improve their API security.