{{announcement.body}}
{{announcement.title}}

API Security Weekly: Issue #63

DZone 's Guide to

API Security Weekly: Issue #63

This week, we are looking into a huge API vulnerability exposing more than 47 million devices.

· Integration Zone ·
Free Resource

Newspapers taped to wall in dark room

This week, we are looking into a huge API vulnerability exposing more than 47 million devices. Also, Microsoft and Google are dropping Basic Authentication support, and there is an opinion piece on the top risks of API security.

Vulnerability: Thinkrace

The platforms you are using to power your systems can add vulnerabilities. PenTestPartners looked at various GPS watches, kids smartwatches, sport watches, car trackers, engine immobilizers, and other tracking devices. They found that many of these are based on one common platform from Thinkrace. The researchers have discovered at least 47 million such devices.

Unfortunately, the platform is highly vulnerable:

  • A lot of devices have a default password of 123456!
  • Infamous IDOR/BOLA: there is no proper authorization. You change the ID in the API call and can access a different device
  • The device identifiers can be enumerated

A combination of these vulnerabilities allows attackers to discover all the devices that use Thinkrace and take control over them.

3rd-party platforms and libraries can help you get to the market faster. However, you need to make sure that you take into account the security risks they might bring.

And, obviously, beware of using enumerable identifiers and default passwords, and properly implement authorization checks.

You may also like:  API Security Weekly: Issue #62

API Authentication: Microsoft and Google Dropping Basic Auth

Microsoft and Google both announced that they are removing basic authentication option for API access in 2020.

In basic authentication, client application such as email client prompts the user for username and password. The application then uses these credentials for API calls to the remote system.

This approach is highly vulnerable:

  • Users give total access to their system. They cannot limit access to a subset of functionality
  • API providers have no way to tell who is making the calls
  • You cannot revoke access without changing your credentials
  • You have to trust the client application 100%. Should they maliciously or accidentally leak the credentials, whoever gets them can do anything on the user's behalf

OAuth2 is a much more secure approach. It allows you to delegate partial access, manage each client separately, and never share your main credentials.

Be like Microsoft and Google. Use current best practices when implementing API authentication.

Opinion: Top Risks for API Security

In his blog post, Paul Maccann (Axway) argues that API security is not just a reshuffled version of web app security. It is a completely different game:

  1. The server is used more as a proxy for data
  2. The rendering component is the client, not the server
  3. Clients consume raw data
  4. APIs expose the underlying implementation of the app
  5. The user’s state is usually maintained and monitored by the client
  6. More parameters are sent in each HTTP request (object ID’s, filters)
  7. The REST API standard
  8. Standardized and generic
  9. Predictable entry points
  10. One entry point (URL) can be used for many purposes
  11. Traditional vulnerabilities are less common in API-Based apps

Hence he promotes the importance of the OWASP API Security Top 10 list (in its current RC form.)

You can subscribe to this newsletter at APIsecurity.io.

Further Reading

REST API Security

How to Secure APIs

Topics:
api ,apis ,api security ,cybersecurity ,newsletter

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 }}