OWASP API Top 10: Broken User Authentication

Gavin Johnson-Lynn -

This is the second entry in the OWASP API top 10 (API2:2019).

In my development career, implementing authentication was always something I feared. It's an important part of an API and implementing something like OAuth 2.0 takes a lot of reading and understanding to get right. Just the sort of feature where mistakes happen!

What is it?

Authentication is the act of verifying your identity, proving you are who you say you are. (not to be confused with Authentication, which is all about what actions you’re allowed to perform after you’ve passed authentication)

Authentication for an API can work in a variety of ways. At its simplest it might only require an API key to be passed with each request. More complex authentication might involve login with username, password and a second factor such as an authentication app on a mobile device.

Broken authentication can present itself in a wide variety of ways...

What Does an Attack Look Like?

The first thing to remember is that attacks on authentication aren’t just limited to the point where authentication happens e.g. where someone enters their username and password. Authentication is all about the proof that someone is who they say they are, so a forgotten password flow and MFA entry are also potential points of attack.

The second key thing to remember is that some of the endpoints involved are unauthenticated i.e. a user who hasn’t logged in yet should always be able to make calls to them. In an API there are often very few endpoints that can be called by an unauthenticated user, unless of course you’re making some or all of your API freely available to the world. This means that they already have less security controls than your typical endpoint, which may make them a little more vulnerable.

Credential Stuffing

When an endpoint can be accessed by an unauthenticated user, anonymous users (i.e. someone who hasn’t logged in yet) can often make requests to that endpoint as often as they like. That’s where credential stuffing comes in. It’s becoming increasingly common for attackers to have large databases of stolen usernames and passwords. With that they can then try to login to your API with every username and password combination they have. If one of those username and password combinations was also used by a user on your API then the attacker will be able to login and do whatever that user can do!

JWT’s

Even if authentication flows are working securely there can be other problems. A JSON Web Token (JWT) is often generated to be sent with API requests. JWTs effectively work as a temporary credential, so are closely linked with authentication. There are a lot of things that can go wrong with a JWT that most frameworks should handle by default, but once you leave the default settings, you should be aware of the problems. These include ensuring:

  • the signature is checked
  • it is signed with a strong signing algorithm
  • the expiration date is checked

What is the Impact?

In short, broken authentication generally means an attacker can login as a user. What can that user do within your API? Access data they shouldn’t? Access resources or even money?

If you're hoping to defend from this attack then I've got a Pluralsight course on Secure Coding: Preventing Broken Access Control, which might just help. Here's a preview: