This week, we have news on a breach affecting 400 000 users of a popular German school app, and another vulnerability in a popular WordPress plugin. In addition, there’s a thought-provoking opinion piece on the value of GraphQL on public interfaces, and an article featuring nine useful API testing tools.
Breach: Sensitive data of 400 000 German students exposed by API flaw
Last week, the news broke of a breach on a popular German student community app, Scoolio, discovered by security researcher Lilith Wittmann. Conservative estimates put the number of affected students to 400 000 students, but how Scoolio creates user accounts throws some uncertainty to the exact figure here.
Wittman describes (in German) how she was able to exploit the Scoolio API to retrieve sensitive user data, such as:
- User nicknames
- User and parent email addresses
- GPS location of last app use
- Name of school and class
- Personality traits like origin, religion, sexuality
Below shows an example of the type of user information leaked:
It took the developers of Scoolio just over a month to deploy a fix for the issue, but they were gracious enough to publicly thank Wittman for her responsible disclosure.
The precise nature of the vulnerability was not disclosed, but it would appear that this may be an example of API1:2019 — Broken object level authorization, based on the UUIDs of accounts.
Vulnerability: OptinMonster WordPress plugin affects 1 million sites
Another week, another vulnerability affecting users of WordPress, this time in a popular marketing plugin called OptinMonster. The vulnerability is similar to previous plugin vulnerabilities we have seen: API endpoints exposed by the plugin were not properly secured, allowing an attacker to compromise the deployment.
The vulnerability was discovered by the Wordfence team, who swiftly moved swiftly to protect their affected customers, and advised OptinMonster, who responded equally swiftly and patched the issue in version 2.6.5 of the plugin.
It turned out that many of the REST API endpoints were not securely implemented, which allowed attackers multiple pathways to access an affected installation. The most serious was the endpoint /wp-json/omapp/v1/support which actually disclosed an API key used to make requests to the OptinMonster website. An attacker could easily use this API key to make changes to any campaigns associated with it, including potentially embedding dangerous JavaScript code.
As we have seen with similar plugin vulnerabilities in WordPress, it tends to originate in how the permissions_callback method is implemented. WordPress core triggers this callback to allow the plugin to validate the API request, typically by performing checks on the authentication and authorization of the caller. Unfortunately, the implementation in the OptinMonster case left a lot to be desired, as there was no attempt at checking the caller’s permissions. All that was required was that the caller was logged in and had a valid API key! A good example of API5:2019 — Broken function level authorization.
The key takeaway here is for API developers to ensure that all API callers are fully authorized for the API endpoints being called.
Opinion: GraphQL is not meant to be exposed over the internet
Previously, we have featured Jens Neuse’s view on hardening and securing GraphQL implementations. This week, he is back discussing GraphQL in a provocative article that suggests that GraphQL should not be exposed over the internet!
According to Neuse, in many cases GraphQL is an unnecessary indulgence that is not required from a technical perspective and adds to risk exposure. Typically the benefits of GraphQL only manifest for the so-called ‘unicorns’ like Facebook and GitHub. Neuse’s advice is to consider if you really need GraphQL at all.
Neuse recommends that a security review of risks should be conducted if GraphQL be used at all, paying special attention to the following:
- How secure are the libraries upon which your endpoint is built?
- Do you understand how they work and what limitations they may have?
- Are you inadvertently exposing your API even if you disable the visual GraphQL playground?
- Are you enabling the introspection query which could leak sensitive information like the underlying data schema?
- Are you aware of schema traversal attacks?
Anyone considering a GraphQL implementation would do well to read and understand this article, as well as its prequel. As Neuse concludes with tongue firmly in cheek:
“If you want to be 100% safe, you should consider unplugging the network cable. However, this comes with some inconvenient drawbacks.”
Guide: Nine online API testing tools
Last but not least this week is a quick read from Idowu Omisola on nine online API testing tools.
The article covers some of the industry-standard tools, such as Postman and Swagger Inspector, but also features some lesser-known tools like the excellent Paw for MacOS users and the updated Fiddler Everywhere from Telerik.
All in all, a useful guide for any API tester or hacker.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
