Authentication and Authorization

INF 203
 Authentication
Often sites have restricted non-public functionality. To access this resources
user must go through login functionality. First of all, he must identify himself. But if
I’m identifying myself as Bill Gates, it doesn’t mean that I’m one. As a result, I
must authenticate, i.e., determine that I’m really who I claim to be. In real world it
would be showing a passport or driver’s license.
So, authentication is an act of confirming the identity. This process ensures
that contents are accessed only if the user has the rights to do so.
For example, we often login with username and password. In such cases,
username – is an identification of user, when password is authentication factor of
that user.
Authorization

Authorization is the function that specifying what you are able to do.
Authentication and authorization both are similar words, and often
confused for each other, so keep in mind the difference.

For example, if you are a student, and you can claim that you are a teacher and read
a lecture – you broke authentication mechanism (you verified yourself as a different
person). If you able to go into teachers lounge, where all know that you are a
student, and still put marks for recent exam instead of actual professor – you broke
authorization mechanism (you performed an action, that you normally cannot do)
 The ways in which someone may be
authenticated called authentication factors. They can
be based on what user knows, owns or is. There are 3
types of factors:
• Knowledge factors – something that user knows, e. g.
Authentication password, PIN, secret question.
factors • Ownership factors – something that user has, e. g.
security token, mobile phone, bank card.
• Inherence factors – something that user is or does,
e.g., fingerprint, retinal pattern, DNA sequence,
signature, face, voice, unique bio-electric signals, or
another biometric identifier.
Single-, two- and
multi-factor
authentication
 The single-factor authentication requires a user to
provide just one of the factors.

Usually for web applications it is a password

(knowledge factor).
 The two-factor (or multi-factor - MFA)
authentication requires a user to provide two (or
more) of the factors.
For example, many web applications require,
besides password, an SMS or OTP (one- time-
password) code.
AAA
concept
 Access Control Models
Applications may Discretionary Access Control (DAC) – least restrictive model where users
differently define can decide which parties can access resources that they own. Example –
access control – Google Drive where you can give access to the files you uploaded
which user can Mandatory Access Control (MAC) – model where owner manages roles of
access different other users
resources. There
are several
Role Based Access Control (RBAC) – user can access the resource if he have
common models proper role
which are used in
implementations:
Rule Based Access Control (RBAC) – the are rules defined to accessing the
resource. For example, you need to be part of some DL (delivery list).
 COMMON VULNERABILITIES

CONFIDENTIAL
Credentials over unencrypted
channel
Let’s dig into common vulnerabilities for username +
password authentication.
First of all, all sensitive data, including credentials, must
be transmitted over encrypted channel.
Because of star-topology of ethernet and wi-fi based
networks, all the hosts in the local network see unencrypted
traffic from other hosts, so sniffing is an easy option. But if it
somehow not possible – attacker still may be able to
perform Man-In-The-Middle (MITM) attack and intercept the
credentials. It is crucial for web application to use HTTPS or
other protocols with encryption.
Inadequate Password Policy
A simple passwords can be easily guessed or brute-forced, so it is
an application job to ensure that users can choose only strong
passwords.

Attacker can attempt to guess passwords with dictionary attack –

meaning querying the authentication system with a set list of
words from wordlists (or dictionaries, such as SecLists,
SkullSecurity).

Brute-force attacks means that attacker will try all possible

combinations of defined character set to guess a password (or
tokens and etc.). This attack will cover all possible combinations,
even that user won’t probably choose, and will require much
more time to complete. Usually, it is best to perform this attack
only if dictionary attack has failed.
Strong password
policy
Password policies usually also include
rules, such as composition of characters
(at least one uppercase, at least one
lowercase, at least one digit and special
character), never use the same password
twice, regularly change password, do not
include personal info in passwords.
OWASP ASVS recommends at least 12
symbols in passwords (8 symbols can be
brutted in offline attack with help AWS).
Password
storage
•On a server side, passwords must be stored
in hashed (with salt) state and never be
stored in clear text.

•If an attacker would be able to access

unhashed password storage, he will be able
to access any user account with them.
Lockout
For defending against online brute-force and
dictionary attacks, an application can identify
an attack and block attacker’s authentication
requests.
It can do that in the following ways:

• Add an increasing delay after each failed

login attempt

• Show a CAPTHA after several (usually 3)

failed login attempts

• After 10 failed attempts, lock a user for a

certain amount of time
 User enumeration
As we mentioned before, simple application accept
username (user ID) and password as an authentication
mechanism and let in a user only if they are both correct.

So having a user ID is a half of what we are need to

login. Improperly implemented systems can reveal information
about existence of user. It is not considered a direct threat,
but it is a good practice not to avoid such behavior.

For example, error message for login (or password reset

function) can reveal the state of user: “Incorrect username”,
“User is disabled”, “Account has been deleted”, “Invalid
password”.

Good error message does not reveal any info: “Login or

