According to the 2017 OS update,

the number five vulnerability is broken access control.

Broken access control refers to the lack of proper protections applied to

the actions users can take.

This could mean that the developer forget to ensure that normal users can't control

admin functionality, or that when a user does something specific,

they can read documents, or information of other users without permission.

Broken access controls can be further broken down into two major categories for

most web apps, indirect or direct object references, and

missing function level access controls.

A direct object reference occurs when a developer exposes a reference

to a resource that's supposed to only be accessible via the internal application,

like files, directories, data and storage, keys, URLs, or form parameters.

When references to direct objects are exposed in the interface of

an application, attackers can also exploit these.

Without proper access controls in place,

they do not need any further authorization to directly access exposed objects.

A classic example of direct object references is when a banking application

uses a customer's account number as the primary key.

If an attacker realizes this it may possible

to use other users accounts if the attacker has users account number and

uses that in forms, escrow inquiries, or other functionality.

This exact attack occurred with AT&T in the early 2000s when each user's

personal information can be accessed by changing an ID parameter in the URL.

This led to further discovering that AT&T simply incremented the ID number for

the next registered user, which allowed an attacker to try ID numbers in order.

Upon discovery, a now famous hacker,

exposed the information of every user account in the AT&T website.

In practice, these types of flaws occur when application uses the actual name, or

a key of an object, when creating or

rendering webpages without verifying if the user's authorized for the resource.

A skilled attacker can exploit these flaws by changing the parameter values.

Furthermore, if the developer does not make object references unpredictable,

unlike the case of AT&T, it's easy to access all data of that specific type.

Insecure direct object references occur very often in production, and

of course, also in your application.

In our application, the userid parameter is passed in the URL from the client,

which lets the server know for what user to retrieve allocations, and

to display them.

When we go to the allocations page, we see our allocations for

various investment types for our current user.

In this case, we're user one with the name John Doe.

However, if we go to the URL and increment the ID,

then now we see an allocation for a different user.

Preventing insecure direct object references can usually be accomplished

by checking access controls and ensuring resources are protected.

This is done by using per user, or per session IDs for references, rather

than exposing the underlying database keys, which was essentially done here.

Furthermore, via testing and code analysis, we can usually infer

whether a parameter can be manipulated to provide access to restricted resources.

In our application, the allocations are retrieved by the allocations.js file.

On line 10 the application takes the user ID from the URL to

retrieve the allocations for the given user.

Instead of storing the user ID in the URL parameters, we can instead store it in

each session, which is not visible directly to attackers when utilizing XSS

since session access can be blocked with the cookie settings mentioned earlier.

Furthermore, by using a random session ID, and storing it in the session,

only the server knows which IDs correspond to which sessions, because random IDs

cannot be easily guessed by an attacker, and then used to take over a user account.

Finally, all checks to ensure the correct user's data is being fetched must

be done at least on the server and not just the client, which prevents users from

only having to tamper with the client's site checks to take over the application.

Insecure direct object references lead to web vulnerabilities

beyond simply accessing resources via IDs.

An example of another, well-known vulnerability is path reversal

where the attacker enters relative path information as part of the user input.

These attacks try to access files that are not directly accessible by anyone or

by anyone that would be denied under direct access.

These attacks usually occur in URLs or in any input that eventually accesses a file

like code execution via the eval function or shell commands.

Other notable attacks are the access of files with insecure file permissions,

which can happen often in content management systems like WordPress or

Drupal, as well as the exploitation of client side caching in apps.

When an application does not expire cache information, computers and

machines accessible in public places, like schools, libraries, airports, and

general information terminals, can expose sensitive user information like logins

to an attacker who stumbles upon the computer.

To prevent client side caching attacks developers should use hp headers,

meta tags, and settings on the users session to purge caches

of sensitive user information after log out or a certain amount of time.

Preventing file permission attacks is even easier, since the developer just needs to

set the permissions correctly within the web interface or

underlying server file system.

While indirect object references occur when references to

internal resources are insecure and not checked when accessed, function level or

feature access control is often important.

Often, developers will only verify the user's access rights before displaying

the functionality, but these checks also need to be performed on the server.

By checking on both the server and the client before rending the functionality

attackers can't forge request or bypass the check to access restrictive features.

Now that we've seen how function level access control flaws our current theory,

let's snap back to reality.

In our application, there's a function level access vulnerability in the benefits

functionality.

In this case, the application exposes the benefits functionality

without checking to see if the current user is an admin.

This lets us change the benefits start date for

employees by going to the benefits URL directly and setting whatever we want.

This is not good since users in the app should not be

able to change their start date or else they could get benefits for

any time period they want, even if they must wait to qualify.

To address this issue,

we must ensure that the functionality is restricted on the server.

In Express, and many other frameworks,

we can restrict the HTTP methods that are accessible to certain users and

user types when creating the individual URL routes.

In the routes folder and index.js file, we see that there is no

authorization check for benefits URL on the get and posts methods.

First, let's add the variable isadmin after isloggedin, which will be used to

check whether the current user who's checking the benefits URL is an admin.

Now, we need to actually make sure these parameters do something.

If we look in the application session file, in session.js under the routes

folder, we already have made aware that checks at the isAdmin flag is set for

the currently logged in user.

Then back in the routes folder and index.js file, we can make this middleware

available by adding a middleware to the session handler of the Express app.

Broken access controls can cause major issues with web applications,

from the ability to steal user information,

to completely reconfiguring the functionality of an application.

In practice vulnerabilities, such as insecure references, path traversal, and

unrestrictive functionality are some of the most common and

often significantly impactful vulnerabilities.

In no-js and JavaScript, libraries and middleware exist beyond what we have

discussed to help combat and test for these vulnerabilities.

Some of these tools will be linked in the teacher's notes.