Hello and welcome back.
In this lesson, we are going to talk about
enforcing access control with session management.
Specifically, we're going to
talk about what access control
is and the relationship between authentication,
session management and access control.
Then, we're going to talk about
the two different kinds of
privilege attacks including, vertical and horizontal.
Last, we're going to talk about
specifying explicitly about how users are
going to be able to access
resources and how they will be able to do that.
At the end of this lesson,
you'll be able to distinguish
the relationship between authentication,
session management and access control. Let's get started.
Access control can be defined using three components.
First, there's the principle.
A principle is a user or a processor machine.
The second component is
the action that is allowed by that principle.
The third component is
the resource to be acted upon by that principle.
Basically, we want to define how we can control
which principle is allowed to access which resources.
Access control only makes
sense if you know what you're protecting.
There are several kinds of access control models.
One we're going to talk about,
specifically is called role-based access control
and that's where users are assigned to
functional roles like for example:
administrator or regular user or guest.
These different functional roles
have different sets of privileges.
Now, there are other kinds.
One that I can mention here is
discretionary access control and that's where owners of
resources grant access to
other users to access their resources.
If those owners of those resources don't
explicitly grant access to those resources,
access is automatically denied.
Another access control model is something
called identity-based access control.
That's where a user is
allowed access to a resource only if they
appear in a certain whitelist
of allowed users for that particular resource.
There are several more that aren't mentioned here,
but you can find the others online.
Again, to simplify we're going to
focus on role-based access control in this video.
Looking at the bigger picture,
authentication validates the principles identity
and initiates this creation of the session.
Recall that session management keeps track
of the state while the application is in use.
During this session, access control acts
as a gatekeeper to application resources.
Notice in this diagram that
access control is in its own component.
It's best practice to make
sure that the functionality for
access control is in its own centralized module,
so that programming mistakes are
reduced as well as for making functional testing easier.
Moving on to the two broad privilege attack types.
The first kind is called vertical privilege attack.
These are attacks where an attacker
attempts to gain more abilities
to be able to modify or act upon a resource.
For example, when an attacker starts out
as a user with regular user privileges,
then escalates their privileges to be able to
gain administrator user privileges.
In contrast, horizontal privilege attacks
are when an attacker is able to
access more than the resources
to which he or she has been given access.
For example, if initially I am user one and
it was intended that I could
only access or act upon file one,
but it turns out that because of a flaw in
the web application I can also act upon file two,
which I as user one I'm not supposed to
access because I don't own it and user two owns it.
So, that is an example of a horizontal privilege attack.
What we want to do to make sure that we create
a good access control system for
our web application is during the design phase,
we want to specify specifically who or
what has access to which resource and how.
You can specify your access control policy
using a tuple of principle,
access type and resource.
For example, here I have the principle of employee.
My access type is "put".
So, I'm talking in terms of a restful action here.
My resource is emp1/resource.jpg.
However, when you have many principles,
expressing your access control policy in this manner can
be cumbersome because if you could imagine,
if you have many principles,
you would have a huge list of tuples.
What is commonly done is to squash
the first column of principles into,
basically bucket them into groups or roles.
A group is the function assumed by
a user at a particular time.
For example, at an administrator
or a regular user or a guest for example.
So now, here are some best practices for setting
up an access control system in your web application.
What I had mentioned previously is we want to
explicitly design your access control security policy.
Another thing you want to make sure to do is to
express the access rights
during a session on the server side.
So in other words, don't trust
any user controlled data to signify access rights.
So you could imagine a counter example is,
if a URL has admin equals true on it and that is how
the web application signifies whether
the access for admin rights is true or is okay.
Now, in this case we
wouldn't want to do that because that
is incomplete control by the client side.
We don't want to trust that data.
Another thing that we want to do is to
always validate user controlled data.
We want to make sure to have
the access control functionality
placed in a centralized component.
So for example, in a module that is
specifically designed for access control functions,
you also want to make sure that
every request is checked against
the centralized access control function
before allowing any access to a resource.
Additionally, you could restrict special pages like
admin pages using an IP access whitelist.
For any critical actions like for example,
some critical admin action,
you want to re-authenticate
that user before performing that critical action.
In summary, we talked about what access control
is and how it's related to
session management and authentication.
We talked about the two kinds of
privilege attacks and we also mentioned
this idea of specifying explicitly
our access control security policy.
That's it for now. Thank you.