password are incorrect”.
Default credentials
Most of the software and devices
come with default credentials. SQL servers,
web administrator consoles, web-cameras, all
of those can be easily accessed in cases
Information Gathering section and then look
up for default credentials for when default
password wasn’t changed. And tests against
such vulnerabilities are simple: you define
what components are used with help of
what you learned in discovered components
with google or in the GitHub for open source
projects. “admin:admin” is a lucky number in
this step.
Also, developers can create test user
account for ease of application testing, such
accounts usually contain weak credentials and
can be easily guessed.
Remember me

Typing credentials each time when you are visiting a web site is an
exhausting. To avoid that, applications often introduce the
remember me functionality. It allows to remember user for a
long time after one successful login. It can be implemented by using
browser cache, by saving credentials in web storage or cookie.
The password input field must not be cached, because if attacker will
access the cache – it will easily recover passwords from there.
Especially when you are using a public computer. To be protected
from such attack, applications must disable the cache by using
autocomplete=“off” attribute.
 Remember me
Application may store credentials in the cookie for
remember me functionality, or give a user session id with a
long lifetime. The first variant is bad and insecure, because if
attacker would be able to steal the cookie, it receive not
limited in time access to application, but full and as a bonus
if password was stored unencrypted will try to use this
credentials on other resources that the same user uses.
Cookie can be stolen with XSS in cases when it does not
have HttpOnly flag or with MITM attacks.
With a Web Storage situation is similar to cookie, but we
don’t have a XSS protection. Best defense is not to store
passwords on client side. And at least encrypt them if do.
Password reset feature
Users who forgot their passwords must have a way to
reset it. And surely it must be safe.
Usually, it is implemented by sending email to the
user with a new password or a password reset link.
As a first step to improve this process is to ask a
secret questions before sending the email. Answers to those
questions usually added by user upon account creation. And
they must be known only by the owner of the account, so it’s
just like another password.
Applications must suggest recommendations for it, so
user won’t choose easily guessed answers.
Logout weaknesses
Another session weakness can exist in
logout. It is can occur either when session
timed out or when user voluntarily logs
out.
On the server side, a logout is freeing up
the session data that corresponds to
session id. If server does it improperly or
not does at all, an attacker can reuse this
session after gaining a session token that
was previously used even if user have been
logged out.
CAPTCHA
•Completely Automated Public Turing test to tell
Computers and Humans Apart or CAPTCHA is a test
used by many web applications to ensure that the
response is not generated by a computer.

•It can be used for prevention of brute-force attacks

that usually performed by bots and would take ages to
do so by humans. It is not an easy task to implement a
good and a secure one, even when using a third-
party component, and there were a lot of
vulnerabilities in old implementations. And sometimes
it is easy and cheap to hire a people to solve it for
you.

•So CAPTCHA can only add a small security protection

against attackers.
 BYPASSING AUTHORIZATION

CONFIDENTIAL
 Bypassing authorization
Lets dig into another set of common vulnerabilities that bypass authorization.
Usually this kind of vulnerabilities exist because of logical errors in application code.
First is Broken Access Control. It occurs when restrictions on what authenticated users
are allowed to do not properly enforced. As an old OWASP Top 10, this vulnerability
was divided into two: Insecure Direct Object Reference (IDOR) and Missing Function
level Access Control (MFAC). First occurred when user was able to access resources
that he wasn’t allowed to access and second occurred when user was able to perform
an action (function) that he wasn’t allowed to do. But this classification confused a lots
of people, so it was decided to merge both of them into one.
 Broken access control
For resource access it usually an easy exploitation: attacker can
simply change a parameter value (such as fileID) that refers to
another object. Link can look like this:
http://example.com/download?id=101. The first thing is to try
different IDs and determine a files that not ours. If you are able to
view foreign file – it is a Broken Access Control vulnerability.

The same is for the actions, if you see a word view in URL, you
probably can change it to edit or delete and see what happens. The
same with GET/POST->PUT/DELETE verbs.

To defend against this kind of attack developers must write code

that checks current user permission before giving him resources on
each and every action that application can do.
Incorrect Redirection

Often applications redirect users to error or home pages

when they determine that user cannot access requested
resource. Generally it writes a value in Location HTTP
header, which browser then visits without even
rendering code that was in the application response.
But if we look into this code, by using an interception
proxy or performing a request by tools such as Curl, we
would see a sensitive data that we wouldn’t supposed to
see…
This vulnerability exist because developers forget to
end a script execution after determining that user
won’t allowed to see it.
Weak Session ID

Session ID or session token usually is just a

number that assigned to client after login and will be
used by server to identify the client in subsequent requests.
Obviously, if an attacker would be able to guess
the ID and send in to the server, the server will identify
the attacker as an successfully logged client.
So, to make impersonation of users impossible, IDs
must have the following properties:
• Purely random and unpredictable
• Valid only for single session
• Time-limited
 Other bypasses
Attacker can also use injections (SQL, NoSQL,
XPath, LDAP, command) to bypass an
authentication or steal user sessions.

Such vulnerabilities can exist on a login page and you

can bypass an authentication with an input similar to:
admin‘ or 1=1 -- -.
File attacks such as Path Traversal also can help you to
bypass authorization controls and access resources
out of your reach.
Keep in mind such possibilities when trying to bypass
authentication and authorization.