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.