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

Sign up for Treehouse

Broken Access Controls

8:03 with Jared Smith

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.

According to the 2017 OS 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 up