API Security Weekly: Issue #45

DZone 's Guide to

API Security Weekly: Issue #45

This week, we take a look at the recent location API vulnerabilities in dating apps and smart locks and more!

· Integration Zone ·
Free Resource

This week, we take a look at the recent location API vulnerabilities in dating apps and smart locks. In addition, we have an API security video from RSA Conference in Singapore, and the survey results and API security recommendations from Cloud Security Alliance.

Vulnerability: Dating Apps

BBC has run a story on the common API vulnerability pattern across several gay dating applications: Recon, Grindr, and Romeo.

All of these applications show other members in the user’s proximity. The shared API vulnerability is a combination of two factors:

  • API can be invoked outside of the application and spoofed client coordinates can be supplied as parameters
  • API returns other members’ exact distance from these coordinates

Attackers could run API calls and supply different locations. Once they knew the exact distance to a user from three different points, they could then determine the user’s exact location using trilateration.

Needless to say, this kind of API flaw could potentially become a source of a physical security threat for app users.

We have covered other dating app API vulnerabilities in issues 18 and 44.

Vulnerability: FB50 Smart Lock

FB50 smart locks are sold under different brands and have more than 15,000 estimated customers. Researchers have found the lock service APIs vulnerable to Insecure Direct Object Reference (IDOR) attack, opening the door for a full takeover.

IDOR vulnerabilities are essentially authorization issues. In such cases, credentials for one account can be used to access data for other accounts.

Here’s how the attack worked:

  1. Attacker creates an FB50 smart lock account with the vendor.
  2. Attacker scans for Bluetooth devices near a smart lock to get the MAC address.
  3. Attacker makes a REST API call to the FB50 cloud service for a device query based on the MAC address of the lock. This gives the attacker the barcode and ID of the lock.
  4. Attacker supplies the lock’s barcode in an API call and gets the user ID of the owner of the lock.
  5. Attacker supplies the lock ID and the user ID in an API call to unbind the lock from the user.
  6. Attacker makes an API call providing their user ID, a new name for the lock, and the MAC of the lock to take ownership of the lock.

RSAC Singapore: The State of API Security

Videos from the recent RSA Conference in Singapore are coming out. This video has a conversation between Varun Haran and Jacques Declas on the state of API security:

  • How API security has evolved
  • API security and the role that DevSecOps plays
  • API security for microservices in the world of Kubernetes

Surveys: Egregious 11 Cloud Security Issues

Cloud Security Alliance has released its “Egregious 11” cloud security issues report. The report is the result of a survey that they ran across 241 industry experts.

Needless to say, API security comes out as one of the top issues. Here are some recommendations that they include:

  • Practice good API hygiene, including diligent oversight of things like inventory, testing, auditing, and abnormal activity protections.
  • Consider using standard and open API frameworks.

You can subscribe to this newsletter at APIsecurity.io.

apis ,api ,api security ,cybersecurity ,newsletter ,integration ,integration news ,api news ,security news ,api security news

Published at DZone with permission of Dmitry Sotnikov , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}