This week we look at the recent API vulnerabilities at Facebook, Amazon Ring, and GitHub. There is also an upcoming webinar on OWASP API Security Top 10 that you can attend.

You may also like:  How to Secure APIs

Vulnerability: Facebook

Facebook has reported and fixed a vulnerability in its Groups API. This API and the information it exposes had been potentially abused by about 100 partners after Facebook introduced stricter conditions.

The vulnerability allowed apps to access and download excessive data including user names and profile pictures of the group members without their permission.

This is a reminder on a few important API security best practices:

• Object-level authorization to make sure that APIs cannot access the data that they should not access
• Logging and monitoring so you can detect when the data indeed is downloaded and can go back and see who accessed which data

Vulnerability: Amazon Ring

Researchers at Bitdefender have found a vulnerability in Amazon Ring doorbell cameras.

During the initial setup, the doorbell starts an unsecured WiFi access point and communicates over unencrypted HTTP with the mobile app. Thus, it could leak data, including your home WiFi password that in turn could open the door for accessing everything else in your home network.

Even worse, the danger won’t pass after the setup is done. An attacker could trigger the reconfiguration of the doorbell by continuously sending de-authentication messages so that the doorbell gets dropped from the wireless network. This forces the owner to reset the doorbell and thus leak the WiFi credentials, with the attacker at the ready to take advantage.

Do not ever use unencrypted connections, even for a short period of time! HTTPS and TLS are there for a reason. And do not sacrifice security for user convenience. Careful design can help you achieve both.

Vulnerability: GitHub OAuth Flow

Teddy Katz successfully hacked GitHub’s OAuth flow using a HEAD request:

1. GitHub implementation was using the same URL (https://github.com/login/oauth/authorize) for both authentication web page (with GET requests) and OAuth request submissions (with POST). There was code in place to differentiate between the two and handle them accordingly.
2. To circumvent the logic, attacker had to send a HEAD request. Typically, these are used instead of GET to receive headers only — for example to determine the size of response without actually downloading it.
3. The Rails router in GitHub treats HEAD requests as GET and forwards the request to the controller. This is automated behavior by Rails that developers didn’t account for.
4. The if-else logic of the controller only expects GET requests (to render authentication web page) or POST requests (for the actual authentication). Since the HEAD request is not a GET, the controller handles it as a POST, int other words as authentication.
5. Because a HEAD request lacks the CSRF protection, the access to the GitHub data is granted without user consent.

An important reminder of why it is important to properly define all accepted operations in your API and enforce them.

Webinar: OWASP API Security Top 10

Want to learn more about the upcoming OWASP API Security Top 10? Next Thursday, November 21, I will be participating in a webinar with some real-life examples of recent vulnerabilities from each of the OWASP API Security Top 10 categories.

To claim your spot, register here.

You can subscribe to this newsletter at APIsecurity.io.

Further Reading

API Security Weekly: Issue #56

API Security: An Overview