Broken Access Controls

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