AUTHORIZATION

Prepared by: Dr. Alia Alabdulkarim

‫‪Recording Lectures‬‬
‫ﻧﻈًﺮا ﻟﻤﺎ ﺗﻢ ﻣﻼﺣﻈﺘﻪ ﻣﻦ ﺗﻜﺮار ﻣﺨﺎﻟﻔﺔ اﻟﺘﺴﺠﯿﻞ اﻟﺼﻮﺗﻲ‪/‬اﻟﻤﺮﺋﻲ ﻣﻦ دون اذن اﻟﺸﺨﺺ‬
‫اﻟﻤﺴﺠﻞ وﺟﮫﻞ اﻟﻄﺎﻟﺒﺎت ﺑﺄن ھﺬا اﻟﻌﻤﻞ ﻳﻌﺘﺒﺮ ﻣﺨﺎﻟﻔﺔ وﺗﺪاوﻟﻪ ﻳﻨﺪرج ﺗﺤﺖ اﻟﺠﺮاﺋﻢ اﻟﻤﻌﻠﻮﻣﺎﺗﯿﺔ‬
‫)اﻟﻔﻘﺮة اﻟﺜﺎﻟﺜﺔ ﻣﻦ اﻟﻤﺎدة اﻟﺨﺎﻣﺴﺔ( واﻟﺬي ﻳﻌﻨﻰ ﺑﺎﺳﺘﺨﺪام وﺳﺎﺋﻞ ﺗﻘﻨﯿﺎت اﻟﻤﻌﻠﻮﻣﺎت ﻟﻠﺘﺸﮫﯿﺮ‬
‫ﺑﺎﻵﺧﺮﻳﻦ وإﻟﺤﺎق اﻟﻀﺮر ﺑﮫﻢ‪ .‬وﻳﻌﺎﻗﺐ ﻋﻠﯿﮫﺎ ﺑﺎﻟﺴﺠﻦ ﻣﺪة ﻻ ﺗﺰﻳﺪ ﻋﻦ ﺳﻨﺔ وﺑﻐﺮاﻣﺔ ﻻ ﺗﺰﻳﺪ ﻋﻦ‬
‫ﺧﻤﺴﻤﺎﺋﺔ أﻟﻒ ﷼ أو ﺑﺈﺣﺪى ھﺎﺗﯿﻦ اﻟﻌﻘﻮﺑﺘﯿﻦ‪.‬‬
Authorization (AuthZ) Fundamentals
Authorization: is the process of determining whether a subject has sufficient permission
to perform a given operation against a target resource.
Authorization is a complex subject.

Must take into consideration the characteristics of a web application and their resources

The requirements for authentication and authorization may well have been determined
in conjunction with local, regional, or national law. Example: HIPAA. You need to spend
some time during
early phases to
gather info about
Determining Resource laws that can govern
Subject Access (Object)
your web app.

3
Web Application Security

4
 Authorization Fundamentals

ACL : Access Control List

Read
Write

Authenticated means Who writes readable

User has session ID data (blood
examination)?
AuthZ 5
elements 1-Subject 2- Determining Access 3-Object (resources)
Authorization goals
There are three specific goals associated with it:
To ensure that users can only perform actions within their privilege level.

To control access to protected resources using criteria based on a user’s role or

privilege level.

To mitigate privilege escalation attacks, such as might enable a user to access

administrative functions while logged on as a non-administrative user or potentially
even an anonymous guest user.

6
Authorization Elements
1.Subjects
The thing requesting access to protected resources

KSU
Student LMS
DB 7
Authorization Elements
2.Resources (Objects)
The protected objects: data or functionality
File

Database

Programs

How a web application knows what the resource in question is for any given access request?

1. Encoded in URL parameters: http://www.MyHometownNewspaper.com/archives?article=0029385923

2. Encoded as path components within the URL: http://www.amazon.com/Animal-Farm-Anniversary-

George-Orwell/dp/B000KWSLAO

3. Encoded or identified by data stored within the session state à adds little security

8
Session State

Most browsers restrict cookie size to 4096 bytes

9
Authorization Elements
3. Determining Access
Once the web application has determined the subject and what the subject wants to
do, it can determine whether the action is permitted
Through rules: many names permissions, access control, policies..

We have heterogeneous techniques to define and enforce these rules. Among these
techniques, we can highlight two:

Permission-based authorization
defines permissions to each system’s user

Role-based authorization
specifies permissions to a set of roles of a system, roles assigned to each user.
10
Authorization Elements
3.Determining Access
1. Policies: ACL are permissions that are applied to a specific resource
ACL combines particular subjects, operations, and target resources into discrete
bundles

They can be fine-grained and flexible è More active administration

Can we make exceptions?

What we need to get full access

to resources?

11
Authorization Elements
3.Determining Access
2. Role-based authorization labels resources with groups of subjects (roles)
Requires two-stage decision:
Assessing what roles can perform the requested action

Determining whether the subject is a member of any

of these roles

Less flexible èeasier to administer

Can we make exceptions?

We need to create a new special role to hold
subject(s) who need to have that exception.
Which style to choose is one of the key decisions
12
Types of permissions
There are two kinds of resources that users attempt to access

Data

Functions

Both can have permissions, and there are three type of permissions:

Read access: ability to see what something is

Write access: ability to change something

Execute access: ability to run a piece of code in order to do something

13
Read & Write permission Execute permission
 (‫بداية التسجيل )كنت غايبه في اللي قبل‬

Authorization Layers (Reading assignment)

Authorization is NOT a one-time thing.

We have four layers in web applications:

Web browser layer

Web server layer (static content)

Application server layer (dynamic content)

Database server layer

AuthZ (A2) should happen at many points and many times within a web app.

14
When and How to Authorized

15
 Authorization Layers (Reading assignment)
Traditional
computer
security concerns
with vertical
interaction
User to application (horizontally) Horizontally: it takes
place between
systems on the path
from user to app.
Interacting components

Vertically: it takes
(vertically)

place between
interacting
components within an
individual system.

16
Web browser layer Web server layer Application server layer Database server layer
Controls by layer (Horizontally)
Talk about potential authorization checkpoints in each layer.

Web server layer

IP Addressing Blacklisting
Ø Block IP who performs DoS. How?
Ø Drop request or 403 forbidden HTTP response

IP Addressing whitelisting
Ø internal private network (intranets)

URL Authorization (most java web server allows limit access to URL through setting or configuration files)
Ø specify which users and groups can access what URLs.

OS Authorization (web application| server must run in some context within the OS)
Ø Use OS native security framework of file and directory permissions, security group, ACL, ….
17
Ø Reduce damages when web applications are compromised
Controls by layer (Horizontally)
Application server layer
Can use the same basic techniques as the previous ones (IP black or white listing…). In addition to:
Application Compartmentalization
Servlet and App Server Restrictions
Ø Java implemented applications
Ø Use resource management configuration features
Ø Complex

Application Server Code

Ø Using the business logic within the web application to implement authorization
Ø Three ways to do it:
§ Use a built-in framework: Mircosoft’s .NET and ASP.NET platform
§ Use an existing, open plug-in authorization module: add features not present in frameworks

§ Develop a custom framework: significant responsibility

18
Code Access Security (CAS): performing authorization on pieces of code to determine whether the code is allowed
to run with the capabilities it wishes to use. >> executable permission
Controls by layer (Horizontally)
Database Server Layer
Databases have their own implementations of concepts like users, roles, permissions, and so forth

Take advantage of these features to implement part of the application’s authorization scheme

Ø Stored procedures à revoke direct access permissions from all the tables in the DB

§ What sort of measure we are made?

Ø User accounts: and reduce their permissions to the bare minimum

Procedures
• ___________
• ___________
Web
• ___________
Application Database
• ___________
• ___________ 19
Where should you put authorization logic

AuthZ logic: the code that enforces those permission policy decisions

1. Web application (Most popular)

+ Simplifies the design and development process

- Complicates deployment and maintenance: web admin and DB admin are different people

2. Database layer
Stored procedures can contain authorization logic

Before running that query, the stored procedure can first figure out whether the user making
the request is allowed to do so

or both
Which one is better? There is no right or wrong here. Just make sure you make the
decision for security reasons rather than convenience.
20
Custom authorization mechanisms
Not recommended (security code can be hard and tricky to get right)

You can’t receive any help and support

However, if you need to use your own custom authorization mechanism:

Any authorization framework should be designed around a 3-by-3 matrix of factors (also

referred to as a lattice).

It ensures you will consider all the critical authorization points in your application

Why is it necessary? (the 3-by-3 matrix)

Alternative: designers brainstorm a list of every place in the application that needs to consider
21
authorization. They can forget an important area that leaves your application open to attack.
The 3X3 model of authorization

2 axis:
1- What (3 categories of item of participant)
2- When (3 places)

The pairings between the items on each axis

of the matrix gives you a systematic basis for
designing your authZ framework.
22
The 3X3 model of authorization

What: considers the categories of items that participate in authorization

23
The 3X3 model of authorization
When: it considers the times when permission checks need to happen and approvals
granted or denied

To a degree, it also captures where these checks need to take place

• Before loading the interface

• Before requests are submitted

• Before granting final access

24
The 3X3 model of authorization
Before loading the interface
Web applications are not loaded at onceè distributed among a collection of HTML pages. It does not
need to make a one-time all-or-nothing decision.
They will perform authorization checks before ever sending that part of the interface to the user’s web
browser

There are two main ways to do it. It’s better to do both

Link filtering: web application omit the link for unauthorized user
Ø Hidden sensitive functionality from users who not authorized.

Ø It is not sufficient:
§ Vulnerable to forceful browsing
§ It should be done with each URL request
Ø Gives an HTTP response 401 unauthorized, 403 forbidden or 404 not found. Some are lies but never say truth!

Redirect upon direct URL access 25

Ø Root URL, terminating session , .. Other secure failure action…
Forceful Browsing

26
The 3X3 model of authorization
Before (HTTP|HTTPS) requests are submitted
Interactive web pages (run JavaScript) creates the possibility of using client-side code to
implement additional authorization checking
Warning: it is only for performance, it offers zero protection against determined attackers
Ø Save server time from dealing with request that will only be denied

Client-side code can deter casual attackers driven by curiosity more than actual malice. They
are trivial to bypass (Example: yellow warning tape around freshly poured section of sidewalk)

It can also filter the links. Its there but you can’t see it you can’t click it (using CSS or DOM).
Attackers can use reverse engineering to extract hidden links

It can also defend against a user interacting with UI elements at the wrong time.
Disable submit button when field has improper value
27
The 3X3 model of authorization
Client-side attacks Client-side checks are helpful for keeping
most users honest and for improving overall
CSS and JavaScript can be used to display the
places color code that show which is available system performance by keeping most bad
and which is reserved. requests from reaching the server side

But they are not a substitute for actual

authorization checks elsewhere

If the checks are only in the client side,

attackers can do tricks using browsers
extensions or intercept HTTP request and
change the seat number to pick whatever

https://www.smartertravel.com/
seat they want even it it’s shown to be not 28
available.
The 3X3 model of authorization
Before granting final access
The most important time to perform authorization checks, and the most important
place to perform them, is on the server immediately before granting final access to
anything
The server can be the web application server, the database server or both.
The strongest guarantees of security come from server-side authorization
The server is the last line of defense for those resources

The best time to make server-side authorization checks is as close as possible to the
time when an action is to be taken, to avoid the “time of check to time of use
(TOCTOU)” problem.
29
Ø Race condition vulnerability
 The 3X3 model of authorization
Time of check to time of use (TOCTOU)
The idea is to minimize the interval between these two times, because an overly lengthy
interval can create the potential for abuse

It can show up in two different forms:

Different person using an authenticated and authorized user’s account without permission
Ø Do an action on behalf of you.

Subject’s permissions may change

Web application servers should specify upper limit on the TOCTOU interval.

This limit represents a time beyond which the server isn’t even willing to trust its own prior
authorization checks 30
 TOCTOU exploits
Married couple example

Go to the
Sign-in to bank and
bank Go to take a
website meeting check

Open the Offer to Go home

fund give half and
transfer complete
form fund
transfer 31
Based on your experience with web apps, how can we avoid this problem?
form
TOCTOU exploits
Automatically invalidating the session
Solution to deal with TOCTOU problem: session management

Automatically invalidate sessions based on various criteria:

A session that has been idle for too long can be expired

A session that has simply been in existence for too long can be expired

A session can be forcibly expired if the timestamp on the permission records for the user is
newer than the creation timestamp of the session ID, thus indicating permission changes.

32
Web authorization best practices
(Reading assignment)
Failing closed Minimizing custom authorization
Fails securely
code
Operating with least privilege
Protecting static resources
Separating duties
users and admin Avoiding insecure client-side

Defining strong policies authorization tokens

Keeping accounts unique Using server-side authorization

Don’t allow users to share accounts
Mistrusting everybody
Authorizing on every request (direct before
preforming any action)

Centralizing the authorization mechanism (WHY?) 33

Attacks against authorization
Forceful browsing
Designers assume that users couldn’t have reached the URL unless they had permission to use the
functions exposed by this URL.

XSS maybe used in a completely unrelated website to obtain user’s browsing history à make a site map

Or by guessing: admin.php or main.html

That’s why we need to authorize on every request

Input authorization/parameter tampering

Occurs when an attacker or malicious user alters the parameters of a request before the request reaches
the web application

Any data stores in URL parameters, cookies, or form fields is subject to tampering.

Dan’s example. How we can address this problem?

34
Attacks against authorization
HTTP header manipulation
This generated by web client.

Contains metadata about the

request

Should never be trusted for

authorization, except for the
cookie holding the session ID

Attacker have control over it à

CSRF, SQL injection….

35
Attacks against authorization
Cross-site request forgery (CSRF) ‫ﺗزوﯾر‬
Occurs when an attacker tricks a victim’s browser into making an HTTP request against a
target web application

The victim is already authenticated à has SessionID

Example: attacker stole Joe’s web browsing history through XSS à online banking history
(purchases)
Ø à chat forum for vintage cars à crafts a post

Sensitive operations should be properly authorized, or require additional authorization 36

beyond a valid session ID
Session Management

37
Session Management
The key challenge is that HTTP is stateless
Example: two students logged on edugate

Sessions represent a user’s authentication and authorization for the duration of a user’s
interaction with your web application

Session management is the means by a client and server keep track of who a user is

It is also related to what that user is allowed to do, and what the user is actually doing

Is how the web server knows you are you, after you have been authenticated
Allow\deny access

Web application security is impossible without sessions

What’s a session?
Tracking a single user’s interactions with the web application 38
Session management fundamentals
A secure (encrypted) session ID will therefore look like random data

The harder you make it for an attacker to guess the value (Predictable session token),
the harder it is for them to impersonate an active session with the web application

39
Session management fundamentals
When to issue sessions IDs?

Many web applications issue a session ID at the time an unknown user performs the
application’s authentication procedure, but some do so before authentication
Example: filling the shopping cart before signing-in

Before completing the purchase, the user must sign-in à issue new session ID

Never reuse a session ID à let the web client dictate to you the session ID value
open you up to session fixation attack

If the applications doesn’t need to track user behavior prior to authentication à it’s safer
not to do it

40
What is session state
Session IDs help enormously by at least allowing a web application to tell different users apart

But they don’t track user’s information across a session

Shopping cart, your previous actions or previous requests

Common strategies to track user’s information across a session:

Cookie: content held in one or more client-side cookies
Ø Pros: easy to implement

Ø Cons: insecure, unless encrypted; and limited to 4KB of data, performance issue

Form fields and URL query parameters:

Ø Not secure

Ø URL parameters è length challenge

Web storage: introduced by HTML5 è client side

Ø Improves cookie storage issue, but we still can’t trust the client unless encrypted, not send with each request
41
What is session state
Common strategies (cont.):
Flash Local Shared Objects (LSOs): web applications using Adobe Flash Player
Ø Called also Flash cookie

Ø Same security issues as cookies

Silverlight isolated storage: Microsoft’s platform

Ø Client-side and server-side storage

Ø Client-side storage not considered secure unless encrypted

Server-side storage:
Ø Modern web application server implementations provide facilities for session state management

Ø Name/value pair associated with a user’s session ID

42
How to manage session state?

43
Attacks against sessions
Tampering
Also referred to as: cookie poisoning

Modifying the client-side session ID or other data to bypass authorization checks

Relies on session state being stored in any client-side data storage such as cookies or form fields.
Example: storing permission level in cookies

Theft
Stealing the session ID value to impersonate the victim
Mitigations are generic (see Session Management Best Practices )

Ø XSS: trick the victim in running a script to transmit the cookies on their browser

Ø Intercept by using packet sniffer who has access to the network

§ SSL and HTTPS (reading assignment) 44
Attacks against sessions
Predictability
Session IDs should not be predictable

Attacker can then generate the next 100 or 1000 session IDs and wait for a user to be assigned one of them

Session fixation
When an attacker is able to prepopulate a victim’s web browser with session ID value

Mitigation:
Ø Not issue before authentication

Ø Or issue a new one (not to reuse session IDs)

Session hijacking
Use a stolen or fixated session ID to impersonate a legitimate user è prevent the user from using it

45
Attacks against sessions
Cross-site request forgery
Cause the victim’s browser to take a single desired action within the application

It exploits the trust between the application and the client based on the session ID

Works by tricking the web browser into making a request for a URL à hidden elements

Attacker cannot predict when the victim might take the bait (if ever)
Ø Succeed attack: hijacking a still used session, or been idle for a long period of time

Mitigation: session expiration

46
Attacks against session state
Sessions and session state go hand in hand

Two principal concerns: data tampering and data hijacking

Tampering: when an attacker is able to alter elements within a session state
Ø Dan’s example

Hijacking: when an attacker is able to steal the contents of the session state

Ø E-commerce web site à identity theft

Mitigation: client-side à encryption. Or just store everything at server-side

47
Session Management Best Practices
(Reading Assignment-Page 141)
Enforcing absolute session timeouts

Enforcing idle session timeouts

Limiting session concurrency (active session single user can have - sessions per user)

Mandating secure cookies (secure tag – uses ssl and https)

Using the HttpOnly flag

Using cryptographically random session IDs

Destroying invalidated session IDs

Using encrypted cookies

Logging out
48
Regenerating session IDs on Authentication
References
Web Application Security: A Beginner’s Guide

Chapter 4

49