1 00:00:01,300 --> 00:00:04,156 ‫So, everything that we did in this section so far 2 00:00:04,156 --> 00:00:06,514 ‫was to secure all application 3 00:00:06,514 --> 00:00:10,320 ‫and our users' data as good as possible. 4 00:00:10,320 --> 00:00:12,290 ‫And I talked about a lot of things 5 00:00:12,290 --> 00:00:14,170 ‫we can do to achieve that. 6 00:00:14,170 --> 00:00:16,430 ‫But all of this information was kind of 7 00:00:16,430 --> 00:00:18,860 ‫spread out all over these lectures. 8 00:00:18,860 --> 00:00:21,311 ‫So I decided to create this quick summary 9 00:00:21,311 --> 00:00:24,717 ‫with many best practices that we already implemented 10 00:00:24,717 --> 00:00:26,960 ‫and that we're still gonna implement 11 00:00:26,960 --> 00:00:28,860 ‫in the rest of this section. 12 00:00:28,860 --> 00:00:32,100 ‫Because security is so extremely important, 13 00:00:32,100 --> 00:00:36,010 ‫but unfortunately, many courses don't address it enough. 14 00:00:36,010 --> 00:00:37,490 ‫Now, I'm also not turning this 15 00:00:37,490 --> 00:00:40,660 ‫Node.js course into a security course. 16 00:00:40,660 --> 00:00:44,170 ‫There are better courses and experts for that. 17 00:00:44,170 --> 00:00:46,490 ‫But I will show you a couple of things that 18 00:00:46,490 --> 00:00:51,490 ‫you can do to properly secure your applications and data. 19 00:00:51,650 --> 00:00:54,200 ‫And I'm gonna look at a couple of common attacks 20 00:00:54,200 --> 00:00:57,010 ‫and give some suggestions to prevent them. 21 00:00:57,010 --> 00:01:00,780 ‫And first up, we have the event of a compromised database, 22 00:01:00,780 --> 00:01:04,980 ‫meaning that an attacker gained access to our database. 23 00:01:04,980 --> 00:01:07,970 ‫Of course, this is an extremely severe problem, 24 00:01:07,970 --> 00:01:10,430 ‫but to prevent even bigger problems, 25 00:01:10,430 --> 00:01:14,550 ‫we must always encrypt passwords and password reset tokens 26 00:01:14,550 --> 00:01:17,660 ‫just like we did in the videos in this section. 27 00:01:17,660 --> 00:01:19,800 ‫This way, the attacker can't at least 28 00:01:19,800 --> 00:01:24,320 ‫steal our users' passwords and also can't reset them. 29 00:01:24,320 --> 00:01:26,720 ‫Now, about actually preventing attacks, 30 00:01:26,720 --> 00:01:29,110 ‫let's talk about the brute force attack 31 00:01:29,110 --> 00:01:32,290 ‫where the attacker basically tries to guess a password 32 00:01:32,290 --> 00:01:35,660 ‫by trying millions and millions of random passwords 33 00:01:35,660 --> 00:01:37,850 ‫until they find the right one. 34 00:01:37,850 --> 00:01:42,160 ‫And what we can do is to make the login request really slow. 35 00:01:42,160 --> 00:01:44,586 ‫And the bcrypt package that we're using 36 00:01:44,586 --> 00:01:47,020 ‫actually does just that. 37 00:01:47,020 --> 00:01:50,180 ‫Another strategy is to implement rate limiting, 38 00:01:50,180 --> 00:01:52,340 ‫which limits the number of requests 39 00:01:52,340 --> 00:01:54,640 ‫coming from one single IP. 40 00:01:54,640 --> 00:01:56,330 ‫And this one we're gonna implement 41 00:01:56,330 --> 00:01:58,460 ‫in one of the next videos. 42 00:01:58,460 --> 00:02:01,690 ‫Also, a nice strategy is to actually implement 43 00:02:01,690 --> 00:02:05,470 ‫a maximum number of login attempts for each user. 44 00:02:05,470 --> 00:02:07,660 ‫For example, we could make it so that 45 00:02:07,660 --> 00:02:10,540 ‫after 10 failed attempts, user would have to 46 00:02:10,540 --> 00:02:14,020 ‫wait one hour until he can try again. 47 00:02:14,020 --> 00:02:16,360 ‫Now, I'm not going to implement this functionality 48 00:02:16,360 --> 00:02:18,760 ‫in this section, but please feel free 49 00:02:18,760 --> 00:02:21,340 ‫to experiment with it on your own. 50 00:02:21,340 --> 00:02:24,350 ‫It's probably a really cool learning experience 51 00:02:24,350 --> 00:02:26,120 ‫to code this up by yourself, 52 00:02:26,120 --> 00:02:27,890 ‫and it's actually not that hard. 53 00:02:27,890 --> 00:02:29,210 ‫All right. 54 00:02:29,210 --> 00:02:32,580 ‫Next up, there is the cross-site scripting attack, 55 00:02:32,580 --> 00:02:34,020 ‫where the attacker tries to 56 00:02:34,020 --> 00:02:38,430 ‫inject scripts into our page to run his malicious code. 57 00:02:38,430 --> 00:02:41,280 ‫On the clients' side, this is especially dangerous 58 00:02:41,280 --> 00:02:44,810 ‫because it allows the attacker to read the local storage, 59 00:02:44,810 --> 00:02:46,500 ‫which is the reason why we should 60 00:02:46,500 --> 00:02:50,360 ‫never ever store the JSON web token in local storage. 61 00:02:50,360 --> 00:02:54,110 ‫Instead, it should be stored in an HTTP-only cookie 62 00:02:54,110 --> 00:02:55,950 ‫that makes it so that the browser can 63 00:02:55,950 --> 00:02:58,110 ‫only receive and send the cookie 64 00:02:58,110 --> 00:03:01,400 ‫but cannot access or modify it in any way. 65 00:03:01,400 --> 00:03:04,360 ‫And so, that then makes it impossible for any attacker 66 00:03:04,360 --> 00:03:08,460 ‫to steal the JSON web token that is stored in the cookie. 67 00:03:08,460 --> 00:03:11,590 ‫Again, we're implementing this in a second. 68 00:03:11,590 --> 00:03:15,780 ‫Now, on the backend side, in order to prevent XSS attacks, 69 00:03:15,780 --> 00:03:18,170 ‫we should sanitize user input data 70 00:03:18,170 --> 00:03:20,660 ‫and set some special HTTP headers 71 00:03:20,660 --> 00:03:24,470 ‫which make these attacks a bit more difficult to happen. 72 00:03:24,470 --> 00:03:27,040 ‫And Express doesn't come with these best practices 73 00:03:27,040 --> 00:03:29,560 ‫out of the box, so we're gonna use middleware 74 00:03:29,560 --> 00:03:31,713 ‫to set all of these special headers. 75 00:03:32,710 --> 00:03:35,620 ‫Next, we have denial-of-service attacks. 76 00:03:35,620 --> 00:03:37,510 ‫And maybe you have heard of these. 77 00:03:37,510 --> 00:03:39,330 ‫It happens when the attacker sends 78 00:03:39,330 --> 00:03:42,600 ‫so many requests to a server that it breaks down 79 00:03:42,600 --> 00:03:45,450 ‫and the application becomes unavailable. 80 00:03:45,450 --> 00:03:47,470 ‫Again, implementing rate limiting 81 00:03:47,470 --> 00:03:49,530 ‫is a good solution for this. 82 00:03:49,530 --> 00:03:51,970 ‫Also, we should limit the amount of data 83 00:03:51,970 --> 00:03:55,810 ‫that can be sent in a body in a post or a patch request. 84 00:03:55,810 --> 00:03:57,950 ‫And also, we should avoid using 85 00:03:57,950 --> 00:04:01,110 ‫so-called evil regular expressions to be in our code. 86 00:04:01,110 --> 00:04:03,590 ‫And these are just regular expressions that take 87 00:04:03,590 --> 00:04:07,550 ‫an exponential time to run for non-matching inputs and 88 00:04:07,550 --> 00:04:11,680 ‫they can be exploited to bring our entire application down. 89 00:04:11,680 --> 00:04:15,960 ‫Okay, next up, we have the NoSQL query injection attack. 90 00:04:15,960 --> 00:04:18,510 ‫And query injection happens when an attacker, 91 00:04:18,510 --> 00:04:22,240 ‫instead of inputting valid data, injects some query 92 00:04:22,240 --> 00:04:24,330 ‫in order to create query expressions 93 00:04:24,330 --> 00:04:26,600 ‫that are gonna translate to true. 94 00:04:26,600 --> 00:04:28,920 ‫For example, to be logged in even without 95 00:04:28,920 --> 00:04:32,120 ‫providing a valid username or password. 96 00:04:32,120 --> 00:04:33,380 ‫It's a bit complex 97 00:04:33,380 --> 00:04:36,330 ‫and you should definitely Google it to learn more. 98 00:04:36,330 --> 00:04:38,940 ‫But what you need to know is that using Mongoose 99 00:04:38,940 --> 00:04:40,810 ‫is actually a pretty good strategy 100 00:04:40,810 --> 00:04:43,300 ‫for preventing these kind of attacks 101 00:04:43,300 --> 00:04:46,110 ‫because a good schema forces each value 102 00:04:46,110 --> 00:04:48,410 ‫to have a well-defined data tab. 103 00:04:48,410 --> 00:04:50,190 ‫Which then effectively makes 104 00:04:50,190 --> 00:04:53,640 ‫this type of attack very difficult to execute. 105 00:04:53,640 --> 00:04:56,000 ‫However, it's always a good idea 106 00:04:56,000 --> 00:04:59,280 ‫to still sanitize input data, just to be sure. 107 00:04:59,280 --> 00:05:02,300 ‫And we will take care of that a bit later. 108 00:05:02,300 --> 00:05:04,360 ‫All right, and now to finish, 109 00:05:04,360 --> 00:05:07,822 ‫I just have a couple of best practices and suggestions 110 00:05:07,822 --> 00:05:10,150 ‫on how to improve the authentication 111 00:05:10,150 --> 00:05:14,009 ‫and authorization mechanisms that we implemented. 112 00:05:14,009 --> 00:05:16,350 ‫So, the first thing I need to repeat 113 00:05:16,350 --> 00:05:18,760 ‫over and over and over again 114 00:05:18,760 --> 00:05:21,370 ‫is that in a production application, 115 00:05:21,370 --> 00:05:24,310 ‫all communication between server and client 116 00:05:24,310 --> 00:05:26,980 ‫needs to happen over HTTPS. 117 00:05:26,980 --> 00:05:30,010 ‫Otherwise, anyone can listen into the conversation 118 00:05:30,010 --> 00:05:32,520 ‫and steal our JSON web token. 119 00:05:32,520 --> 00:05:35,540 ‫Next, always create random password tokens. 120 00:05:35,540 --> 00:05:38,660 ‫Not generated from dates or something like that. 121 00:05:38,660 --> 00:05:40,920 ‫Because they are effectively passwords 122 00:05:40,920 --> 00:05:43,470 ‫and so, they should be treated as such. 123 00:05:43,470 --> 00:05:45,860 ‫Plus, always give them expiry dates, 124 00:05:45,860 --> 00:05:47,750 ‫just like we implemented it. 125 00:05:47,750 --> 00:05:48,910 ‫All right? 126 00:05:48,910 --> 00:05:52,340 ‫And we also implemented that a certain JSON web token 127 00:05:52,340 --> 00:05:56,480 ‫is no longer valid after the user has changed his password. 128 00:05:56,480 --> 00:05:58,660 ‫So, we basically revoke the token 129 00:05:58,660 --> 00:06:01,410 ‫as soon as the user changes the password. 130 00:06:01,410 --> 00:06:04,070 ‫Which makes a lot of sense, but again, 131 00:06:04,070 --> 00:06:07,650 ‫many tutorials out there simply do not do that. 132 00:06:07,650 --> 00:06:10,470 ‫Another big thing is to never ever commit 133 00:06:10,470 --> 00:06:14,060 ‫a configuration file, like for environment variables, 134 00:06:14,060 --> 00:06:16,460 ‫to a version control like Git. 135 00:06:16,460 --> 00:06:19,020 ‫In fact, do not upload it anywhere 136 00:06:19,020 --> 00:06:20,500 ‫because this file contains 137 00:06:20,500 --> 00:06:23,780 ‫the most sensitive data of the entire application. 138 00:06:23,780 --> 00:06:26,340 ‫For example, if someone gets access to 139 00:06:26,340 --> 00:06:28,260 ‫your JSON web token secret, 140 00:06:28,260 --> 00:06:32,083 ‫then your entire authentication process is compromised. 141 00:06:32,083 --> 00:06:35,950 ‫Okay, and now just a small detail is to 142 00:06:35,950 --> 00:06:37,560 ‫whenever there is an error, 143 00:06:37,560 --> 00:06:40,560 ‫do not send the entire error to the client. 144 00:06:40,560 --> 00:06:44,010 ‫So, stuff like the stack trace could give the attacker 145 00:06:44,010 --> 00:06:46,920 ‫some valuable insights into your system, 146 00:06:46,920 --> 00:06:49,650 ‫and so, of course, we don't want that. 147 00:06:49,650 --> 00:06:52,480 ‫Next up, we can use the csurf package 148 00:06:52,480 --> 00:06:57,200 ‫to fight a type of attack called Cross-Site Request Forgery, 149 00:06:57,200 --> 00:06:59,750 ‫which is an attack that forces a user 150 00:06:59,750 --> 00:07:03,530 ‫to execute unwanted actions on a web application 151 00:07:03,530 --> 00:07:05,330 ‫in which they are currently logged in. 152 00:07:05,330 --> 00:07:07,600 ‫We're not gonna do that in this section, though. 153 00:07:07,600 --> 00:07:10,140 ‫But I still wanted to mention it here. 154 00:07:10,140 --> 00:07:12,280 ‫Next, we could require the user to 155 00:07:12,280 --> 00:07:16,180 ‫re-authenticate before performing a high-value action. 156 00:07:16,180 --> 00:07:19,730 ‫For example, making a payment or deleting something. 157 00:07:19,730 --> 00:07:22,070 ‫Again, this is just a suggestion 158 00:07:22,070 --> 00:07:23,810 ‫that you can try out for yourself. 159 00:07:23,810 --> 00:07:26,630 ‫Another cool feature that you can implement 160 00:07:26,630 --> 00:07:29,460 ‫is a blacklist of untrusted tokens. 161 00:07:29,460 --> 00:07:31,660 ‫So, we already know that there is not really 162 00:07:31,660 --> 00:07:34,910 ‫a way to log users out of the application 163 00:07:34,910 --> 00:07:37,220 ‫if they show some malicious activity. 164 00:07:37,220 --> 00:07:41,260 ‫But what we can do is to create a list of untrusted tokens 165 00:07:41,260 --> 00:07:44,370 ‫that are then validated on each request. 166 00:07:44,370 --> 00:07:47,920 ‫And next up, a feature that we could have implemented is to 167 00:07:47,920 --> 00:07:51,810 ‫confirm the email address after an account is first created. 168 00:07:51,810 --> 00:07:54,665 ‫So, basically by sending a link to the user's email, 169 00:07:54,665 --> 00:07:57,520 ‫like many real apps actually do. 170 00:07:57,520 --> 00:08:00,190 ‫But I wanted to just keep things simple here, 171 00:08:00,190 --> 00:08:02,600 ‫which is why I didn't do this here. 172 00:08:02,600 --> 00:08:05,400 ‫But please feel free to just implement this yourself 173 00:08:05,400 --> 00:08:07,360 ‫if you feel like it. 174 00:08:07,360 --> 00:08:09,900 ‫Now, a big feature that many apps have 175 00:08:09,900 --> 00:08:12,580 ‫is the concept of refresh tokens. 176 00:08:12,580 --> 00:08:15,050 ‫Which are basically to remember users. 177 00:08:15,050 --> 00:08:17,150 ‫So, to keep them logged in forever 178 00:08:17,150 --> 00:08:19,720 ‫or until they choose to log out. 179 00:08:19,720 --> 00:08:22,170 ‫Our current implementation makes it so that 180 00:08:22,170 --> 00:08:25,020 ‫the user has to basically log in again 181 00:08:25,020 --> 00:08:27,480 ‫after the JSON web token expires. 182 00:08:27,480 --> 00:08:30,720 ‫But, with refresh tokens, that's no longer necessary. 183 00:08:30,720 --> 00:08:33,490 ‫And it's a bit complex to implement and so, 184 00:08:33,490 --> 00:08:35,343 ‫it's a feature for another time. 185 00:08:36,270 --> 00:08:37,950 ‫And finally, the last one 186 00:08:37,950 --> 00:08:41,530 ‫that we could have implemented is two-factor authentication, 187 00:08:41,530 --> 00:08:43,770 ‫which I'm sure you're familiar with. 188 00:08:43,770 --> 00:08:46,079 ‫Basically, with two-factor authentication, 189 00:08:46,079 --> 00:08:48,750 ‫after logging into the application, 190 00:08:48,750 --> 00:08:50,050 ‫the user needs to perform 191 00:08:50,050 --> 00:08:53,110 ‫a second action to really get authenticated. 192 00:08:53,110 --> 00:08:55,750 ‫And typically, that is to insert a code 193 00:08:55,750 --> 00:08:58,980 ‫sent via text message to a mobile phone. 194 00:08:58,980 --> 00:09:01,420 ‫So, these are a lot of functionalities 195 00:09:01,420 --> 00:09:03,580 ‫our authentication could have. 196 00:09:03,580 --> 00:09:05,730 ‫And if you want me to implement any of them, 197 00:09:05,730 --> 00:09:08,160 ‫please let me know so in the Q&A section. 198 00:09:08,160 --> 00:09:10,640 ‫And, if there is a lot of demand for one of them, 199 00:09:10,640 --> 00:09:12,740 ‫then I will show you how it works. 200 00:09:12,740 --> 00:09:15,210 ‫Okay, but again, I didn't want to 201 00:09:15,210 --> 00:09:17,270 ‫turn this Node.js course into 202 00:09:17,270 --> 00:09:20,760 ‫a whole security and authentication course. 203 00:09:20,760 --> 00:09:24,230 ‫And just to finish, something that we will implement 204 00:09:24,230 --> 00:09:26,200 ‫in the rest of the section is 205 00:09:26,200 --> 00:09:28,320 ‫to prevent parameter pollution. 206 00:09:28,320 --> 00:09:32,450 ‫For example, try to just insert two field parameters 207 00:09:32,450 --> 00:09:36,030 ‫into the query string that searches for all tours. 208 00:09:36,030 --> 00:09:38,290 ‫And if you do that, you will find that 209 00:09:38,290 --> 00:09:39,770 ‫there will be an error because 210 00:09:39,770 --> 00:09:42,150 ‫our application is not prepared for that. 211 00:09:42,150 --> 00:09:45,790 ‫And so, attackers try to use these kinds of weaknesses 212 00:09:45,790 --> 00:09:49,330 ‫to crash applications, which is, of course, not good. 213 00:09:49,330 --> 00:09:51,530 ‫And so, we need to fix that. 214 00:09:51,530 --> 00:09:56,286 ‫Okay, so this turned out to be a lot longer than I expected. 215 00:09:56,286 --> 00:09:59,231 ‫And there are entire courses about security 216 00:09:59,231 --> 00:10:01,560 ‫if you're really into security. 217 00:10:01,560 --> 00:10:04,074 ‫All right, but I am leaving it at this, 218 00:10:04,074 --> 00:10:07,283 ‫and so, let's now move on right to the next one.