0% found this document useful (0 votes)
141 views3 pages

Authentication Bypass

Uploaded by

harshyadav1361
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
141 views3 pages

Authentication Bypass

Uploaded by

harshyadav1361
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

Authentication Bypass

Authentication in web applications is a familiar concept. When attacking an authentication mechanism,


there are many ways to go about it, and usage of other exploits can supplement or even give way to
authentication bypass. This is not really an exploit per se, but rather something attackers look out for.

Exploitation

Generally, we look out for logic vulnerabilities or developers failing to implement some features safely.
These include:

• Usage of easy to brute force credentials

• 2FA measures that aren't well secured.

o For example, a 2FA measure that has a 6 digit PIN but has unlimited tries for it.

• Phishing or Social Engineering Attacks to gain passwords.

• SQL Injection, XSS or other vulnerabilities.

• Lack of account lockout after repeated failed attempts (anti-brute forcing mechanisms)

Personally, when I'm testing for authentication vulnerabilities, I would ask myself the following
questions:

• How does the authentication verify the user?

• What kind of parameters are being passed into the database?

o POST parameters

o JSON

• What is being used to authenticate a user and save their login session?

o Are the cookies decryptable like JWT?

o Can I poison the web cache or smuggle a HTTP request into the backend?

• Is the login sending a request of some form into a backend database? Or is it running purely on
Javascript

o This can be seen if we proxy the requests through Burpsuite

• Is there any other information being processed and passed into the web application?

o For example, are any other parameters, like userID being used?

• Is the website running an outdated version of software that has known exploits for it?

• Are there Web Application Firewalls or Intrusion Detection that would trigger upon entering of
special characters into the database?
Example

Suppose that we have a web application that uses a JWT token to authenticate a session.

JWT Tokens are basically base64 encoded strings separated into 3 different portions, and they are
decryptable or spoofable once we have the private key to encode it properly.
This particular application runs on Flask, and Flask JWT Tokens are actually decryptable and we can find
the secret tokens from this.

Then, we can create a new cookie with whatever username we like. In this case, the username blue was
the admin of the page.

With this new cookie, we can simply swop out the value of the Cookie header we found earlier and be
able to login as this new user. This can also be done using Javascript in the browser console with
developer.cookie='cookiehere'.

You might also like