This course will be retired on June 1, 2025.
Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. By implementing proper access controls, users will only have access to what they should be able to use and nothing more.
Further Reading:
Node.js Access Control Libraries
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
According to the 2017 OWASP update,
0:00
the number five vulnerability
is broken access control.
0:02
Broken access control refers to the lack
of proper protections applied to
0:06
the actions users can take.
0:09
This could mean that the developer forget
to ensure that normal users can't control
0:12
admin functionality, or
that when a user does something specific,
0:16
they can read documents, or information
of other users without permission.
0:19
Broken access controls can be further
broken down into two major categories for
0:24
most web apps, indirect or
direct object references, and
0:28
missing function level access controls.
0:31
A direct object reference occurs
when a developer exposes a reference
0:34
to a resource that's supposed to only be
accessible via the internal application,
0:38
like files, directories, data and
storage, keys, URLs, or form parameters.
0:43
When references to direct objects
are exposed in the interface of
0:49
an application,
attackers can also exploit these.
0:52
Without proper access controls in place,
0:56
they do not need any further authorization
to directly access exposed objects.
0:58
A classic example of direct object
references is when a banking application
1:03
uses a customer's account
number as the primary key.
1:07
If an attacker realizes
this it may possible
1:10
to use other users accounts if
the attacker has users account number and
1:13
uses that in forms, escrow inquiries,
or other functionality.
1:16
This exact attack occurred with AT&T
in the early 2000s when each user's
1:20
personal information can be accessed
by changing an ID parameter in the URL.
1:24
This led to further discovering that AT&T
simply incremented the ID number for
1:29
the next registered user, which allowed
an attacker to try ID numbers in order.
1:33
Upon discovery, a now famous hacker,
1:38
exposed the information of every
user account in the AT&T website.
1:40
In practice, these types of flaws occur
when application uses the actual name, or
1:44
a key of an object, when creating or
1:49
rendering webpages without verifying if
the user's authorized for the resource.
1:51
A skilled attacker can exploit these
flaws by changing the parameter values.
1:56
Furthermore, if the developer does not
make object references unpredictable,
2:00
unlike the case of AT&T, it's easy to
access all data of that specific type.
2:04
Insecure direct object references
occur very often in production, and
2:10
of course, also in your application.
2:13
In our application, the userid parameter
is passed in the URL from the client,
2:17
which lets the server know for
what user to retrieve allocations, and
2:21
to display them.
2:24
When we go to the allocations page,
we see our allocations for
2:26
various investment types for
our current user.
2:29
In this case,
we're user one with the name John Doe.
2:32
However, if we go to the URL and
increment the ID,
2:35
then now we see an allocation for
a different user.
2:38
Preventing insecure direct object
references can usually be accomplished
2:46
by checking access controls and
ensuring resources are protected.
2:50
This is done by using per user, or
per session IDs for references, rather
2:54
than exposing the underlying database
keys, which was essentially done here.
2:58
Furthermore, via testing and
code analysis, we can usually infer
3:03
whether a parameter can be manipulated to
provide access to restricted resources.
3:07
In our application, the allocations
are retrieved by the allocations.js file.
3:11
On line 10 the application takes
the user ID from the URL to
3:17
retrieve the allocations for
the given user.
3:21
Instead of storing the user ID in the URL
parameters, we can instead store it in
3:24
each session, which is not visible
directly to attackers when utilizing XSS
3:28
since session access can be blocked with
the cookie settings mentioned earlier.
3:33
Furthermore, by using a random session ID,
and storing it in the session,
3:37
only the server knows which IDs correspond
to which sessions, because random IDs
3:42
cannot be easily guessed by an attacker,
and then used to take over a user account.
3:46
Finally, all checks to ensure the correct
user's data is being fetched must
3:50
be done at least on the server and not
just the client, which prevents users from
3:55
only having to tamper with the client's
site checks to take over the application.
3:59
Insecure direct object references
lead to web vulnerabilities
4:04
beyond simply accessing resources via IDs.
4:07
An example of another,
well-known vulnerability is path reversal
4:10
where the attacker enters relative path
information as part of the user input.
4:14
These attacks try to access files that
are not directly accessible by anyone or
4:18
by anyone that would be
denied under direct access.
4:23
These attacks usually occur in URLs or in
any input that eventually accesses a file
4:26
like code execution via the eval
function or shell commands.
4:31
Other notable attacks are the access of
files with insecure file permissions,
4:35
which can happen often in content
management systems like WordPress or
4:39
Drupal, as well as the exploitation
of client side caching in apps.
4:43
When an application does not expire
cache information, computers and
4:47
machines accessible in public places,
like schools, libraries, airports, and
4:51
general information terminals, can expose
sensitive user information like logins
4:56
to an attacker who stumbles
upon the computer.
5:01
To prevent client side caching attacks
developers should use hp headers,
5:04
meta tags, and settings on
the users session to purge caches
5:08
of sensitive user information after
log out or a certain amount of time.
5:12
Preventing file permission attacks is even
easier, since the developer just needs to
5:17
set the permissions correctly
within the web interface or
5:21
underlying server file system.
5:24
While indirect object references
occur when references to
5:26
internal resources are insecure and not
checked when accessed, function level or
5:29
feature access control is often important.
5:34
Often, developers will only verify
the user's access rights before displaying
5:36
the functionality, but these checks
also need to be performed on the server.
5:40
By checking on both the server and the
client before rending the functionality
5:45
attackers can't forge request or bypass
the check to access restrictive features.
5:49
Now that we've seen how function level
access control flaws our current theory,
5:54
let's snap back to reality.
5:57
In our application, there's a function
level access vulnerability in the benefits
6:00
functionality.
6:04
In this case, the application
exposes the benefits functionality
6:05
without checking to see if
the current user is an admin.
6:09
This lets us change
the benefits start date for
6:12
employees by going to the benefits URL
directly and setting whatever we want.
6:15
This is not good since users
in the app should not be
6:19
able to change their start date or
else they could get benefits for
6:22
any time period they want,
even if they must wait to qualify.
6:25
To address this issue,
6:28
we must ensure that the functionality
is restricted on the server.
6:29
In Express, and many other frameworks,
6:33
we can restrict the HTTP methods that
are accessible to certain users and
6:35
user types when creating
the individual URL routes.
6:39
In the routes folder and
index.js file, we see that there is no
6:42
authorization check for
benefits URL on the get and posts methods.
6:46
First, let's add the variable isadmin
after isloggedin, which will be used to
6:52
check whether the current user who's
checking the benefits URL is an admin.
6:56
Now, we need to actually make sure
these parameters do something.
7:00
If we look in the application session
file, in session.js under the routes
7:04
folder, we already have made aware that
checks at the isAdmin flag is set for
7:09
the currently logged in user.
7:13
Then back in the routes folder and
index.js file, we can make this middleware
7:14
available by adding a middleware to
the session handler of the Express app.
7:19
Broken access controls can cause
major issues with web applications,
7:31
from the ability to
steal user information,
7:35
to completely reconfiguring
the functionality of an application.
7:37
In practice vulnerabilities, such as
insecure references, path traversal, and
7:41
unrestrictive functionality
are some of the most common and
7:46
often significantly
impactful vulnerabilities.
7:49
In no-js and JavaScript, libraries and
middleware exist beyond what we have
7:53
discussed to help combat and
test for these vulnerabilities.
7:57
Some of these tools will be
linked in the teacher's notes.
8:00
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up