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.
Vulnerability: Facebook
Facebook has reported and fixed a vulnerability in their 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 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 deauthentication 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 short period of times! 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:
- GitHub implementation was using the same URL (
https://github.com/login/oauth/authorize) for both authentication web page (withGETrequests) and OAuth request submissions (withPOST). There was code in place to differentiate between the two and handle them accordingly. - To circumvent the logic, attacker had to send a
HEADrequest. Typically, these are used instead ofGETto receive headers only – for example to determine the size of response without actually downloading it. - The Rails router in GitHub treats
HEADrequests asGETand forwards the request to the controller. This is automated behavior by Rails that developers didn’t account for. - The if-else logic of the controller only expects
GETย requests (to render authentication web page) orPOSTrequests (for the actual authentication). Since theHEADrequest is not aGET, the controller handles it as aPOST, int other words as authentication. - Because a
HEADrequest lacks the CSRF protection, the access to the GitHub data is granted without user consent.
An important reminder 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.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
