Chapter 4. Authentication

1.

Chapter 4. Authentication

2.

Chapter 4.Sections and sectors
1. What is Authentication?
Understanding Authentication.
2. Business logic vulnerabilities
Explain the Business logic vulnerabilities.
3. Vulnerabilities in authentication mechanisms
Explain
vulnerabilities
in
authentication
mechanisms.
4. 11 Common Authentication Vulnerabilities
You Need to Know

3.

1. Authentication
Authentication is the process of verifying the
identity of a given user or client. In other words,
it involves making sure that they really are who
they claim to be.

4.

Authentication
There are three authentication factors into which different
types of authentication can be categorized:
Something you know, such as a password or the answer to a security
question. These are sometimes referred to as "knowledge factors".
Something you have, that is, a physical object like a mobile phone or
security token. These are sometimes referred to as "possession
factors".
Something you are or do, for example, your biometrics or patterns of
behavior. These are sometimes referred to as "inherence factors".

5.

Authentication and authorization?
Authentication is the process of verifying that a user really is who
they claim to be, whereas authorization involves verifying whether a
user is allowed to do something.
In the context of a website or web application, authentication
determines whether someone attempting to access the site with the
username Carlos123 really is the same person who created the
account.
Once Carlos123 is authenticated, his permissions determine whether
or not he is authorized, for example, to access personal information
about other users or perform actions such as deleting another user's
account.

6.

How do authentication vulnerabilities
arise?
Broadly speaking, most vulnerabilities in authentication mechanisms arise
in one of two ways:
-The authentication mechanisms are weak because they fail to adequately
protect against brute-force attacks.
-Logic flaws or poor coding in the implementation allow the authentication
mechanisms to be bypassed entirely by an attacker. This is sometimes referred
to as "broken authentication".
In many areas of web development, logic flaws will simply cause the
website to behave unexpectedly, which may or may not be a security issue.
However, as authentication is so critical to security, the likelihood that
flawed authentication logic exposes the website to security issues is clearly
elevated.

7.

2. Business logic vulnerabilities

8.

What are business logic vulnerabilities
Business logic vulnerabilities are flaws in the design and
implementation of an application that allow an attacker to
elicit unintended behavior. This potentially enables
attackers to manipulate legitimate functionality to achieve a
malicious goal. These flaws are generally the result of
failing to anticipate unusual application states that may
occur and, consequently, failing to handle them safely.

9.

What are business logic vulnerabilities
Logic flaws are often invisible to people who
aren't explicitly looking for them as they
typically won't be exposed by normal use of
the application.

10.

What are business logic vulnerabilities
One of the main purposes of business logic is
to enforce the rules and constraints that were
defined when designing the application or
functionality.

11.

What are business logic vulnerabilities
Flaws in the logic can allow attackers to circumvent these
rules. For example, they might be able to complete a
transaction without going through the intended purchase
workflow. In other cases, broken or non-existent validation
of user-supplied data might allow users to make arbitrary
changes to transaction-critical values or submit nonsensical
input

12.

How do business logic vulnerabilities
arise
Business logic vulnerabilities often arise because
the design and development teams make flawed
assumptions about how users will interact with the
application. These bad assumptions can lead to
inadequate validation of user input. For example, if
the developers assume that users will pass data
exclusively via a web browser, the application may
rely entirely on weak client-side controls to validate
input. These are easily bypassed by an attacker
using an intercepting proxy.

13.

The impact of business logic
vulnerabilities
The impact of business logic vulnerabilities can, at
times, be fairly trivial. It is a broad category and the
impact is highly variable. However, any unintended
behavior can potentially lead to high-severity
attacks if an attacker is able to manipulate the
application in the right way. For this reason, quirky
logic should ideally be fixed even if you can't work
out how to exploit it yourself. There is always a risk
that someone else will be able to.

14.

How to prevent business logic
vulnerabilities
In short, the keys to preventing business
logic vulnerabilities are to:
• Make sure developers and testers
understand the domain that the application
serves
• Avoid making implicit assumptions about
user behavior or the behavior of other parts
of the application

15.

