Continuing our series about the OWASP API Security Top 10, this time we are going to talk a little bit about Broken User Authentication. Hope you like it 🤗
🤔 User Authentication, What is it?
Imagine a login page, which asks you for both your email address and your password.
These are some possible interactions you might have with the page, and the expected responses for each interaction:
- If you click on the login button without passing any data to the input fields, the page returns an error 🤨
- If you type your email but don't type any password, when you try to login, the page will return an error 😤
- If you type your email and type a wrong password, when you try to login, the page will still return an error 🤬
But if you manage to somehow insert your email along with your correct password, this is what you will get as a response from the application:
This process of picking up your email and password in order to verify that you are User1337 is a possible form of authentication. In more general terms, any sort of process which verifies whether or not users are who they're saying they are, may be called an user authentication method.
User authentication comes in different shapes, colours and flavours. You can find it not only in basic login forms, but also in password reset forms, HTTP request headers/cookies, 2FA apps, and the list goes on and on...
🔓 How Does it Get Broken?
So how does API2:2019 happen? Well, the Broken User Authentication happens when a faulty implementation of an authentication mechanism allows an attacker to impersonate someone else, temporarily or permanently.
🧐 Example 1
An application in which all passwords have 4 numeric digits and has no brute forcing prevention methods at all. In this scenario, anyone with a computer might impersonate any user of the application in a few seconds or minutes just by automating the process of attempting 4 digit number combinations. So we have a Broken User Authentication here 😲
🤯 Example 2
A password reset flow for users who forgot their password. The user enters their email address in order to receive a link for setting a new password:
When the user submit this form, the following HTTP request is sent:
POST /password-reset/n1c3-t0k3n-h3r3 HTTP/1.1
Content-Type: application/json{
"password": "therealpassword123",
"passwordConfirm": "therealpassword123",
"userID": 1337
}
Notice that there's an attribute called userID which apparently refers to the ID of the user who did request this password change. And remember, from the last post, that there is something called Broken Object Level Authorization, which is very very common in applications these days.
If this particular endpoint is vulnerable to API1:2019, in a way that by changing the value of userID an attacker end up changing the password of someone else and being able to impersonate them, we may say that this same endpoint is also vulnerable to API2:2019, because we have a broken authorization mechanism leading to a broken authentication mechanism. 😭
📚 External materials
As my goal with this series is to just explain what each flaw is, I would like to suggest some materials about authentication security issues, so you understand better the details of it:
https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication
https://www.youtube.com/watch?v=j8Yxff6L_po
https://auth0.com/blog/what-is-broken-authentication/
Top comments (0)