APIsecurity.io - APISecurity.io Newsletter: Issue 154

This week, the 42Crunch Field CTO Isabelle Mauny was featured in Security Boulevard, discussing how security officers should approach the challenges of securing APIs. The growth of API consumption has — unfortunately but unsurprisingly — resulted in an increase in attacks against API infrastructure, resulting in well-known breaches that have also been covered in this newsletter.

Mauny suggests that the reason why API security issues are so prevalent include:

• Development teams are increasingly agile, resulting in a more frequent release schedule that presents challenges to security teams who are still reliant on manual testing procedures.
• Application development techniques are changing: the monolith is being broken down, and modern applications are composed of multiple APIs — frequently client-side — that can be invoked directly without adequate controls.
• Security is typically implemented late in the application lifecycle as part of a mandatory compliance stage, which results in security testing with high false-positives late in the development process.

Modern APIs (especially in interconnected microservices) erode the typical network boundaries and reduce the effectiveness of traditional perimeter protections, such as web application firewalls (WAFs). Mauny suggests with the receding importance of the perimeter, it is more important to protect the data than the perimeter itself.

The other key consideration is ensuring that API security tooling has the full context to ensure that the tool makes the correct decision, either statically (like when auditing an API contract against the OpenAPI standard) or dynamically when enforcing traffic behavior on an API endpoint. WAFs also exemplify how the lack of context renders them ineffective in protecting an API: a WAF cannot distinguish bad (unintended) behavior from good (intended) behavior.

Finally, the article highlights the value of API contracts as a means towards a positive security model, one in which the expected behavior is clearly defined, the opposite of a negative security model where bad behavior is inferred. By utilizing an API definition (such as an OpenAPI definition of the API contract) it is possible to verify the API development process at every stage of the development and deployment cycle. Such an approach affords a security officer early insight into the security posture of APIs and guarantees that APIs can be tested against their contracts.

A recent report from IBM  reveals that two-thirds of cloud breaches have their origins in misconfiguration of the API implementations. The report contains 12 months of findings from various IBM research teams and concludes that cloud environments need to be better secured.

The key findings from the report include:

• There is a vast and thriving black market for the resale of public cloud access details and credentials, such as Remote Desktop Protocol access.
• Many systems could be compromised due to poor passwords and inadequate policies.
• APIs were the most common cause of compromise, accounting for nearly two-thirds of the cases identified in the report.
• The erosion of the traditional perimeter has resulted in more complex scenarios which are difficult to protect with legacy systems.

The main recommendations from the report include:

• Environments should be secured by a more robust hardening of systems (such as by protecting passwords, or enforcing policies).
• Stricter governance must be imposed on “shadow IT” because it represents an unquantified business risk and is a frequent source of compromise.
• Organizations must understand the risks inherent in the rapid opening of hitherto internal-only APIs to public access because this opens new attack vectors.

Also featured this week is an article by Jason Kent in Threat Post on how to detect malicious behavior on API endpoints. Increasingly, API endpoints intended for either web or mobile applications are under attack by rogue actors and bots. Being able to identify such attacks in systems allows potential attacks to be thwarted before they are successful.

Kent’s experience as a hacker comes to the fore in the article, with several key (and relatively simple) suggestions for API developers:

• Use a separate domain for web and mobile applications. This allows spurious activity to be identified, for example, by being able to detect when a browser is accessing an endpoint intended for a mobile application — a leading indicator that a human attacker may be attempting to reverse-engineer the API.
• Pay attention to the presence of ‘crawlers’ — such as Facebook and Google, commonly used in enumerating websites — in API endpoints, particularly those for mobile applications. The presence of crawlers in logs is often an indication of active reconnaissance and an imminent attack.
• Review API logs periodically,  paying particular attention to user agent strings — a sign of unusual or unexpected behavior is often the precursor to an attack.

Given the rise of bot attacks on APIs, these simple recommendations should prove valuable to API builders.

In issue 150, we covered best practices for hardening your GraphQL implementations. In this week’s issue, we feature some brief observations on common attack vectors used against GraphQL  implementations.

GraphQL is a data query language that allows the client to construct arbitrary data queries against the underlying data stores . This contrasts to the more well-established REST API that allows a structured method of access through known endpoints. The difference is illustrated below:

Whilst the GraphQL endpoint provides more flexibility for the client consumer, it does represent additional security considerations due to the complexity of the underlying implementation. Mihalache’s article highlights a few common attack vectors to consider to protect, or other compensating controls:

• Introspection: One of the benefits of GraphQL is the ability to dynamically enumerate the underlying data, which can — unfortunately — facilitate attackers’ discovery process.
• Missing access controls: Default implementations don’t provide access controls, developers must be implemented them in bespoke logic.
• SQL and NoSQL injections: GraphQL is easily susceptible to traditional injection attacks on the backing data stores.
• Information disclosure: Default GraphQL implementations tend to be very verbose, potentially to the advantage of attackers.
• Bypassing rate limiting: Batching queries can lead to denial of service (DoS) attacks on the GraphQL endpoints.
• DoS: In addition to above, nested queries too can easily be used for launching DoS attacks.

Mihalache reaches the same conclusion as our previously referenced GraphQL article, namely that default GraphQL implementations are often insecure by default, and the savvy API developer is well-advised to harden implementations to eliminate some of the more common attack vectors.