How to prevent business logic
vulnerabilities
To facilitate this, the development team should adhere to the following best
practices wherever possible:
Maintain clear design documents and data flows for all transactions and
workflows, noting any assumptions that are made at each stage.
Write code as clearly as possible. If it's difficult to understand what is supposed
to happen, it will be difficult to spot any logic flaws. Ideally, well-written code
shouldn't need documentation to understand it. In unavoidably complex cases,
producing clear documentation is crucial to ensure that other developers and
testers know what assumptions are being made and exactly what the expected
behavior is.
Note any references to other code that uses each component. Think about any
side-effects of these dependencies if a malicious party were to manipulate them
in an unusual way.

16.

The impact of vulnerable
authentication
The impact of authentication vulnerabilities can be
very severe.
Once an attacker has either bypassed authentication
or has brute-forced their way into another user's
account, they have access to all the data and
functionality that the compromised account has.
If they are able to compromise a high-privileged
account, such as a system administrator, they could
take full control over the entire application and
potentially gain access to internal infrastructure.

17.

3. Vulnerabilities in authentication
mechanisms
There are more some of the most common
vulnerabilities in the following areas:
Vulnerabilities in password-based login
Vulnerabilities in multi-factor authentication
Vulnerabilities in other authentication mechanisms

18.

Vulnerabilities in password-based login.
Brute-force attacks
A
brute-force attack is when an attacker
uses a system of trial and error in an
attempt to guess valid user credentials.
These attacks are typically automated using
wordlists
of
usernames
and
passwords.
Automating this process, especially using
dedicated tools, potentially enables an
attacker to make vast numbers of login
attempts at high speed.

19.

Vulnerabilities in password-based login.
Brute-forcing usernames
Usernames are especially easy to guess if they conform to a recognizable
pattern, such as an email address.
For example, it is very common to see business logins in the format
[email protected].
However, even if there is no obvious pattern, sometimes even high-privileged
accounts are created using predictable usernames, such as admin or
administrator.
You should also check HTTP responses to see if any email addresses are
disclosed.

20.

Vulnerabilities in password-based login.
Brute-forcing passwords
This typically involves enforcing passwords with:
A
minimum number of characters
A
mixture of lower and uppercase letters
At
least one special character

21.

Vulnerabilities in password-based login.
Brute-forcing passwords
For example, if mypassword is not allowed, users may try
something like Mypassword1! or Myp4$$w0rd instead.
In cases where the policy requires users to change their
passwords on a regular basis, it is also common for users
to just make minor, predictable changes to their preferred
password. For example, Mypassword1! becomes Mypassword1? or
Mypassword2!.

22.

Vulnerabilities in password-based login.
Username enumeration
Username
enumeration is when an attacker is able to
observe changes in the website's behavior in order to
identify whether a given username is valid.
Username enumeration typically occurs either on the login
page, for example, when you enter a valid username but an
incorrect password, or on registration forms when you enter
a username that is already taken.

23.

Vulnerabilities in password-based login.
Username enumeration
While attempting to brute-force a login page, you should pay particular attention to
any differences in:
Status codes: During a brute-force attack, the returned HTTP status code is likely
to be the same for the vast majority of guesses because most of them will be
wrong.
Error messages: Sometimes the returned error message is different depending on
whether both the username AND password are incorrect or only the password was
incorrect. It is best practice for websites to use identical, generic messages in
both cases, but small typing errors sometimes creep in. Just one character out of
place makes the two messages distinct, even in cases where the character is not
visible on the rendered page.
Response times: If most of the requests were handled with a similar response
time, any that deviate from this suggest that something different was happening
behind the scenes. This is another indication that the guessed username might be
correct. For example, a website might only check whether the password is correct
if the username is valid. This extra step might cause a slight increase in the
response time. This may be subtle, but an attacker can make this delay more
obvious by entering an excessively long password that the website takes
noticeably longer to handle.

24.

Vulnerabilities in password-based login.
Flawed brute-force protection
It is highly likely that a brute-force attack will involve many failed guesses
before the attacker successfully compromises an account. Logically, bruteforce protection revolves around trying to make it as tricky as possible to
automate the process and slow down the rate at which an attacker can
attempt logins.
The two most common ways of preventing brute-force attacks are:
Locking the account that the remote user is trying to access if they make too
many failed login attempts
Blocking the remote user's IP address if they make too many login attempts in
quick succession

