1 00:00:00,240 --> 00:00:01,260 In this lesson, 2 00:00:01,260 --> 00:00:03,390 we're going to discuss cross-site scripting 3 00:00:03,390 --> 00:00:05,700 and cross-site requests forgery attacks. 4 00:00:05,700 --> 00:00:07,950 Now, cross-site scripting is a malicious script 5 00:00:07,950 --> 00:00:09,810 that's hosted on an attacker site 6 00:00:09,810 --> 00:00:11,370 or coded inside of a link 7 00:00:11,370 --> 00:00:13,530 that's injected into a trusted site designed 8 00:00:13,530 --> 00:00:17,010 to compromise the client that is browsing that trusted site. 9 00:00:17,010 --> 00:00:18,960 Now, this allows the attacker to circumvent 10 00:00:18,960 --> 00:00:21,750 the browser's security model or trusted zones, 11 00:00:21,750 --> 00:00:24,120 and the attacker's goal in using cross-site scripting 12 00:00:24,120 --> 00:00:26,400 is to get you to run some kind of malicious script, 13 00:00:26,400 --> 00:00:28,470 so that your system will process this thing 14 00:00:28,470 --> 00:00:31,350 and bypass its normal security mechanisms. 15 00:00:31,350 --> 00:00:33,900 Cross-site scripting is a powerful exploit 16 00:00:33,900 --> 00:00:35,370 that relies on your website 17 00:00:35,370 --> 00:00:37,980 not conducting proper input validation. 18 00:00:37,980 --> 00:00:40,110 If you're not doing proper input validation, 19 00:00:40,110 --> 00:00:41,730 you are most likely going to fall victim 20 00:00:41,730 --> 00:00:43,710 to a cross-site scripting attack. 21 00:00:43,710 --> 00:00:46,560 So let's take a look at how cross-site scripting works 22 00:00:46,560 --> 00:00:49,050 in the real world by looking at the four basic steps 23 00:00:49,050 --> 00:00:51,090 of a cross-site scripting attack. 24 00:00:51,090 --> 00:00:52,830 First, the attacker identifies 25 00:00:52,830 --> 00:00:56,250 an input validation vulnerability within a trusted website. 26 00:00:56,250 --> 00:00:57,900 For example, if my website 27 00:00:57,900 --> 00:00:59,700 doesn't conduct proper input validation 28 00:00:59,700 --> 00:01:01,680 for the username and password fields used 29 00:01:01,680 --> 00:01:04,140 by my students, that could become a good candidate 30 00:01:04,140 --> 00:01:06,000 for cross-site scripting attacks. 31 00:01:06,000 --> 00:01:08,010 Second, the attacker crafts a URL 32 00:01:08,010 --> 00:01:11,070 to perform the code injection against that trusted website. 33 00:01:11,070 --> 00:01:13,170 At the same time, the attacker needs to get somebody 34 00:01:13,170 --> 00:01:15,540 to click on that maliciously encoded URL, 35 00:01:15,540 --> 00:01:17,910 so they might post it to a trusted website, 36 00:01:17,910 --> 00:01:20,640 embed it in an email message using a phishing campaign, 37 00:01:20,640 --> 00:01:22,680 or post it to an online forum. 38 00:01:22,680 --> 00:01:24,810 The goal here is that the attacker needs to get somebody 39 00:01:24,810 --> 00:01:27,000 to click on that encoded URL. 40 00:01:27,000 --> 00:01:29,370 Third, the trusted site will return a page, 41 00:01:29,370 --> 00:01:31,050 containing the malicious code injected, 42 00:01:31,050 --> 00:01:33,060 as well as the regular site code. 43 00:01:33,060 --> 00:01:35,790 This occurs once the user clicks the encoded URL 44 00:01:35,790 --> 00:01:38,550 and the trusted site executes the code that was injected. 45 00:01:38,550 --> 00:01:40,440 At this point, the user's going to be presented 46 00:01:40,440 --> 00:01:42,960 with malicious content which they believe is trusted 47 00:01:42,960 --> 00:01:44,550 because it came from the trusted website 48 00:01:44,550 --> 00:01:45,930 that they were visiting. 49 00:01:45,930 --> 00:01:48,060 Fourth, the malicious code is now run 50 00:01:48,060 --> 00:01:50,010 in the client's browser finalizing 51 00:01:50,010 --> 00:01:51,750 the cross-site scripting attack. 52 00:01:51,750 --> 00:01:54,120 When this occurs, the code will run the permission level 53 00:01:54,120 --> 00:01:56,490 of the trusted site because the system believes 54 00:01:56,490 --> 00:01:59,940 the trusted site sent that code which technically it did 55 00:01:59,940 --> 00:02:01,860 because it was injected into the reply coming 56 00:02:01,860 --> 00:02:04,890 from that trusted server to the end user's browser. 57 00:02:04,890 --> 00:02:07,530 This is why we call it a cross-site scripting attack 58 00:02:07,530 --> 00:02:09,720 because malicious code is actually going to be injected 59 00:02:09,720 --> 00:02:13,200 and served by the trusted site to their users. 60 00:02:13,200 --> 00:02:15,780 Now, for example, let's say, I was scrolling Facebook, 61 00:02:15,780 --> 00:02:16,980 and somebody was able to perform 62 00:02:16,980 --> 00:02:18,750 a cross-site scripting attack there, 63 00:02:18,750 --> 00:02:21,210 and they could inject code into my newsfeed. 64 00:02:21,210 --> 00:02:23,370 Now, it's going to cross that threat actor site 65 00:02:23,370 --> 00:02:25,110 into the trusted site, in this case, 66 00:02:25,110 --> 00:02:27,420 Facebook, and then it's delivered to me, 67 00:02:27,420 --> 00:02:29,610 the end user who's scrolling my newsfeed. 68 00:02:29,610 --> 00:02:32,310 That's how a cross-site scripting attack works. 69 00:02:32,310 --> 00:02:34,380 Now, cross-site scripting attacks can be used 70 00:02:34,380 --> 00:02:37,530 to run malicious code that perform many different functions. 71 00:02:37,530 --> 00:02:40,410 One attack may focus on defacing the trusted website 72 00:02:40,410 --> 00:02:42,900 by injecting extra HTML code into it. 73 00:02:42,900 --> 00:02:45,750 Another attack might focus on stealing the user's data 74 00:02:45,750 --> 00:02:47,940 by stealing protected cookies from that user. 75 00:02:47,940 --> 00:02:49,860 Another might try to intercept data 76 00:02:49,860 --> 00:02:51,480 or communications as they're being entered 77 00:02:51,480 --> 00:02:53,760 into the web forms, and yet another, 78 00:02:53,760 --> 00:02:56,610 might try to install malware on your client's system. 79 00:02:56,610 --> 00:02:58,260 As you can imagine, there are lots 80 00:02:58,260 --> 00:02:59,280 of different things we can can do 81 00:02:59,280 --> 00:03:00,780 with the malicious code being run, 82 00:03:00,780 --> 00:03:03,273 but cross-site scripting is the initial delivery mechanism 83 00:03:03,273 --> 00:03:04,800 that the threat actor is going to use 84 00:03:04,800 --> 00:03:06,810 to get that malicious code to your system 85 00:03:06,810 --> 00:03:08,910 and have it run by your web browser. 86 00:03:08,910 --> 00:03:11,250 Now, the reason cross-site scripting is so dangerous 87 00:03:11,250 --> 00:03:14,070 is because it breaks the browser's security and trust model 88 00:03:14,070 --> 00:03:15,780 because browsers are going to assume that scripts 89 00:03:15,780 --> 00:03:18,780 that receives from a trusted site should be safe to run. 90 00:03:18,780 --> 00:03:20,370 Now, this isn't the browser's fault, 91 00:03:20,370 --> 00:03:22,290 it's just because they're designed to run scripts 92 00:03:22,290 --> 00:03:24,090 they receive from trusted sites. 93 00:03:24,090 --> 00:03:25,980 That's how the internet is designed. 94 00:03:25,980 --> 00:03:27,720 After all, if you go to my website, 95 00:03:27,720 --> 00:03:29,400 there are lots of different scripts we're running 96 00:03:29,400 --> 00:03:31,440 in order to provide you with the training videos, 97 00:03:31,440 --> 00:03:33,840 quizzes, and practice exams that you want. 98 00:03:33,840 --> 00:03:36,390 Your browser knows that it can trust my website 99 00:03:36,390 --> 00:03:38,250 because there's a valid digital certificate, 100 00:03:38,250 --> 00:03:39,720 and you've logged into our site, 101 00:03:39,720 --> 00:03:41,400 and therefore, you're a trusted client, 102 00:03:41,400 --> 00:03:42,870 and we're a trusted site. 103 00:03:42,870 --> 00:03:44,280 Without this level of trust, 104 00:03:44,280 --> 00:03:46,260 webpages would be extremely boring 105 00:03:46,260 --> 00:03:49,170 because no scripts could ever be run or operated. 106 00:03:49,170 --> 00:03:50,700 So let's take a quick look 107 00:03:50,700 --> 00:03:52,620 at what cross-site scripting might look like 108 00:03:52,620 --> 00:03:55,020 if we used it against a vulnerable website. 109 00:03:55,020 --> 00:03:57,450 First, we're going to craft the URL by adding 110 00:03:57,450 --> 00:03:59,640 the script to an otherwise safe URL. 111 00:03:59,640 --> 00:04:02,010 For example, if my site was vulnerable, 112 00:04:02,010 --> 00:04:06,030 we could use a URL, like diontraining.com/search, 113 00:04:06,030 --> 00:04:07,860 question mark, q equals, 114 00:04:07,860 --> 00:04:10,260 and then you'll see something like bracket, 115 00:04:10,260 --> 00:04:13,170 script percent 20, type, equals, 116 00:04:13,170 --> 00:04:15,570 quote, application/javascript, 117 00:04:15,570 --> 00:04:18,750 end quote, bracket, alert, parentheses, 118 00:04:18,750 --> 00:04:22,980 xss, parentheses, bracket, slash script, bracket. 119 00:04:22,980 --> 00:04:24,720 Now, what does this really say? 120 00:04:24,720 --> 00:04:27,300 Well, the first part here is simply saying we're going to use 121 00:04:27,300 --> 00:04:30,300 a trusted website like diontraining.com. 122 00:04:30,300 --> 00:04:33,210 The next part that says, search, question mark q, equals, 123 00:04:33,210 --> 00:04:35,130 would normally be used for a website to conduct 124 00:04:35,130 --> 00:04:37,710 a search for anything found after the Q equals 125 00:04:37,710 --> 00:04:39,510 because that is my query. 126 00:04:39,510 --> 00:04:41,370 For example, maybe, you're on my site, 127 00:04:41,370 --> 00:04:43,110 and you're searching for the word CompTIA. 128 00:04:43,110 --> 00:04:46,320 So you would see in the URL, Q equals CompTIA, 129 00:04:46,320 --> 00:04:48,630 and that would send the word CompTIA to my server 130 00:04:48,630 --> 00:04:50,640 to be able to search its database for any pages 131 00:04:50,640 --> 00:04:52,710 that have the word CompTIA in it. 132 00:04:52,710 --> 00:04:53,880 Now, because we're attempting 133 00:04:53,880 --> 00:04:55,590 a cross-site scripting attack here, 134 00:04:55,590 --> 00:04:57,810 we're actually going to replace the query with the script 135 00:04:57,810 --> 00:04:59,190 that we want to insert. 136 00:04:59,190 --> 00:05:01,110 In this case, I have a really short piece 137 00:05:01,110 --> 00:05:03,600 of JavaScript code that's going to pop up an alert box 138 00:05:03,600 --> 00:05:07,320 that says XSS when it goes and reaches the server. 139 00:05:07,320 --> 00:05:08,760 Now, if you try to run this code, 140 00:05:08,760 --> 00:05:10,770 it probably won't work on my website 141 00:05:10,770 --> 00:05:12,990 because my site is already protected from this type 142 00:05:12,990 --> 00:05:14,640 of cross-site scripting attack. 143 00:05:14,640 --> 00:05:16,800 But if you want to attempt these on your own, 144 00:05:16,800 --> 00:05:18,990 you could check out the cross-site scripting game set up 145 00:05:18,990 --> 00:05:23,990 by google at xss-game.appspot.com, 146 00:05:24,000 --> 00:05:26,100 which has six different challenges where you try 147 00:05:26,100 --> 00:05:27,930 to create a cross-site scripting attack 148 00:05:27,930 --> 00:05:29,340 against their servers. 149 00:05:29,340 --> 00:05:30,930 The first one can be completed using 150 00:05:30,930 --> 00:05:33,360 the example I just covered in this lesson. 151 00:05:33,360 --> 00:05:34,710 Now, the example I just showed you 152 00:05:34,710 --> 00:05:36,120 is what's known as a reflected 153 00:05:36,120 --> 00:05:38,970 or non-persistent cross-site scripting attack. 154 00:05:38,970 --> 00:05:41,700 This type of attack only occurs when it's launched 155 00:05:41,700 --> 00:05:43,230 because you're clicking on that link, 156 00:05:43,230 --> 00:05:44,850 or you're entering it into your web browser 157 00:05:44,850 --> 00:05:46,260 and pressing enter. 158 00:05:46,260 --> 00:05:49,170 When it happens, it happens once and then it stops 159 00:05:49,170 --> 00:05:51,690 because it is considered non-persistent. 160 00:05:51,690 --> 00:05:52,590 Now, there are other types 161 00:05:52,590 --> 00:05:54,240 of cross-site scripting attacks though, 162 00:05:54,240 --> 00:05:56,010 and these can be more dangerous. 163 00:05:56,010 --> 00:05:59,130 For example, a persistent cross-site scripting attack allows 164 00:05:59,130 --> 00:06:01,740 an attacker to insert code into the backend database 165 00:06:01,740 --> 00:06:03,600 used by that trusted website. 166 00:06:03,600 --> 00:06:05,700 By doing this, the attacker doesn't have to wait 167 00:06:05,700 --> 00:06:07,620 for somebody to actually click on a link anymore 168 00:06:07,620 --> 00:06:09,240 because the malicious code is now embedded 169 00:06:09,240 --> 00:06:11,160 into that website's database. 170 00:06:11,160 --> 00:06:14,160 Anytime a user loads the page or content from the database, 171 00:06:14,160 --> 00:06:14,993 they're going to be loading 172 00:06:14,993 --> 00:06:17,280 the persistent cross-site script as well. 173 00:06:17,280 --> 00:06:18,390 Now, both persistent 174 00:06:18,390 --> 00:06:20,490 and non-persistent cross-site scripting attacks 175 00:06:20,490 --> 00:06:23,400 are considered forms of server-size scripting attacks 176 00:06:23,400 --> 00:06:25,200 because it's a server that is executing 177 00:06:25,200 --> 00:06:26,970 the scripts that we're injecting. 178 00:06:26,970 --> 00:06:28,830 Now, there's also a client-side attack 179 00:06:28,830 --> 00:06:31,440 known as a DOM cross-site scripting attack. 180 00:06:31,440 --> 00:06:34,920 Now, DOM, is the Document Object Model, 181 00:06:34,920 --> 00:06:37,440 and the document object model cross-site scripting attack 182 00:06:37,440 --> 00:06:39,510 is going to exploit the client's web browser 183 00:06:39,510 --> 00:06:42,000 using client-side scripts to modify the content 184 00:06:42,000 --> 00:06:43,830 and layout of the webpage. 185 00:06:43,830 --> 00:06:46,530 The document object model or DOM is how things 186 00:06:46,530 --> 00:06:48,420 are displayed in the client's browser, 187 00:06:48,420 --> 00:06:50,700 but by injecting scripts into the DOM, 188 00:06:50,700 --> 00:06:52,500 you can actually change this. 189 00:06:52,500 --> 00:06:54,000 Now, let me show you a quick example 190 00:06:54,000 --> 00:06:56,520 of a DOM-based, cross-site scripting attack. 191 00:06:56,520 --> 00:06:59,010 In this simple example, you can see a URL 192 00:06:59,010 --> 00:07:03,450 of diontraining.com/index.html hashtag, 193 00:07:03,450 --> 00:07:08,250 default, equals script, alert, document dot cookie, script. 194 00:07:08,250 --> 00:07:10,530 Now, at first glance, this looks a lot like 195 00:07:10,530 --> 00:07:12,570 the non-persistent, cross-site scripting attack 196 00:07:12,570 --> 00:07:13,740 that I showed you earlier, 197 00:07:13,740 --> 00:07:15,690 and both of these do have a short script 198 00:07:15,690 --> 00:07:18,570 and an alert being issued, but the big difference 199 00:07:18,570 --> 00:07:21,090 with this one is actually in the payload itself 200 00:07:21,090 --> 00:07:22,500 because we're using the alert to show 201 00:07:22,500 --> 00:07:24,930 the contents of document dot cookie. 202 00:07:24,930 --> 00:07:26,940 Now, when you see the word, document here, 203 00:07:26,940 --> 00:07:29,130 this is an indication that we're looking at the DOM 204 00:07:29,130 --> 00:07:32,730 or the document object model inside of the web browser. 205 00:07:32,730 --> 00:07:35,430 In this example, we're trying to access the cookie store 206 00:07:35,430 --> 00:07:37,320 inside of the web browser's DOM, 207 00:07:37,320 --> 00:07:40,050 and therefore, we're trying to execute this in the browser 208 00:07:40,050 --> 00:07:42,990 and display the contents of those client's cookies. 209 00:07:42,990 --> 00:07:45,120 If the web browser is vulnerable to this, 210 00:07:45,120 --> 00:07:48,030 you're going to then see code go, oh, I see this code. 211 00:07:48,030 --> 00:07:49,860 You're asking for document dot cookie. 212 00:07:49,860 --> 00:07:51,240 You want to see what my cookies are? 213 00:07:51,240 --> 00:07:52,410 Well, let me show you, 214 00:07:52,410 --> 00:07:53,610 and we'll display those cookies 215 00:07:53,610 --> 00:07:55,800 to the screen using this alert. 216 00:07:55,800 --> 00:07:57,510 This again, is a simple example, 217 00:07:57,510 --> 00:07:59,700 but there are many more dangerous ones out there 218 00:07:59,700 --> 00:08:02,070 that could be used like document dot write, 219 00:08:02,070 --> 00:08:04,770 document dot location, and other things that can access 220 00:08:04,770 --> 00:08:06,540 and change the DOM environment. 221 00:08:06,540 --> 00:08:08,040 Remember, when you're performing 222 00:08:08,040 --> 00:08:09,870 a DOM cross-site scripting attack, 223 00:08:09,870 --> 00:08:10,800 it's going to be run using 224 00:08:10,800 --> 00:08:13,560 the logged-in user permissions for that local system. 225 00:08:13,560 --> 00:08:15,690 So if you're lucky enough as an attacker 226 00:08:15,690 --> 00:08:17,610 to have a system administrator who executes 227 00:08:17,610 --> 00:08:20,370 your DOM cross-site scripting attack, guess what? 228 00:08:20,370 --> 00:08:21,870 You now have access to that system 229 00:08:21,870 --> 00:08:23,880 as a system administrator too. 230 00:08:23,880 --> 00:08:27,240 Now, for the exam, let me give you a couple of quick tips. 231 00:08:27,240 --> 00:08:29,820 First, anytime you're looking at a log snippet 232 00:08:29,820 --> 00:08:31,980 or captured URLs that have the script 233 00:08:31,980 --> 00:08:34,260 or any kind of JavaScript inside of them, 234 00:08:34,260 --> 00:08:37,230 it's most likely going to be a cross-site scripting attack 235 00:08:37,230 --> 00:08:39,299 that's going to be the right answer for that question. 236 00:08:39,299 --> 00:08:40,950 And second, if you see something 237 00:08:40,950 --> 00:08:42,690 with document dot something in it, 238 00:08:42,690 --> 00:08:45,600 like document dot cookie or document dot right, 239 00:08:45,600 --> 00:08:47,460 this should tell you it's a DOM-based, 240 00:08:47,460 --> 00:08:49,620 cross-site scripting attack because it's affecting 241 00:08:49,620 --> 00:08:52,170 the document object model of your browser. 242 00:08:52,170 --> 00:08:54,000 If you keep those two tips in mind, 243 00:08:54,000 --> 00:08:55,740 you'll do great on the exam. 244 00:08:55,740 --> 00:08:58,980 Now, we're going to discuss cross-site request forgery attacks. 245 00:08:58,980 --> 00:09:01,530 But before we do, we need to quickly cover 246 00:09:01,530 --> 00:09:03,450 the concept of session management 247 00:09:03,450 --> 00:09:04,590 because session management 248 00:09:04,590 --> 00:09:06,360 is a fundamental security component 249 00:09:06,360 --> 00:09:08,520 in our modern web applications. 250 00:09:08,520 --> 00:09:10,740 Session management enables web applications 251 00:09:10,740 --> 00:09:12,420 to uniquely identify a user 252 00:09:12,420 --> 00:09:14,070 across a number of different actions 253 00:09:14,070 --> 00:09:16,590 and requests while keeping the state of the data generated 254 00:09:16,590 --> 00:09:19,110 by that user and ensuring it remains assigned 255 00:09:19,110 --> 00:09:20,790 to that particular user. 256 00:09:20,790 --> 00:09:23,250 For example, right now, there are hundreds 257 00:09:23,250 --> 00:09:24,660 or thousands of people logged 258 00:09:24,660 --> 00:09:27,060 into my site at diontraining.com, 259 00:09:27,060 --> 00:09:28,770 all trying to take their courses. 260 00:09:28,770 --> 00:09:30,660 Now, they're all doing this at the same time, 261 00:09:30,660 --> 00:09:32,010 so we need to have a way to be able 262 00:09:32,010 --> 00:09:34,350 to track which users are doing which courses 263 00:09:34,350 --> 00:09:36,390 and which items in those courses. 264 00:09:36,390 --> 00:09:38,550 So when you log into my website, 265 00:09:38,550 --> 00:09:40,860 my website needs to keep track of your actions 266 00:09:40,860 --> 00:09:43,230 and know which lessons you're currently watching. 267 00:09:43,230 --> 00:09:45,270 It also needs to know which quizzes you've taken 268 00:09:45,270 --> 00:09:47,670 and all of your different actions throughout the course. 269 00:09:47,670 --> 00:09:49,620 And as you conduct those different actions, 270 00:09:49,620 --> 00:09:52,200 we need to store the results of that in our database. 271 00:09:52,200 --> 00:09:53,610 So when you log in next time, 272 00:09:53,610 --> 00:09:55,620 you can resume the course at the right place 273 00:09:55,620 --> 00:09:57,570 and not lose all your progress. 274 00:09:57,570 --> 00:09:59,610 Now, as a developer, we can do this 275 00:09:59,610 --> 00:10:02,640 by using our own server-side tracking using our databases, 276 00:10:02,640 --> 00:10:06,450 or we can rely on cookies located on your client device. 277 00:10:06,450 --> 00:10:08,250 Now, in the first web applications, 278 00:10:08,250 --> 00:10:10,740 cookies were heavily used for tracking user actions 279 00:10:10,740 --> 00:10:14,580 because HTTP is by default, a stateless protocol. 280 00:10:14,580 --> 00:10:16,740 This means that the web server doesn't preserve 281 00:10:16,740 --> 00:10:19,650 any information about the clients or their actions. 282 00:10:19,650 --> 00:10:21,480 So in the good old days, 283 00:10:21,480 --> 00:10:23,550 if you wanted to store information about your client, 284 00:10:23,550 --> 00:10:25,200 you would simply store it as a cookie 285 00:10:25,200 --> 00:10:26,940 on that user's computer. 286 00:10:26,940 --> 00:10:29,010 A cookie is essentially just a text file 287 00:10:29,010 --> 00:10:30,600 that's going to be used to store information 288 00:10:30,600 --> 00:10:33,240 about a user when they visit the website. 289 00:10:33,240 --> 00:10:34,590 That cookie is going to be created 290 00:10:34,590 --> 00:10:35,640 when the server first sends 291 00:10:35,640 --> 00:10:37,290 the HTTP response header 292 00:10:37,290 --> 00:10:39,150 with that cookie over to the client. 293 00:10:39,150 --> 00:10:41,670 Then any subsequent request headers that are sent 294 00:10:41,670 --> 00:10:44,010 by the client back to the server should include 295 00:10:44,010 --> 00:10:46,800 that cookie with the most updated information. 296 00:10:46,800 --> 00:10:49,680 Cookies can be either persistent or non-persistent. 297 00:10:49,680 --> 00:10:51,060 Now, a non-persistent cookie 298 00:10:51,060 --> 00:10:53,370 is also known as a session cookie. 299 00:10:53,370 --> 00:10:55,170 Session cookies reside in memory, 300 00:10:55,170 --> 00:10:57,540 and they're used for a very short period of time. 301 00:10:57,540 --> 00:10:59,400 When the browser is done with that session, 302 00:10:59,400 --> 00:11:01,800 that session cookie is going to be deleted, 303 00:11:01,800 --> 00:11:04,560 But some other cookies are more persistent, 304 00:11:04,560 --> 00:11:07,020 and those cookies will be stored in the browser cache, 305 00:11:07,020 --> 00:11:10,560 until they're either deleted by a user or they expire. 306 00:11:10,560 --> 00:11:12,990 For example, if my website uses cookies 307 00:11:12,990 --> 00:11:14,670 to track your movements and they're set 308 00:11:14,670 --> 00:11:16,380 to expire after seven days, 309 00:11:16,380 --> 00:11:18,780 those would be considered persistent cookies. 310 00:11:18,780 --> 00:11:20,310 If you finished your work today, 311 00:11:20,310 --> 00:11:21,780 but you came back in three days, 312 00:11:21,780 --> 00:11:23,460 the cookie remembers where you were, 313 00:11:23,460 --> 00:11:25,200 and it brings that progress back. 314 00:11:25,200 --> 00:11:27,510 On the other hand, if you left for two weeks, 315 00:11:27,510 --> 00:11:29,490 when you come back, the system might think you're 316 00:11:29,490 --> 00:11:32,040 a brand new user because your cookies already expired 317 00:11:32,040 --> 00:11:34,140 after you were gone for seven days. 318 00:11:34,140 --> 00:11:35,370 When dealing with cookies, 319 00:11:35,370 --> 00:11:37,680 those cookies need to be encrypted and secured 320 00:11:37,680 --> 00:11:39,510 because they could contain sensitive information 321 00:11:39,510 --> 00:11:40,560 in them as well. 322 00:11:40,560 --> 00:11:42,600 All right. Now, that we have a little background 323 00:11:42,600 --> 00:11:44,100 on session management and cookies, 324 00:11:44,100 --> 00:11:46,380 we can move into session hijacking. 325 00:11:46,380 --> 00:11:49,140 Now, session hijacking is a type of spoofing attack 326 00:11:49,140 --> 00:11:50,940 where the attacker disconnects a host 327 00:11:50,940 --> 00:11:52,140 and then replaces it with his 328 00:11:52,140 --> 00:11:55,110 or her own machine by spoofing the original host IP 329 00:11:55,110 --> 00:11:57,180 or using some other takeover mechanism. 330 00:11:57,180 --> 00:12:00,000 For example, a lot of session hijacking occurs 331 00:12:00,000 --> 00:12:02,130 by taking cookie theft or modification 332 00:12:02,130 --> 00:12:03,333 of those session cookies. 333 00:12:03,333 --> 00:12:06,240 Now, if the attacker is able to steal the session cookie, 334 00:12:06,240 --> 00:12:07,620 they can take over the session 335 00:12:07,620 --> 00:12:09,750 as the already authenticating user. 336 00:12:09,750 --> 00:12:12,090 Now, another form of session hijacking focuses 337 00:12:12,090 --> 00:12:15,000 on session management that's conducted using a database, 338 00:12:15,000 --> 00:12:16,770 and this database will assign 339 00:12:16,770 --> 00:12:19,320 a randomized session token to each user. 340 00:12:19,320 --> 00:12:22,350 If the randomized scheme is not truly random in nature, 341 00:12:22,350 --> 00:12:24,570 it'll create tokens that can easily be guessed 342 00:12:24,570 --> 00:12:27,690 by an attacker, and this means they can predict your session 343 00:12:27,690 --> 00:12:29,940 and take over the already authenticated session 344 00:12:29,940 --> 00:12:32,310 by guessing your randomized token. 345 00:12:32,310 --> 00:12:34,080 Session prediction attacks are simply 346 00:12:34,080 --> 00:12:36,300 a type of spoofing attack where the attacker attempts 347 00:12:36,300 --> 00:12:37,860 to predict the session token 348 00:12:37,860 --> 00:12:39,870 in order to hijack your session. 349 00:12:39,870 --> 00:12:41,760 To prevent session prediction attacks, 350 00:12:41,760 --> 00:12:43,860 the session tokens need to be generated using 351 00:12:43,860 --> 00:12:45,420 a non-predictable algorithm, 352 00:12:45,420 --> 00:12:47,280 and they need to be truly randomized. 353 00:12:47,280 --> 00:12:49,170 That way, the session tokens won't 354 00:12:49,170 --> 00:12:50,640 be able to be easily guessed. 355 00:12:50,640 --> 00:12:54,060 Also, those session tokens should not reveal any information 356 00:12:54,060 --> 00:12:55,620 about the session's client, 357 00:12:55,620 --> 00:12:58,950 instead session tokens should be a one-time use ticket 358 00:12:58,950 --> 00:13:01,350 for the duration of a given session. 359 00:13:01,350 --> 00:13:03,570 All right, now that we've established some background 360 00:13:03,570 --> 00:13:05,880 and session management and session hijacking, 361 00:13:05,880 --> 00:13:07,260 we can move into our discussion 362 00:13:07,260 --> 00:13:11,490 of cross-site request forgery attacks, also known as XSRF. 363 00:13:11,490 --> 00:13:13,620 Now, a cross-site request forgery attack 364 00:13:13,620 --> 00:13:15,510 is a malicious script that's going to be hosted 365 00:13:15,510 --> 00:13:17,280 on an attacker's site that can be used 366 00:13:17,280 --> 00:13:19,500 to exploit a session started on another site 367 00:13:19,500 --> 00:13:21,270 within the same web browser. 368 00:13:21,270 --> 00:13:23,790 For this to work, the attacker needs to convince the victim 369 00:13:23,790 --> 00:13:26,100 to start a session with the targeted website. 370 00:13:26,100 --> 00:13:28,320 Once that occurs, the attacker can then pass 371 00:13:28,320 --> 00:13:31,110 an HTTP request to the victim's browser 372 00:13:31,110 --> 00:13:33,930 and spoof this as an action on the target site. 373 00:13:33,930 --> 00:13:36,540 For example, if you're logged into your account already, 374 00:13:36,540 --> 00:13:37,560 the attacker might attempt 375 00:13:37,560 --> 00:13:40,410 to use a cross-site request forgery to change your password 376 00:13:40,410 --> 00:13:42,720 or your email address for that account. 377 00:13:42,720 --> 00:13:45,000 Cross-site request forgeries can be disguised 378 00:13:45,000 --> 00:13:46,920 in a lot of different ways as well. 379 00:13:46,920 --> 00:13:49,200 For example, cross-site request forgeries 380 00:13:49,200 --> 00:13:51,030 can use things like image, tags, 381 00:13:51,030 --> 00:13:54,150 and other HTML coding techniques to hide themselves. 382 00:13:54,150 --> 00:13:56,700 The scariest thing about a cross-site request forgery 383 00:13:56,700 --> 00:13:57,780 is that they can be accomplished 384 00:13:57,780 --> 00:13:59,130 without the victim necessarily 385 00:13:59,130 --> 00:14:01,050 even having to click on a link in order 386 00:14:01,050 --> 00:14:02,910 for that victim to be exploited. 387 00:14:02,910 --> 00:14:04,920 For a cross-site request forgery to work, 388 00:14:04,920 --> 00:14:07,110 the website must have a feature that could lead 389 00:14:07,110 --> 00:14:08,640 to unauthorized access, 390 00:14:08,640 --> 00:14:11,370 something like a forgot-my-password reset feature. 391 00:14:11,370 --> 00:14:14,610 And the site must rely on cookies for authenticating users 392 00:14:14,610 --> 00:14:16,950 and use predictable patterns for session management 393 00:14:16,950 --> 00:14:18,480 that can be guessed. 394 00:14:18,480 --> 00:14:20,850 So let's take a look at a real-world example 395 00:14:20,850 --> 00:14:22,530 of how this might play out. 396 00:14:22,530 --> 00:14:25,140 First, let's assume the browser's already authenticated 397 00:14:25,140 --> 00:14:26,190 to the target site. 398 00:14:26,190 --> 00:14:28,320 In this case, the victim's bank. 399 00:14:28,320 --> 00:14:30,420 That cross-site request forgery will then try 400 00:14:30,420 --> 00:14:33,600 to steal the valid session token from that victim's browser. 401 00:14:33,600 --> 00:14:35,310 For this example, let's assume there are 402 00:14:35,310 --> 00:14:37,050 two tabs open in the web browser. 403 00:14:37,050 --> 00:14:38,580 One is the attacker's website 404 00:14:38,580 --> 00:14:40,140 and the other one is your bank. 405 00:14:40,140 --> 00:14:41,880 Now, you've already authenticated to your bank, 406 00:14:41,880 --> 00:14:44,400 but now, you've also connected to the attacker's website 407 00:14:44,400 --> 00:14:46,830 inside this new tab because you clicked on a link 408 00:14:46,830 --> 00:14:50,040 in a phishing campaign or another social engineering scheme. 409 00:14:50,040 --> 00:14:51,360 Now, the attacker can use 410 00:14:51,360 --> 00:14:53,220 a cross-site request forgery attack 411 00:14:53,220 --> 00:14:55,500 to try to manipulate the session with your bank 412 00:14:55,500 --> 00:14:58,290 because your browser is already authenticated to that site, 413 00:14:58,290 --> 00:14:59,430 and they can attempt to take over 414 00:14:59,430 --> 00:15:01,710 that session inside the other tab. 415 00:15:01,710 --> 00:15:04,530 So, how can you prevent cross-site request forgery 416 00:15:04,530 --> 00:15:05,790 as a defender? 417 00:15:05,790 --> 00:15:07,830 Well, let's say, you're working for the bank, 418 00:15:07,830 --> 00:15:09,660 and you want to make sure that nobody's going to perform 419 00:15:09,660 --> 00:15:11,010 this against your customers. 420 00:15:11,010 --> 00:15:13,830 What can you do? Well, first, you can ensure 421 00:15:13,830 --> 00:15:16,920 that user-specific tokens are used in all form submissions 422 00:15:16,920 --> 00:15:19,260 to prevent cross-site request forgeries. 423 00:15:19,260 --> 00:15:21,540 This is an action that your web developers would take 424 00:15:21,540 --> 00:15:24,360 as part of their secure coding and best practices. 425 00:15:24,360 --> 00:15:26,280 Second, you can add randomness 426 00:15:26,280 --> 00:15:27,900 and prompt for additional information 427 00:15:27,900 --> 00:15:29,880 whenever a user tries to reset their password. 428 00:15:29,880 --> 00:15:33,030 Or you can require two-factor authentication. 429 00:15:33,030 --> 00:15:34,590 Third, you can require the user 430 00:15:34,590 --> 00:15:35,940 to enter their current password 431 00:15:35,940 --> 00:15:38,190 whenever they're trying to change their password. 432 00:15:38,190 --> 00:15:39,090 This would actually stop 433 00:15:39,090 --> 00:15:41,250 a lot of cross-site requests forgery attacks 434 00:15:41,250 --> 00:15:43,470 because they usually try to change a user's password 435 00:15:43,470 --> 00:15:45,030 without the user knowing it in order 436 00:15:45,030 --> 00:15:47,160 for the attacker to take over that account. 437 00:15:47,160 --> 00:15:49,770 Now for the exam, remember, that if somebody is trying 438 00:15:49,770 --> 00:15:51,660 to get a victim to unintentionally carry out 439 00:15:51,660 --> 00:15:54,120 an action on a website, this is normally going to be 440 00:15:54,120 --> 00:15:56,550 a form of cross-site request forgery. 441 00:15:56,550 --> 00:15:58,470 This most often occurs by trying to get 442 00:15:58,470 --> 00:16:00,690 the victim to do some kind of unknown update 443 00:16:00,690 --> 00:16:02,010 to their default email address 444 00:16:02,010 --> 00:16:03,990 or by changing that user's password, 445 00:16:03,990 --> 00:16:05,763 so keep that in mind for the exam.