APIsecurity.io - APISecurity.io Newsletter: Issue 151

Last Friday saw a security and maintenance release for WordPress, with the details of version 5.8.1 available here. This release features 60 bug fixes and — most importantly — three security fixes, namely:

• A data exposure vulnerability within the WordPress REST API
• An XSS vulnerability in the block editor
• Lodash library updated to version 4.17.21 to incorporate upstream security fixes

Of interest to us is the vulnerability related to the WordPress REST API, detailed more fully in CVE-2021-39200.

WordPress provides an internal helper method wp_die that is called when an error occurs in the WordPress core. Unfortunately, the existing implementation of the handler emitted excessive internal data including nonces. This would allow an attacker to gain access to nonces which in turn could allow unauthorized access to core WordPress API methods. The fix shown below is available on GitHub here.

Because of the fixed security issues, WordPress recommends users to update their installations to the new version as soon as possible.

The main lessons learned here are:

• Complex systems, such as WordPress, can relatively easily be compromised by their APIs. In security-sensitive applications, it may be advisable to disable such APIs if they are not required.
• Information leaks are a constant threat to software systems — this one is an example of API3:2019 — Excessive data exposure, whereby sensitive data is inadvertently leaked allowing system compromise.

This week featured an article in SecurityIntelligence, covering the rise of the APIs and — specifically — how APIs may increasingly be under threat from botnets weaponized against APIs and Denial of Service (DoS) attacks.

The article quotes various references driving the rise of API adoption suggesting that in 2021, over 70% of organizations will be using APIs in their business solutions. Of particular concern is the rise in the number of organizations that will expose those APIs to the internet or to third-party APIs. According to a survey from Radware and Osterman Research, nearly 40% of respondents stated that over half of their applications were exposed in this manner.

Even more concerning was the fact that nearly half of the participants had experienced an injection attack, and that monthly DoS attacks were even more prevalent.

Key takeaways here are:

• Implement some form of rate-limiting on key APIs to mitigate against bot attacks.
• Consider the use of multi-factor authentication (for example via OAuth2 protocol) to reduce the impact of bot attacks.
• Use identity and access management, such as Role-Based Access Control (RBAC) to restrict which resources are accessible through user accounts.

A key pillar in a holistic approach to API security is the judicious use and management of API tokens. Unfortunately, this is a domain that is frequently poorly understood and often poorly implemented.

This week we are fortunate enough to feature a fantastic (and exhaustive) overview by Thomas H. Ptacek on the use of API tokens. The article is written in a wonderfully humorous way with tongue always firmly in cheek — “Canonically, OAuth lets a 3rd party post a tweet with your account.”

More importantly, the article is well-referenced, opinionated, and almost certain to be valuable to anyone involved in the implementation of API solutions.

The state of play for API tokens is summarized succinctly here:

Finally this week, we have musings from API Evangelist on the joys of all things relating to API discovery, of interest to anyone involved in the development or use of APIs. In a nutshell, the suggested sources for discovery are (in no particular order):

• ProgrammableWeb
• Rapid API
• APIs.json
• APIs.io
• APIs.guru
• Postman Collections
• SwaggerHub
• Postman API Network
• Just Google it!