25.

Vulnerabilities in password-based login.
Flawed brute-force protection
For example, you might sometimes find that your
IP is blocked if you fail to log in too many times.
In some implementations, the counter for the
number of failed attempts resets if the IP owner
logs in successfully. This means an attacker would
simply have to log in to their own account every
few attempts to prevent this limit from ever
being reached.

26.

Vulnerabilities in password-based login.
Account locking
One way in which websites try to prevent brute-forcing is to
lock the account if certain suspicious criteria are met,
usually a set number of failed login attempts. Just as with
normal login errors, responses from the server indicating
that an account is locked can also help an attacker to
enumerate usernames.

27.

Vulnerabilities in password-based login.
Account locking
For example, the following method can be used to work around this kind of
protection:
-Establish a list of candidate usernames that are likely to be valid. This could be
through username enumeration or simply based on a list of common usernames.
-Decide on a very small shortlist of passwords that you think at least one user is
likely to have. Crucially, the number of passwords you select must not exceed
the number of login attempts allowed. For example, if you have worked out that
limit is 3 attempts, you need to pick a maximum of 3 password guesses.
-Using a tool such as Burp Intruder, try each of the selected passwords with each
of the candidate usernames. This way, you can attempt to brute-force every
account without triggering the account lock. You only need a single user to use
one of the three passwords in order to compromise an account.

28.

Vulnerabilities in password-based login.
User rate limiting
Another way websites try to prevent brute-force attacks
is through user rate limiting. In this case, making too
many login requests within a short period of time
causes your IP address to be blocked. Typically, the IP
can only be unblocked in one of the following ways:
Automatically after a certain period of time has elapsed
Manually by an administrator
Manually by the user after successfully completing a
CAPTCHA

29.

Vulnerabilities in password-based login.
User rate limiting
User rate limiting is sometimes preferred to
account locking due to being less prone to
username enumeration and denial of service
attacks.

30.

Vulnerabilities in multi-factor
authentication
Verifying biometric factors is impractical for most websites. However, it is increasingly
common to see both mandatory and optional two-factor authentication (2FA) based on
something you know and something you have. This usually requires users to enter both a
traditional password and a temporary verification code from an out-of-band physical device
in their possession.
It is also worth noting that the full benefits of multi-factor authentication are only
achieved by verifying multiple different factors. Verifying the same factor in two
different ways is not true two-factor authentication. Email-based 2FA is one such
example.

31.

Vulnerabilities in multi-factor authentication.
Two-factor authentication tokens
Verification codes are usually read by the user from a physical device of some kind.
Many high-security websites now provide users with a dedicated device for this purpose,
such as the RSA token or keypad device that you might use to access your online banking
or work laptop.
In addition to being purpose-built for security, these dedicated devices also have the
advantage of generating the verification code directly. It is also common for websites to use
a dedicated mobile app, such as Google Authenticator, for the same reason.

32.

Vulnerabilities in multi-factor authentication.
Two-factor authentication tokens
On the other hand, some websites send verification codes to a user's mobile
phone as a text message. While this is technically still verifying the factor of
"something you have", it is open to abuse. Firstly, the code is being
transmitted via SMS rather than being generated by the device itself. This
creates the potential for the code to be intercepted. There is also a risk of
SIM swapping, whereby an attacker fraudulently obtains a SIM card with the
victim's phone number. The attacker would then receive all SMS messages
sent to the victim, including the one containing their verification code.

33.

Vulnerabilities in multi-factor authentication.
Bypassing two-factor authentication
At times, the implementation of two-factor authentication is flawed to the
point where it can be bypassed entirely.
If the user is first prompted to enter a password, and then prompted to enter
a verification code on a separate page, the user is effectively in a "logged in"
state before they have entered the verification code. In this case, it is worth
testing to see if you can directly skip to "logged-in only" pages after
completing the first authentication step. Occasionally, you will find that a
website doesn't actually check whether or not you completed the second step
before loading the page.

34.

