This week, we have news of another high severity vulnerability in a WordPress plugin, this time the popular All in One allowing compromise via the core REST API. We also have views from @apihandyman on why to treat all APIs as public ones, a comprehensive beginner’s guide to API security, and finally an optimistic view from Forbes on how enterprises can achieve speed and security by adopting Zero Trust and APIs.
This is the final APISecurity.io newsletter for 2021. We wish all subscribers happy holidays and a prosperous New Year, and look forward to welcoming you back with issue 166 on the 6th January 2022!
Vulnerability: high severity vulnerability in the All in One WordPress plugin
Vulnerabilities in WordPress plugins have featured frequently in this newsletter (here and here) and again this week we feature a pair of high severity vulnerabilities in the popular All in One plugin. The first vulnerability CVE-2021-25036 allows for access to high privilege API endpoints via a privilege escalation attack, whilst the second vulnerability CVE-2021-25037 allows for SQL injection via API endpoints.
The vulnerabilities were discovered by security researcher Marc Montpas who disclosed details to the All in One SEO team who remediated the issues within a week. Users are advised to update their plugin to the latest version 4.1.5.3 or later.
The first vulnerability potentially allows users with low-privileged accounts to access an API endpoint registered by the plugin. For example, the aioseo/v1/htaccess endpoint can rewrite a site’s .htaccess with arbitrary content. The bug is a subtle one resulting from a case-insensitive path comparison — an attacker could change the case of a path and fall through to a default which granted privilege as shown below:
The second vulnerability exploits a flaw in command escaping in the plugin allowing an attacker to exploit the privilege gained via the first vulnerability to execute arbitrary databases queries.
The key takeaway here is the same as per all previous WordPress plugin exploits:
- Plugin authors should ensure that all API endpoints are fully authenticated and authorized.
- Developers should ensure that authorization methods have sensible ‘fail safes’ or defaults — in this case, the default was to allow authorization.
Opinion: All APIs should be treated like public APIs
One of the tradeoffs organizations need to make when approaching API security is whether to treat internal (or non public-facing) APIs differently from external (or public-facing) APIs. Instinctively one may feel internal APIs present a low risk to an organization and as such could be deprioritized from a security perspective. In a recent article Arnaud Lauret (aka. @apihandyman) makes a compelling case for treating all APIs as if they were external in all cases.
Laurent argues the cases on key five points:
- Nurturing people’s API mindset: use your internal API development to evolve best practices to ensure that your external APIs are ‘battle hardened’ when released.
- Simplifying architecture: avoid overly complex APIs designed to meet niche internal demands by enforcing a simplified architecture i.e. HTTP only APIs.
- Ensuring a good level of security: internal APIs may create a false sense of security in the way that APIs are designed from a security perspective.
- Reducing costs: simplifying the architecture and having standard well-documented interfaces reduces the need for custom or bespoke internal-only APIs.
- Achieving faster time to market: having a well-designed internal API that can be easily enabled for public access can reduce development effort and hence time to market.
From my point of view, the security aspect of treating all APIs as external by default is the most compelling. APIs should be designed to be secure by default regardless of where or how they are deployed since there is no guarantee as to how these APIs may be deployed in the future. As an example, an internal API may be enabled for external access due to changing business requirements such as the enablement of a new B2B partner. Assuming an API will be forever internal-only creates a false sense of security.
Additionally inadequately secured APIs expose additional attack surfaces which may be exploited by skilled attackers as part of lateral movement once they have penetrated external boundaries such as firewalls or gateways. The safest strategy is to assume zero trust and that all APIs may at any time be subject to attack.
By far the greatest advantage of assuming all APIs are external facing is the shift in perspectives toward security. API developers gain a greater awareness of the attack vectors and risks and are incentivized to treat security as a first-class element of good API design, rather than as an afterthought.
Guide: Beginner’s guide to API security
DZone featured an excellent article from Artem Arzamas on the beginner’s guide to API security. This comprehensive article should prove to be an invaluable resource to any newcomers to API development needing to consider security aspects and best practices.
The article provides coverage on topics such as API authentication including OAuth2 and SAML, the various protocols used by APIs, and deployment models, and a concise overview of the OWASP API Security Top 10.
The article concludes with some solid recommendations for best practices for API security. All in all an excellent read for anyone starting in API security.
Article: Achieve speed and security by adopting Zero Trust and APIs
Forbes has recently featured views on API security and again this week is featured on APISecurity.io with an article from contributor Vince Padua on how enterprises can achieve speed and security by leveraging APIs and Zero Trust.
Padua describes how the erosion of traditional trust boundaries has led to the wider adoption of zero trust architecture (ZTA) principles. Simultaneously APIs have become increasingly important to organizations as the means of access to critical data and assets. Unfortunately, APIs have increasingly become the target of attack due to weaknesses in implementation particularly regarding API keys and tokens.
Padua concludes that an approach based on ZTA concepts (such as policy decision and enforcement points) using an API gateway and using API authentication and authorization using token-based approaches offers the least privilege access and hence a risk reduction. The article provides an optimistic outlook on how to scale API security across multiple platforms and geo-distributed deployments.
Bonus article: Seven ways to avoid JWT pitfalls
Finally to conclude 2021 we have a bonus contribution from Dr. Phillipe de Ryck (of Pragmatic Web Security fame) discussing seven ways to avoid JWT pitfalls.
De Ryck provides an in-depth discussion with code samples for the following seven topics:
- Use a Static Algorithm Configuration
- Use Explicit Typing
- Go All Out on Metadata
- Treat your Secrets as Secrets
- Bring Down the Testing Hammer
- Encapsulating Security Behavior
- Rely on Static Code Analysis
This guide should prove to be popular with developers focused on API solutions reliant on JWT tokens.
Finally in 2022 de Ryck will be participating in a three-part webinar series on the OWASP API Security Top 10. Make a resolution for 2022 and book your space now.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
