1 00:00:00,000 --> 00:00:05,076 [MUSIC] 2 00:00:05,076 --> 00:00:09,320 Welcome back, over the next few videos we'll be looking into how developers fail 3 00:00:09,320 --> 00:00:13,610 to protect the basic gateways to their application and its users. 4 00:00:13,610 --> 00:00:14,980 From authentication methods, 5 00:00:14,980 --> 00:00:19,510 to user authorization, developers tend to mess up in this area far too often. 6 00:00:19,510 --> 00:00:22,410 It's our goal in this stage to explore ways to prevent these slots 7 00:00:22,410 --> 00:00:23,600 from happening. 8 00:00:23,600 --> 00:00:27,500 First we're going to look at the number two vulnerability on the OS top ten. 9 00:00:27,500 --> 00:00:30,140 Broken authentication and session management. 10 00:00:30,140 --> 00:00:34,450 Sessions and web apps are used to manage the information that identifies a user. 11 00:00:34,450 --> 00:00:37,950 They are usually created when a user logs into the web application, 12 00:00:37,950 --> 00:00:40,620 whether on the web or on mobile. 13 00:00:40,620 --> 00:00:42,670 Sessions make user's lives easy. 14 00:00:42,670 --> 00:00:44,900 They don't require users that are logged in or 15 00:00:44,900 --> 00:00:47,640 recently logged in to enter passwords on every new click. 16 00:00:48,720 --> 00:00:53,400 Before a session is created, when the user logs in they typically pass through some 17 00:00:53,400 --> 00:00:57,160 kind of authentication mechanism, which is often handled by a username password 18 00:00:57,160 --> 00:01:02,750 combination, a third party like Facebook or Google, or two factor authentication. 19 00:01:02,750 --> 00:01:06,720 After a user is successfully authenticated, a session is created with 20 00:01:06,720 --> 00:01:10,900 information that identifies that user for the current use of the application. 21 00:01:10,900 --> 00:01:15,140 Usually via tokens or codes stored within the applications cookies. 22 00:01:15,140 --> 00:01:19,580 With this knowledge an attacker can use flies in the session authentication or 23 00:01:19,580 --> 00:01:23,350 session management functions to impersonate other users. 24 00:01:23,350 --> 00:01:27,540 These attackers can be an external attacker, a normal user with an account 25 00:01:27,540 --> 00:01:31,330 that is attempting to steal data from other users, or someone on the inside of 26 00:01:31,330 --> 00:01:34,520 the company or group that wants to disguise their actions. 27 00:01:34,520 --> 00:01:38,610 The functions used in session management are often not implemented correctly. 28 00:01:38,610 --> 00:01:42,500 Which can allow attackers to see your passwords, secret keys, and 29 00:01:42,500 --> 00:01:44,830 tokens used to authenticate sessions. 30 00:01:44,830 --> 00:01:48,680 By compromising this data, attackers can take over users and accounts 31 00:01:48,680 --> 00:01:52,610 which can lead to severe consequences about the user and for the developer. 32 00:01:53,880 --> 00:01:55,640 When building session workloads, 33 00:01:55,640 --> 00:01:58,990 developers need to implement many pieces of functionality. 34 00:01:58,990 --> 00:02:02,430 By building custom authentication and session management methods, 35 00:02:02,430 --> 00:02:06,320 developers often leave flaws in a variety of functions. 36 00:02:06,320 --> 00:02:10,119 Finding flaws in these functions can be difficult since implementations 37 00:02:10,119 --> 00:02:11,107 are often unique. 38 00:02:11,107 --> 00:02:13,835 Though session management is a very diverse topic, 39 00:02:13,835 --> 00:02:17,499 there are three common flaws here which every developer should know. 40 00:02:17,499 --> 00:02:21,430 First, application timeouts were often set improperly. 41 00:02:21,430 --> 00:02:23,580 If an application token is compromised or 42 00:02:23,580 --> 00:02:26,980 leaked, properly set timeouts prevent an attacker 43 00:02:26,980 --> 00:02:31,930 from using a token to impersonate the user if the token was generated too long ago. 44 00:02:31,930 --> 00:02:36,040 However, tokens are often left valid for days or even weeks. 45 00:02:36,040 --> 00:02:39,530 Second, attackers can acquire a user's session ID or 46 00:02:39,530 --> 00:02:43,020 token from network traffic by getting in between a user and 47 00:02:43,020 --> 00:02:45,630 the application on an unsecured network connection. 48 00:02:45,630 --> 00:02:49,700 If the session ID is in the URL or unencrypted in the request body, 49 00:02:49,700 --> 00:02:53,680 then the attacker can capture it from network traffic and use it as they wish. 50 00:02:53,680 --> 00:02:55,650 Third, an internal attacker or 51 00:02:55,650 --> 00:03:00,400 a remote attacker can gain access to the user database via a variety of methods. 52 00:03:00,400 --> 00:03:02,100 If passwords are not hashed, 53 00:03:02,100 --> 00:03:05,780 then these passwords can be directly used to log in as the user. 54 00:03:05,780 --> 00:03:07,060 Good news for us, though. 55 00:03:07,060 --> 00:03:11,350 Preventing session management issues is easily prevented in most cases. 56 00:03:11,350 --> 00:03:15,530 First, user authentication credentials should always be hashed when stored and 57 00:03:15,530 --> 00:03:17,570 sent over encrypted connection. 58 00:03:17,570 --> 00:03:20,610 Session tokens should never be exposed in the URL, 59 00:03:20,610 --> 00:03:23,670 since this is sent in the clear in most cases. 60 00:03:23,670 --> 00:03:28,480 Session tokens should also timeout after a short time, and be invalidated at logout. 61 00:03:28,480 --> 00:03:31,790 THis prevents attackers from stealing a session token and using it over and 62 00:03:31,790 --> 00:03:34,460 over again to access a user's account. 63 00:03:34,460 --> 00:03:36,880 In addition to invalidating tokens at logout, 64 00:03:36,880 --> 00:03:39,740 they should always be recreated on logins. 65 00:03:39,740 --> 00:03:41,810 Finally, these credentials should always, 66 00:03:41,810 --> 00:03:46,960 always, always be sent over HEPS, with no exceptions. 67 00:03:46,960 --> 00:03:48,450 By following these simple rules, 68 00:03:48,450 --> 00:03:51,780 the majority of session management flaws can be prevented. 69 00:03:51,780 --> 00:03:56,580 Remember, using well known authentication methods such as OAuth 2.0 can 70 00:03:56,580 --> 00:03:58,670 prevent many of these issues. 71 00:03:58,670 --> 00:04:02,210 These topics are covered as well in several other Treehouse courses. 72 00:04:02,210 --> 00:04:05,700 In particular, the introduction to application security course. 73 00:04:06,730 --> 00:04:09,980 To really explore how session management issues arise in an app, 74 00:04:09,980 --> 00:04:12,470 let's look back in our app from the first stage. 75 00:04:12,470 --> 00:04:16,410 In our application, user passwords are start without hashing them first, 76 00:04:16,410 --> 00:04:23,370 which we can see by looking at the user model in userdao.js. 77 00:04:23,370 --> 00:04:27,890 To fix this issue, we can use the bcrypt algorithm, the currently most trusted 78 00:04:27,890 --> 00:04:32,170 password hashing algorithm, with implementations in nearly every language. 79 00:04:32,170 --> 00:04:35,920 With bcrypt, we first generate a salt for the password. 80 00:04:35,920 --> 00:04:39,260 A salt essentially adds more difficulty to breaking the password. 81 00:04:39,260 --> 00:04:41,480 In practice, a salt is a random, 82 00:04:41,480 --> 00:04:45,548 unique, per-user complex string added to every password before hashing. 83 00:04:45,548 --> 00:04:48,720 By doing this, developers can prevent attackers from calculating 84 00:04:48,720 --> 00:04:52,490 the corresponding hashes for common passwords ahead of time. 85 00:04:52,490 --> 00:04:55,390 Where those common passwords can come from data breaches that other users 86 00:04:55,390 --> 00:04:59,890 can be exposed in or they could come from common password combinations in lists. 87 00:04:59,890 --> 00:05:04,110 These precomputed passwords make up something called a rainbow table, and 88 00:05:04,110 --> 00:05:07,000 using a salt with a strong algorithm such as B-grip. 89 00:05:07,000 --> 00:05:09,920 We can prevent our hash passwords from being translated 90 00:05:09,920 --> 00:05:12,610 back to the actual password in nearly all cases, 91 00:05:12,610 --> 00:05:15,980 even if the attacker has the fastest modern super computer. 92 00:05:15,980 --> 00:05:20,870 With the salt calculated pick up library, we hash the user's password with the salt. 93 00:05:32,336 --> 00:05:35,228 By hashing the password and storing the password hash, 94 00:05:35,228 --> 00:05:39,412 when a user attempts to login with a plain text non-hashed password, we can then 95 00:05:39,412 --> 00:05:44,200 proceed to hash the entered password and check it against the stored hash password. 96 00:05:44,200 --> 00:05:47,070 If this two match, we know the user can be authenticated and 97 00:05:47,070 --> 00:05:48,250 proceed to the application. 98 00:05:54,441 --> 00:05:58,940 Another issue with our application is the no time out is forced in the user session. 99 00:05:58,940 --> 00:06:03,490 Which means the session will say active until the user explicitly logs out, 100 00:06:03,490 --> 00:06:05,620 even if the browser window is closed. 101 00:06:05,620 --> 00:06:06,570 Even worse, 102 00:06:06,570 --> 00:06:10,290 the application does not prevent cookies from being accessed via JavaScript, 103 00:06:10,290 --> 00:06:14,790 which leaves the site vulnerable to XSS attacks as we discussed in the last stage. 104 00:06:14,790 --> 00:06:19,410 Not only are cookies able to be accessed via JavaScript, queries also be sent over 105 00:06:19,410 --> 00:06:22,830 unsecured connects, meaning the sessions lack encryption. 106 00:06:22,830 --> 00:06:27,124 When the session lack encryption, the attacker can steal the session ID if they 107 00:06:27,124 --> 00:06:31,610 able to intercept user's traffic, which can be easily done if you and the attacker 108 00:06:31,610 --> 00:06:35,608 are sitting together in a coffee shop on a public unsecured WiFi connect. 109 00:06:35,608 --> 00:06:39,881 In order to address these issues we need to close the session when the browser 110 00:06:39,881 --> 00:06:41,829 closes and when the user logs out. 111 00:06:41,829 --> 00:06:46,037 And we also need to add headers to the HTTP request to ensure that cookies can be 112 00:06:46,037 --> 00:06:47,545 accessed via JavaScript. 113 00:06:47,545 --> 00:06:52,380 And the cookies can't be sent over non-secure, or non-HTTPS connections. 114 00:06:52,380 --> 00:06:55,644 In a video later in the stage, we will make the application speak over HTTPS. 115 00:06:55,644 --> 00:06:59,400 But for now, let's deal with the cookie issues. 116 00:06:59,400 --> 00:07:00,500 Within our application, 117 00:07:00,500 --> 00:07:03,620 we need to make sure that the max age setting is on cookies. 118 00:07:03,620 --> 00:07:07,700 Which means express with these session cookies will be invalidated on browser 119 00:07:07,700 --> 00:07:08,827 close analogue out. 120 00:07:08,827 --> 00:07:11,330 Now, let's add this in the main server file. 121 00:07:13,367 --> 00:07:16,990 First we will set the maximum age to one day. 122 00:07:16,990 --> 00:07:20,869 Then we will ensure the cookies are invalidated when the browser closes. 123 00:07:33,759 --> 00:07:36,710 In other languages, this same kind of thing can be done, so 124 00:07:36,710 --> 00:07:40,320 refer to the documentation for your particular web framework. 125 00:07:40,320 --> 00:07:43,930 Next, you must ensure that cookies are only sent over https and 126 00:07:43,930 --> 00:07:45,850 not accessible via Java Script. 127 00:07:45,850 --> 00:07:48,820 To do this, we can set the http only and 128 00:07:48,820 --> 00:07:52,100 secure http headers in the main server file as well. 129 00:07:59,090 --> 00:08:03,580 We could also use JavaScript libraries to set specific http headers 130 00:08:03,580 --> 00:08:04,980 to add more security. 131 00:08:04,980 --> 00:08:07,002 The best known library for this is Helmet, 132 00:08:07,002 --> 00:08:10,159 which we'll discuss in the video on security misconfiguration. 133 00:08:10,159 --> 00:08:14,060 Regardless of language, these features are available nearly anywhere, so look for 134 00:08:14,060 --> 00:08:17,910 them when you implement authentication in your applications. 135 00:08:17,910 --> 00:08:21,360 Before we move on to broken access controls in the next video, 136 00:08:21,360 --> 00:08:25,840 let's wrap up session management by discussing password handling issues. 137 00:08:25,840 --> 00:08:29,720 When developers don't require strong passwords, attackers can more easily 138 00:08:29,720 --> 00:08:33,700 guess passwords and break into user accounts via brute force methods. 139 00:08:33,700 --> 00:08:36,680 Unfortunately for developers, there are many security tools for 140 00:08:36,680 --> 00:08:39,570 guessing passwords as efficient as possible and 141 00:08:39,570 --> 00:08:43,340 with the ability to try many common password combinations. 142 00:08:43,340 --> 00:08:45,170 To prevent password brute-force attacks, 143 00:08:45,170 --> 00:08:48,560 developers must ensure passwords are long and complex., 144 00:08:48,560 --> 00:08:53,040 preferably more than eight characters, and requiring both letters and numbers. 145 00:08:53,040 --> 00:08:56,340 And if possible, special characters like punctuation. 146 00:08:56,340 --> 00:09:00,410 Another flaw in apps occurs when apps divulge more information than necessary 147 00:09:00,410 --> 00:09:02,590 on an unsuccessful log in attempt. 148 00:09:02,590 --> 00:09:05,580 Authentication responses should never indicate which part of the data 149 00:09:05,580 --> 00:09:06,890 was incorrect. 150 00:09:06,890 --> 00:09:11,000 For example, instead of saying invalid username or invalid password, 151 00:09:11,000 --> 00:09:14,890 simply use invalid username and or password or just log in error. 152 00:09:15,950 --> 00:09:17,540 Even though this may be frustrating for 153 00:09:17,540 --> 00:09:20,510 innocent users, this simple fix prevents attackers from 154 00:09:20,510 --> 00:09:24,290 easily knowing whether their brute force attempts are working effectively. 155 00:09:24,290 --> 00:09:27,160 Beyond simply requiring complex passwords, 156 00:09:27,160 --> 00:09:30,900 developers can disable accounts after too many failed login attempts. 157 00:09:30,900 --> 00:09:34,050 This prevents attackers from trying to log in too many times, 158 00:09:34,050 --> 00:09:37,010 while allowing normal users who simply forget their password 159 00:09:37,010 --> 00:09:40,000 to just have to wait some time before logging back in again. 160 00:09:40,000 --> 00:09:44,060 As we've discussed, session management flaws can arise in many, many ways. 161 00:09:44,060 --> 00:09:45,690 Most of these flaws can be prevented. 162 00:09:45,690 --> 00:09:49,770 In the next video we'll look beyond authentication towards how a developer 163 00:09:49,770 --> 00:09:52,780 can apply permission to users for preventing security flaws