Vulnerabilities in other authentication
mechanisms. Keeping users logged in
A common feature is the option to stay logged in even after closing a browser
session. This is usually a simple checkbox labeled something like "Remember
me" or "Keep me logged in".
This functionality is often implemented by generating a "remember me" token
of some kind, which is then stored in a persistent cookie. As possessing this
cookie effectively allows you to bypass the entire login process, it is best
practice for this cookie to be impractical to guess

35.

Vulnerabilities in other authentication
mechanisms. Resetting user passwords
In practice, it is a given that some users will forget their
password, so it is common to have a way for them to reset
it.
As the usual password-based authentication is obviously
impossible in this scenario, websites have to rely on
alternative methods to make sure that the real user is
resetting their own password.
For this reason, the password reset functionality is
inherently dangerous and needs to be implemented securely.

36.

Vulnerabilities in other authentication
mechanisms. Sending passwords by email
There are a few different ways that this feature is commonly implemented, with
varying degrees of vulnerability.
It should go without saying that sending users their current password should
never be possible if a website handles passwords securely in the first place.
Instead, some websites generate a new password and send this to the user via
email.
Generally speaking, sending persistent passwords over insecure channels is to be
avoided. In this case, the security relies on either the generated password
expiring after a very short period, or the user changing their password again
immediately. Otherwise, this approach is highly susceptible to man-in-the-middle
attacks.

37.

Vulnerabilities in other authentication
mechanisms. Resetting passwords using a URL
A more robust method of resetting passwords is to send a unique URL to users
that takes them to a password reset page. Less secure implementations of this
method use a URL with an easily guessable parameter to identify which account
is being reset, for example:
http://vulnerable-website.com/reset-password?user=victim-user
A better implementation of this process is to generate a high-entropy, hard-to-guess
token and create the reset URL based on that. In the best case scenario, this URL
should provide no hints about which user's password is being reset.
http://vulnerable-website.com/resetpassword?token=a0ba0d1cb3b63d13822572fcff1a241895d893f659164d4cc550b421
ebdd48a8

38.

Vulnerabilities in other authentication
mechanisms. Resetting passwords using a URL
When the user visits this URL, the system should check whether this token
exists on the back-end and, if so, which user's password it is supposed to reset.
This token should expire after a short period of time and be destroyed
immediately after the password has been reset.
However, some websites fail to also validate the token again when the reset
form is submitted. In this case, an attacker could simply visit the reset form from
their own account, delete the token, and leverage this page to reset an arbitrary
user's password.

39.

Vulnerabilities in other authentication
mechanisms. Resetting passwords using a URL
If the URL in the reset email is generated dynamically, this
may also be vulnerable to password reset poisoning. In this
case, an attacker can potentially steal another user's token
and use it change their password.

40.

Vulnerabilities in other authentication
mechanisms. Changing user passwords
Typically, changing your password involves entering your current password and
then the new password twice. These pages fundamentally rely on the same
process for checking that usernames and current passwords match as a normal
login page does. Therefore, these pages can be vulnerable to the same
techniques.
Password change functionality can be particularly dangerous if it allows an
attacker to access it directly without being logged in as the victim user. For
example, if the username is provided in a hidden field, an attacker might be
able to edit this value in the request to target arbitrary users. This can
potentially be exploited to enumerate usernames and brute-force passwords.

41.

OAuth 2.0 authentication vulnerabilities
OAuth is a commonly used authorization framework that
enables websites and web applications to request limited
access to a user's account on another application.
Crucially, OAuth allows the user to grant this access without
exposing their login credentials to the requesting
application. This means users can fine-tune which data
they want to share rather than having to hand over full
control of their account to a third party.

42.

OAuth 2.0 authentication vulnerabilities.
How to work?
OAuth 2.0 was originally developed as a way of sharing access to specific data
between applications. It works by defining a series of interactions between
three distinct parties, namely a client application, a resource owner, and the
OAuth service provider.
Client application - The website or web application that wants to access the
user's data.
Resource owner - The user whose data the client application wants to access.
OAuth service provider - The website or application that controls the user's
data and access to it. They support OAuth by providing an API for interacting
with both an authorization server and a resource server.

43.

OAuth 2.0 authentication vulnerabilities.
How to work?
Broadly speaking, both of these grant types involve the following stages:
1.
The client application requests access to a subset of the user's data, specifying
which grant type they want to use and what kind of access they want.
2.
The user is prompted to log in to the OAuth service and explicitly give their
consent for the requested access.
3.
The client application receives a unique access token that proves they have
permission from the user to access the requested data. Exactly how this
happens varies significantly depending on the grant type.
4.
The client application uses this access token to make API calls fetching the
relevant data from the resource server.

44.

OAuth authentication
OAuth authentication is generally implemented as follows:
The user chooses the option to log in with their social media account. The
client application then uses the social media site's OAuth service to request
access to some data that it can use to identify the user. This could be the
email address that is registered with their account, for example.
After receiving an access token, the client application requests this data from
the resource server, typically from a dedicated /userinfo endpoint.
Once it has received the data, the client application uses it in place of a
username to log the user in. The access token that it received from the
authorization server is often used instead of a traditional password.

45.

How do OAuth authentication
vulnerabilities arise?
OAuth authentication vulnerabilities arise partly because
the OAuth specification is relatively vague and flexible by
design. Although there are a handful of mandatory
components required for the basic functionality of each
grant type, the vast majority of the implementation is
completely optional. This includes many configuration
settings that are necessary for keeping users' data secure.
In short, there's plenty of opportunity for bad practice to
creep in.

46.

Identifying OAuth authentication
The most reliable way to identify OAuth authentication is to proxy your traffic
through Burp and check the corresponding HTTP messages when you use this
login option. Regardless of which OAuth grant type is being used, the first
request of the flow will always be a request to the /authorization endpoint
containing a number of query parameters that are used specifically for OAuth.
In particular, keep an eye out for the client_id, redirect_uri, and
response_type parameters. For example, an authorization request will usually
look something like this:
GET /authorization?client_id=12345&redirect_uri=https://clientapp.com/callback&response_type=token&scope=openid%20profile&state=ae1
3d489bd00e3c24 HTTP/1.1
Host: oauth-authorization-server.com

47.

Recon
Doing some basic recon of the OAuth service being used
can point you in the right direction when it comes to
identifying vulnerabilities.
Once you know the hostname of the authorization server,
you should always try sending a GET request to the following
standard endpoints:
/.well-known/oauth-authorization-server
/.well-known/openid-configuration

48.

11 Common Authentication
Vulnerabilities You Need to Know
Also,
you’ll learn about the most common
authentication-based
vulnerabilities
and
their
implications. By the end, you’ll know the best
practices to prevent these authentication issues and
keep sensitive data safe.
According to Statista, more than 1,000 data breaches
in 2020 exposed over 155 million records. These
breaches resulted in an average cost of $3.86 million.
It’s even more nerve-racking to know that over 82% of
breaches were caused by authentication issues —
stolen or weak credentials.

49.

What Are Authentication
Vulnerabilities?
Authentication
vulnerabilities are issues
that affect authentication processes and
make websites and applications susceptible
to security attacks in which an attacker can
masquerade as a legitimate user.

50.

11 Most Common Authentication
Vulnerabilities
1. Flawed Brute-Force Protection
If there’s a flawed brute-force protection system such as a flaw in the
authentication logic, firewall, or secure shell (SSH) protocol, attackers can
hijack login credentials and processes, compromising the security of user
credentials.
2. Weak Login Credentials
When users register for an account on a site or application that uses passwordbased logins, they’re prompted to create a username and password.
However, if the password is predictable, this can lead to vulnerabilities in the
authentication process. Predictable usernames can make it easier for attackers
to target specific users.

51.

11 Most Common Authentication
Vulnerabilities
3. Username enumeration is not exactly an authentication vulnerability. But, it
can make an attacker’s life easier by lowering the cost for other attacks, such
as brute-force attacks or weak credential checks.
This process of username enumeration confirms whether or not a username is
valid. For example:
In this case, the username is correct but the password isn’t.
Here, the username is invalid.

52.

11 Most Common Authentication
Vulnerabilities
4. HTTP Basic Authentication
This classic web authentication protocol is easy to implement, however, it is not
without its risks.
HTTP basic authentication is simple, sending a username and password with
each request. However, if appropriate security protocols such as TLS session
encryption are not used for all communication, the username and password
information can be sent in the clear, making it easy for attackers to steal the
credentials.
Because the included credentials contain so little context, they can easily be
misused in attacks such as cross-site request forgeries (CSRF). Also, because
they are included with every single request, modern browsers normally cache
this information indefinitely, with minimal ability to "log out" and prevent a local
attacker from reusing the credential at some future point.

53.

11 Most Common Authentication
Vulnerabilities
5. Poor Session Management
A vulnerability in the management of session identifiers leads to hijacking of
valid authenticated sessions. This is one of the common web vulnerabilities to
bypass passwords.
There are several session mismanagement vulnerabilities such as no session
timeouts, exposure of session IDs in URLs, session cookies without the HttpOnly flag set, and poor session invalidation.
If attackers can seize control of an existing session, they easily get into a
system by assuming the identity of an already-authenticated user, bypassing
the authentication process entirely.

54.

11 Most Common Authentication
Vulnerabilities
6. Staying Logged In
A "Remember me" or "Keep me logged in" checkbox beneath a login form
makes it super easy to stay logged in after closing a session. It generates a
cookie that lets you skip the process of logging in.
However, this can lead to a cookie-based authentication vulnerability if an
attacker can predict a cookie or deduce its generation pattern. They can use
malicious techniques like brute-force attacks to predict cookies, and cross-site
scripting (XSS) to hack user accounts by allowing a malicious server to make
use of a legitimate cookie.
If a cookie is poorly designed or protected, attackers may be able to obtain
passwords or other sensitive (and legally protected) data such as user
addresses or account information from a stored cookie.

55.

11 Most Common Authentication
Vulnerabilities
7. SQL Injection
SQL injection is an attack vector that uses malicious SQL code input in an
unexpected way to manipulate and access a database.
SQL injections can enable attacks on authentication mechanisms by stealing
relevant data (such as poorly protected password hashes) from an unprotected
database. They can also bypass authentication mechanisms if the injected SQL
code is executed by an internal (and already authorized) tool that failed to
sufficiently validate external input.

56.

11 Most Common Authentication
Vulnerabilities
8. Unsecure Password Change and Recovery
Sometimes, users forget or just want to change their passwords and click the
"Forgot password" or "Lost your password" links.
The password reset process poses an authentication vulnerability if an
application uses a weak password recovery mechanism such as easy security
questions, no CAPTCHAs, or password reset e-mails with overly long or no
timeouts.

57.

11 Most Common Authentication
Vulnerabilities
9. Flawed Two-Factor Authentication
While two-factor authentication (2FA) is effective for secure authentication, it
can cause critical security issues if not well-implemented.
Attackers can figure out the four- and six-digit 2FA verification codes
through SIM swap attacks if they are sent through SMS. Some two-factor
authentication is also not truly two-factor; if a user is attempting to access
sensitive information on a stolen phone using cached credentials, a "second
factor" that sends a message to that same phone adds no additional security.

58.

11 Most Common Authentication
Vulnerabilities
10. Vulnerable Authentication Logic
Logic vulnerabilities are common in software applications. This occurs as a
result of poor coding or design that affects authentication and authorization
access, and application functionality.
Flawed application logic can be due to the abuse of functionality, weak security
measures, or a skipped step in the verification procedure.
For example, an application can prompt a user to answer a security question
the logic deems as something "only the correct person would know." But
questions like the user’s birthday or mother’s maiden name are often easy to
discover. This vulnerability makes it easy for cyber attackers to bypass
authentication and gain illegal access to such accounts.

59.

11 Most Common Authentication
Vulnerabilities
11. Human Negligence
According to Shred-it 2020 report, up to 31% of C-suite executives reported
employee negligence to be the second major cause of their data breaches.
Human error can result in serious authentication vulnerabilities that are far
easier to take advantage of than brute-force attacks, SQL injections, and
authentication bypasses. This negligence includes actions such as:
Leaving a computer on and unlocked in a public place
Losing devices to theft
Leaking sensitive information to strangers
Writing bad code