WEBVTT 1 00:00:00.040 --> 00:00:02.839 All right, let's dive into something pretty cool today, something 2 00:00:03.120 --> 00:00:05.240 a little cloak and dagger. We're going to be looking 3 00:00:05.280 --> 00:00:07.040 at web application hacking. 4 00:00:07.240 --> 00:00:08.080 Oh fun. 5 00:00:08.400 --> 00:00:10.400 Yeah, you know the kind of stuff gug bounty hunters 6 00:00:10.519 --> 00:00:14.160 use to uncover those nasty vulnerabilities. Right, we're working with 7 00:00:14.199 --> 00:00:17.640 some excerpts from a cybersecurity book kind of like our 8 00:00:17.679 --> 00:00:18.640 little secret weapon. 9 00:00:19.000 --> 00:00:19.839 I like it. 10 00:00:19.839 --> 00:00:24.760 It goes deep into advanced techniques and our mission today. Yeah. 11 00:00:25.000 --> 00:00:29.600 Imagine you right now are tasked with securing a web application. 12 00:00:30.320 --> 00:00:33.280 What are those sneaky, unexpected attacks that keep you up 13 00:00:33.320 --> 00:00:36.439 at night? Well, today's your crash course. 14 00:00:36.920 --> 00:00:39.240 I like that. And what's great about this book is 15 00:00:39.280 --> 00:00:43.079 it doesn't just list out vulnerability. It actually gets inside 16 00:00:43.119 --> 00:00:46.520 the hacker's head. It shows how they chain together exploits, 17 00:00:46.520 --> 00:00:49.200 how they turn even harmless features into weapons. 18 00:00:49.280 --> 00:00:51.320 It really does. And right off the bat it jumps 19 00:00:51.359 --> 00:00:56.200 into de serialization attacks. I'll admit the term itself sounds 20 00:00:56.240 --> 00:00:58.320 kind of techy. Did you break it down for us, like, 21 00:00:58.359 --> 00:00:59.159 what's going on there? 22 00:00:59.240 --> 00:01:02.119 Sure? Sure? Imagine packing a suitcase, right, Ok, you get 23 00:01:02.159 --> 00:01:04.200 your clothes, toiletries all neat and tidy. 24 00:01:04.480 --> 00:01:07.920 Yeah, that's like serialization in the coding world. Taking data, 25 00:01:08.239 --> 00:01:11.519 all those structures within an application and packing up for travel, 26 00:01:11.640 --> 00:01:12.959 for storage or transmission. 27 00:01:13.120 --> 00:01:16.079 Okay, making it compact, easy to move around exactly Now. 28 00:01:16.159 --> 00:01:20.879 De serialization, that's unpacking the suitcase at your destination, getting 29 00:01:20.920 --> 00:01:23.400 that data back to its original usable form. 30 00:01:23.560 --> 00:01:27.319 Got it. So, where's the danger. It's just unpacking data. 31 00:01:27.480 --> 00:01:30.840 Uh, that's where things get tricky. The danger comes in 32 00:01:30.879 --> 00:01:34.560 when a hacker messes with that suitcase before you unpack it. Oh, 33 00:01:34.719 --> 00:01:37.640 if they can tamper with the serialized data, slip in 34 00:01:37.719 --> 00:01:41.959 some malicious kind sneaky. Well, when the application unpacks it, boom, 35 00:01:42.000 --> 00:01:45.400 that code executes. It's like hiding something dangerous in your luggage, 36 00:01:45.400 --> 00:01:47.560 waiting for it to wreak havoc when you open it. 37 00:01:47.640 --> 00:01:50.400 So, in a web app, how do I stop someone 38 00:01:50.480 --> 00:01:53.760 from sneaking that dangerous something into my data? 39 00:01:53.879 --> 00:01:57.640 Never ever de serialized data from untrusted sources without some 40 00:01:57.799 --> 00:02:01.640 serious checks. It's like inspecting your suitcase for anything suspicious 41 00:02:01.680 --> 00:02:03.480 before you open it up completely. 42 00:02:03.159 --> 00:02:06.400 Right, make sure there's no weird ticking sounds. Exactly now. 43 00:02:06.400 --> 00:02:10.360 The book mentions PHP object injection and Python peockle serialization 44 00:02:10.479 --> 00:02:11.479 as common targets. 45 00:02:11.639 --> 00:02:12.360 I've heard of those. 46 00:02:12.439 --> 00:02:17.639 Yeah, these mechanisms. If they're not carefully implemented well, hackers 47 00:02:17.680 --> 00:02:22.960 can inject malicious objects, exploiting how those languages rebuild the data. 48 00:02:22.599 --> 00:02:25.560 So they're like twisting the instructions for how to unpack. 49 00:02:25.680 --> 00:02:29.080 You got it. Now, you've probably heard the term PIOP chains. 50 00:02:29.199 --> 00:02:30.759 Oh yeah, that one sounds kind of scary. 51 00:02:31.000 --> 00:02:34.280 It can be property oriented programming chains. It's like the 52 00:02:34.319 --> 00:02:35.919 hacker setting up a domino effect. 53 00:02:36.000 --> 00:02:36.599 Oh okay. 54 00:02:36.680 --> 00:02:39.479 Each domino is a little piece of code, harmless on 55 00:02:39.520 --> 00:02:41.960 its own right, but trigger them in the right order. 56 00:02:42.319 --> 00:02:45.080 Those harmless pieces can lead to taking over the server, 57 00:02:45.240 --> 00:02:47.280 stealing data, all sorts of nasty stuff. 58 00:02:47.360 --> 00:02:50.639 Yikes. So, as someone trying to keep an application safe, 59 00:02:51.159 --> 00:02:55.120 what are the best defenses against these de serialization attacks? 60 00:02:55.280 --> 00:02:59.280 You got to have a multi layered approach. First, sanitize, sanitize, 61 00:02:59.360 --> 00:03:03.400 sanitize user input before even thinking about de serializing. 62 00:03:02.840 --> 00:03:05.039 It, right like scrub it clean exactly. 63 00:03:05.479 --> 00:03:09.680 Second, use secure serialization libraries. One's less prone to these attacks. 64 00:03:09.719 --> 00:03:14.199 And of course, keep everything updated patching those known vulnerabilities. 65 00:03:14.400 --> 00:03:16.879 So it's not just writing secure code, it's a whole strategy. 66 00:03:16.960 --> 00:03:20.280 You got it. And speaking of sneaky attacks, let's switch 67 00:03:20.319 --> 00:03:23.080 gears a bit. Type juggling attacks heard of those? 68 00:03:23.280 --> 00:03:26.199 I have, Yeah, But to be honest, I'm a bit 69 00:03:26.199 --> 00:03:28.680 fuzzy on the details. Are they really as bad as 70 00:03:28.719 --> 00:03:29.520 some make them sound? 71 00:03:29.560 --> 00:03:31.280 Oh? They can be, They can be. It might not 72 00:03:31.400 --> 00:03:34.599 sound as dramatic as say, taking over a whole server, right, 73 00:03:34.719 --> 00:03:39.639 but type juggling exploits how some languages, especially PHP, compare 74 00:03:39.719 --> 00:03:43.039 different kinds of data. Like PHP might say the number 75 00:03:43.199 --> 00:03:45.840 zero and the string zero are basically the same if 76 00:03:45.879 --> 00:03:46.639 you're not careful. 77 00:03:46.759 --> 00:03:48.159 Uh oh, I see where this is going. 78 00:03:48.240 --> 00:03:50.759 Let's say you've got a log in form username, admin, 79 00:03:50.919 --> 00:03:53.319 password password classic. 80 00:03:52.919 --> 00:03:54.879 Right, yeah, not very secure though, huh huh. 81 00:03:54.960 --> 00:03:58.560 Right, But the point is a hacker with type juggling 82 00:03:58.599 --> 00:04:00.840 in mind might just enter zero for. 83 00:04:00.800 --> 00:04:03.400 Both zero for user name and password. That's it. 84 00:04:03.520 --> 00:04:07.199 And if the application uses loose comparisons, the kind that 85 00:04:07.319 --> 00:04:09.159 doesn't check the data type. 86 00:04:08.879 --> 00:04:11.400 It just sees zero matches zero, and boom, they're. 87 00:04:11.199 --> 00:04:13.400 In admin privileges just like that. 88 00:04:14.319 --> 00:04:17.839 So as a developer, how do I stop these type 89 00:04:17.920 --> 00:04:19.040 juggling shenanigans. 90 00:04:19.399 --> 00:04:23.800 Strict comparisons, my friend. Strict comparisons always, especially when you're 91 00:04:23.879 --> 00:04:24.879 checking user input. 92 00:04:25.279 --> 00:04:28.639 So not just if the values match, but if they're 93 00:04:28.639 --> 00:04:29.319 the same type of. 94 00:04:29.360 --> 00:04:32.920 Data precisely gets rid of all that ambiguity that hackers 95 00:04:33.040 --> 00:04:33.959 love to exploit. 96 00:04:33.959 --> 00:04:36.720 Okay, starting to see how those little quirks in programming 97 00:04:36.800 --> 00:04:39.279 languages can become huge security flaws. 98 00:04:39.279 --> 00:04:43.000 Oh. Absolutely, It's all about knowing those quirks and then thinking, 99 00:04:43.040 --> 00:04:45.439 like the bad guy, how would they twist this to 100 00:04:45.480 --> 00:04:46.160 their advantage? 101 00:04:46.240 --> 00:04:48.279 Right, get inside their heads now. 102 00:04:48.399 --> 00:04:51.519 The book also mentioned something called zero like type juggling. 103 00:04:51.920 --> 00:04:54.560 Zero Like that sounds even trickier it is. 104 00:04:54.759 --> 00:04:58.639 It is certain strings in PHP, when you compare them loosely, Oh, 105 00:04:58.680 --> 00:05:00.560 they end up being treated like the number zero. 106 00:05:00.800 --> 00:05:02.680 So like a blank space or something. 107 00:05:02.720 --> 00:05:06.120 Empty string, a string with just spaces. Yeah, that sort 108 00:05:06.160 --> 00:05:06.839 of thing, And a. 109 00:05:06.759 --> 00:05:09.480 Hacker could use those to sneak past checks that are 110 00:05:09.519 --> 00:05:10.759 looking for numbers. 111 00:05:10.759 --> 00:05:15.040 Exactly, manipulate input fields, parameters, stuff that wouldn't be obvious 112 00:05:15.079 --> 00:05:17.839 at first glance but can have big consequences. 113 00:05:18.120 --> 00:05:21.759 Wow. So type juggling really praise on the assumptions developers make. 114 00:05:21.879 --> 00:05:24.480 It does it does? And that brings us to our 115 00:05:24.519 --> 00:05:29.720 next topic. No SEQL databases. There's this myth out there 116 00:05:29.800 --> 00:05:32.279 that they're immune to injection attacks because they don't use 117 00:05:32.279 --> 00:05:32.959 SQL right. 118 00:05:33.079 --> 00:05:37.199 No SQL all about flexibility handling all sorts of unstructured data, 119 00:05:37.439 --> 00:05:38.120 right right. 120 00:05:38.160 --> 00:05:40.759 But just because it's not SQL doesn't mean it's safe. 121 00:05:40.879 --> 00:05:44.240 So hackers has figured out how to inject commands even 122 00:05:44.319 --> 00:05:46.759 without that classic SQL syntax they have. 123 00:05:47.000 --> 00:05:50.240 The book goes into some specific examples, with Mango dB 124 00:05:50.319 --> 00:05:52.920 and couch dB two of the popular ones. They show 125 00:05:52.959 --> 00:05:56.439 how hackers can craft these malicious queries that exploit weaknesses 126 00:05:56.519 --> 00:05:58.519 in how the database handles user input. 127 00:05:58.720 --> 00:06:00.920 So even if I'm not using SQUEL, I still got 128 00:06:00.959 --> 00:06:02.920 to be super careful about how I handle that data 129 00:06:02.959 --> 00:06:03.839 coming in from users. 130 00:06:03.879 --> 00:06:07.720 Absolutely improvalidation, standardization. Those principles apply no matter what kind 131 00:06:07.720 --> 00:06:09.439 of database you're using. And by the way, there are 132 00:06:09.480 --> 00:06:12.360 tools out there like no SQL map made specifically to 133 00:06:12.480 --> 00:06:14.879 find and exploit those no SQL vulnerabilities. 134 00:06:15.160 --> 00:06:17.959 It's like hackers have a special toolkit for every occasion 135 00:06:18.160 --> 00:06:18.600 they do. 136 00:06:19.240 --> 00:06:22.560 And speaking of toolkits, let's move on to another area 137 00:06:22.600 --> 00:06:26.399 where hackers are pretty creative. API hacking, especially when it 138 00:06:26.439 --> 00:06:27.759 comes to graph ql. 139 00:06:27.800 --> 00:06:32.240 APIs so graphql it's known for being really efficient, flexible, 140 00:06:32.399 --> 00:06:36.079 all that, but is it also known for being well insecure? 141 00:06:36.360 --> 00:06:41.000 Graphql itself doesn't prevent common vulnerabilities like SQL injection or 142 00:06:41.040 --> 00:06:44.360 cross site scripting. It all depends on how it's implemented, 143 00:06:44.439 --> 00:06:47.759 how secure the data sources and logic are underneath. 144 00:06:47.800 --> 00:06:51.000 So a hacker going after a graph QLAPI, they're not 145 00:06:51.040 --> 00:06:54.439 necessarily exploiting graphql itself, but rather how it's used. 146 00:06:54.639 --> 00:06:57.240 Exactly. Think of graph ql as a powerful tool, like 147 00:06:57.279 --> 00:06:58.279 a really sharp knife. 148 00:06:58.360 --> 00:06:58.519 Right. 149 00:06:58.639 --> 00:07:00.360 It can be used for good or bad. It's all 150 00:07:00.360 --> 00:07:01.360 in how you wield it. 151 00:07:01.480 --> 00:07:04.360 Okay, So walk me through this. How would a hacker 152 00:07:04.399 --> 00:07:07.199 approach a graph ql API? What are they trying to do? 153 00:07:07.439 --> 00:07:09.800 First step is usually reconnaissance. They got to find those 154 00:07:09.800 --> 00:07:12.720 graph ql endpoints and then figure out the schemer. 155 00:07:12.399 --> 00:07:13.839 Schema like a map of the API. 156 00:07:14.000 --> 00:07:17.199 That's it, the structure, the capabilities. They're a little blueprint 157 00:07:17.240 --> 00:07:18.319 for the attack. 158 00:07:18.319 --> 00:07:21.040 So intel gathering before the actual attack. 159 00:07:21.319 --> 00:07:25.439 Yep. Then they start crafting malicious queries, looking for ways 160 00:07:25.439 --> 00:07:29.800 to bypass authentication, grab sensitive data, even inject code that'll 161 00:07:29.839 --> 00:07:30.480 run on the server. 162 00:07:30.800 --> 00:07:34.079 Yis. So securing a graph ql API is more than 163 00:07:34.160 --> 00:07:37.360 just slapping on some basic login protection. 164 00:07:37.199 --> 00:07:39.800 Way more. You gotta think like a hacker. Imagine how 165 00:07:39.800 --> 00:07:41.040 they'd try to abuse. 166 00:07:40.680 --> 00:07:42.600 The system, right, stay one step ahead. 167 00:07:42.720 --> 00:07:46.040 That's the game. Now, let's not forget another big target 168 00:07:46.079 --> 00:07:49.839 for these guys, misconfigured cloud storage. 169 00:07:50.120 --> 00:07:51.759 Oh yeah, that's a big one these days. 170 00:07:51.800 --> 00:07:54.160 Cloud storage it's super convenient, but if it's. 171 00:07:54.040 --> 00:07:55.959 Not set up right, the gold mine for hackers. 172 00:07:56.000 --> 00:08:00.000 You got it, all those AWSS three buckets, Digital Ocean spaces, 173 00:08:00.279 --> 00:08:04.519 Azure blobs, Google cloud storage. If the permissions are loose, 174 00:08:04.800 --> 00:08:06.079 files are public. 175 00:08:05.839 --> 00:08:07.360 It's like leaving the door wide open. 176 00:08:07.839 --> 00:08:10.439 And this book has some scary examples of the commands 177 00:08:10.439 --> 00:08:14.759 hackers use. They probe for weaknesses, list files, download data, 178 00:08:14.800 --> 00:08:16.360 even delete or modify stuff. 179 00:08:16.399 --> 00:08:18.720 So it's not just about stealing data, it's about causing 180 00:08:18.800 --> 00:08:20.279 chaos unfortunately. 181 00:08:20.360 --> 00:08:23.759 Yeah, and what's worse, there are tools out there aws 182 00:08:23.800 --> 00:08:28.279 bucket dump, spaces Finder, things like that. These tools automate 183 00:08:28.319 --> 00:08:33.799 the whole process of finding and exploiting these misconfigured cloud setups. 184 00:08:33.840 --> 00:08:37.120 So it's like a shopping spree for hackers, browsing through 185 00:08:37.240 --> 00:08:39.720 vulnerable storage buckets taking what they want. 186 00:08:40.039 --> 00:08:42.759 That's a pretty accurate picture. And the scary part is 187 00:08:42.840 --> 00:08:45.039 a lot of companies don't even know how much sensitive 188 00:08:45.120 --> 00:08:46.840 data they have out there in the cloud or how 189 00:08:46.879 --> 00:08:48.039 bad their security is. 190 00:08:48.279 --> 00:08:50.120 All right, starting to feel a little paranoid. 191 00:08:50.200 --> 00:08:54.440 Now, don't worry, We're not done yet. There's a lot 192 00:08:54.440 --> 00:08:57.360 more ground to cover in this deep dive. Next up, 193 00:08:57.399 --> 00:09:01.720 we'll get into server side request forgery, a really sneaky 194 00:09:01.759 --> 00:09:05.120 attack that takes advantage of how applications trust each other. 195 00:09:05.200 --> 00:09:08.759 Okay, I'm all ears. Let's see what other tricks these 196 00:09:08.799 --> 00:09:11.320 hackers have up their sleeves. Yeah, we've been talking about 197 00:09:11.320 --> 00:09:14.679 how hackers target databases and APIs, and it seems like 198 00:09:14.720 --> 00:09:17.679 no matter what you use, there's always some angle they 199 00:09:17.720 --> 00:09:18.320 can exploit. 200 00:09:18.480 --> 00:09:21.200 Yeah, that's true. And as applications get more complex, right, 201 00:09:21.240 --> 00:09:23.120 you know, relying on all these different systems talking to 202 00:09:23.159 --> 00:09:25.720 each other, Well, that just creates more opportunities for attacks. 203 00:09:25.759 --> 00:09:29.039 That's what makes this next topic so interesting. Server side 204 00:09:29.039 --> 00:09:31.240 request forgery SSRF. 205 00:09:31.480 --> 00:09:34.080 SSRF. I've heard that term, yeah, yeah, but not really 206 00:09:34.120 --> 00:09:34.759 sure what it is. 207 00:09:34.960 --> 00:09:37.279 Okay, So think about it this way. A lot of 208 00:09:37.320 --> 00:09:41.759 web apps they need to fetch data from other systems, right, 209 00:09:41.840 --> 00:09:43.440 internal services, things like that. 210 00:09:43.399 --> 00:09:45.519 Right behind the scenes stuff exactly. 211 00:09:45.120 --> 00:09:48.240 And they do this by making requests within their own network, 212 00:09:48.320 --> 00:09:51.720 you know, where they trust everything, right. SSRF is all 213 00:09:51.759 --> 00:09:55.679 about tricking the application into making those requests to places 214 00:09:55.679 --> 00:09:56.559 that shouldn't be going. 215 00:09:56.919 --> 00:09:59.840 Oh so it's like the app becomes its own insider threat. 216 00:10:00.080 --> 00:10:04.320 Exactly, it's tricked into fetching data that it shouldn't have access. 217 00:10:03.960 --> 00:10:06.320 To, and the hacker is pulling the string, pulling the. 218 00:10:06.320 --> 00:10:10.440 Strings exactly, the app is making requests on the hacker's behalf. Essentially, 219 00:10:11.039 --> 00:10:13.559 in this book, it goes into some really clever techniques 220 00:10:13.600 --> 00:10:16.679 they use. Okay, like what well, for example, they might 221 00:10:16.759 --> 00:10:20.919 use tools like BURP Collaborator or SSRF. 222 00:10:20.159 --> 00:10:21.679 Maps sound familiar. 223 00:10:21.840 --> 00:10:24.879 Yeah, these tools they act like little listening posts. The 224 00:10:24.919 --> 00:10:27.720 hacker can see if the application is making requests to 225 00:10:27.840 --> 00:10:28.559 their servers. 226 00:10:28.600 --> 00:10:30.559 Oh so that's how they test if it's vulnerable in 227 00:10:30.600 --> 00:10:31.159 the first place. 228 00:10:31.559 --> 00:10:34.600 Exactly, if they see those requests coming in, they know 229 00:10:34.679 --> 00:10:37.440 they've got a potential SSRF vulnerability. 230 00:10:37.559 --> 00:10:40.000 Okay, So let's say they find a vulnerable app. What's 231 00:10:40.080 --> 00:10:42.279 the worst case scenario? What can they actually do with that? 232 00:10:42.639 --> 00:10:44.919 Oh, it can be bad. It can be bad. They 233 00:10:44.960 --> 00:10:49.720 can use SSRF to get into sensitive internal systems. Okay, 234 00:10:49.919 --> 00:10:54.000 steal data that's not publicly accessible, even run commands on 235 00:10:54.039 --> 00:10:55.080 those internal servers. 236 00:10:55.240 --> 00:10:55.639 Yikes. 237 00:10:55.759 --> 00:10:59.840 Imagine them getting into a company's financial records or they're 238 00:11:00.000 --> 00:11:00.799 customer database. 239 00:11:00.840 --> 00:11:03.360 It's been manipulating these internal requests exactly. 240 00:11:03.840 --> 00:11:08.039 Now, the book also mentioned something interesting, exploiting cloud based 241 00:11:08.279 --> 00:11:09.399 metadata APIs. 242 00:11:09.440 --> 00:11:10.080 How does that work? 243 00:11:10.279 --> 00:11:12.720 Okay, So with the cloud, applications often run in these 244 00:11:12.799 --> 00:11:16.960 environments where they can access metadata services. These services provide 245 00:11:16.960 --> 00:11:21.080 info about the app's configuration, the infrastructure around it. Hackers 246 00:11:21.120 --> 00:11:24.240 can use SSRF to force the application to query these 247 00:11:24.279 --> 00:11:25.240 metadata services. 248 00:11:25.279 --> 00:11:26.919 Oh, so they can learn about the whole cloud. 249 00:11:26.720 --> 00:11:30.720 Environment exactly, potentially revealing sensitive details that they can then 250 00:11:30.840 --> 00:11:33.240 use for further attacks. And what makes it tricky is 251 00:11:33.240 --> 00:11:38.279 that these cloud metadata services, they often have very predictable structures. 252 00:11:38.679 --> 00:11:42.600 It's like giving the hacker a blueprint of the cloud environment. 253 00:11:42.240 --> 00:11:44.519 All thanks to one vulnerable app. 254 00:11:44.759 --> 00:11:47.240 And the book even talks about using the Gopher protocol. 255 00:11:47.399 --> 00:11:51.279 Gopher that's like ancient, right it is. 256 00:11:51.720 --> 00:11:55.080 But it can still be effective for SSRF in certain situations. 257 00:11:55.399 --> 00:11:57.120 So they're dusting off these old tricks. 258 00:11:57.120 --> 00:11:59.200 They are they are. It just shows you how creative 259 00:11:59.240 --> 00:12:02.200 these guys can be. Now, let's shift gears a bit. 260 00:12:02.279 --> 00:12:06.360 Let's talk about application logic flaws. Okay, these are vulnerabilities 261 00:12:06.360 --> 00:12:09.360 that come from mistakes in how the app is designed, 262 00:12:09.679 --> 00:12:11.799 not necessarily from bad code itself. 263 00:12:12.000 --> 00:12:14.000 Oh interesting, So, like, what's an example of that. 264 00:12:14.120 --> 00:12:17.159 Imagine an e commerce site, right, they have discount coupons 265 00:12:17.159 --> 00:12:18.200 you can apply it check out. 266 00:12:18.320 --> 00:12:19.240 Yeah, pretty common. 267 00:12:19.320 --> 00:12:21.480 A hacker might find a way to mess with the 268 00:12:21.519 --> 00:12:25.559 logic of that coupon system, you know, to apply multiple 269 00:12:25.559 --> 00:12:26.720 discounts at once. 270 00:12:26.639 --> 00:12:28.440 So they get set for free or almost free. 271 00:12:28.480 --> 00:12:31.960 Exactly. The book has all sorts of examples like this, okay, 272 00:12:32.039 --> 00:12:36.759 like what manipulating input fields to bypass checks, exploding race 273 00:12:36.799 --> 00:12:40.399 conditions where multiple things happen at the same time, even 274 00:12:40.480 --> 00:12:44.600 tricking the application into revealing sensitive info through error messages. 275 00:12:44.720 --> 00:12:46.519 So it's not about breaking the code, it's about breaking 276 00:12:46.519 --> 00:12:48.120 the rules of the game exactly. 277 00:12:48.120 --> 00:12:51.799 It's like they're master illusionists, finding those loopholes in the 278 00:12:51.879 --> 00:12:54.360 logic to do things that shouldn't be possible. 279 00:12:54.639 --> 00:12:57.559 And these logic flaws they seem harder to defend against. 280 00:12:57.720 --> 00:13:00.240 They are. They are because you need a really deep 281 00:13:00.320 --> 00:13:03.480 understanding of how the application works what it's supposed to do. 282 00:13:03.840 --> 00:13:06.279 So it's not enough to just write secure code. You 283 00:13:06.320 --> 00:13:08.759 need to understand the whole picture precisely. 284 00:13:09.240 --> 00:13:11.759 Now, let's talk about something that's supposed to make things 285 00:13:11.759 --> 00:13:17.360 more secure. Authentication and authorization protocols like SAML and OTH 286 00:13:17.440 --> 00:13:18.279 two point zero. 287 00:13:18.360 --> 00:13:21.039 Okay, I've heard those terms, but I'm not really sure 288 00:13:21.080 --> 00:13:21.559 how they work. 289 00:13:21.639 --> 00:13:25.440 Okay. So SAMLUS that stands for Security Assertion Markup Language. 290 00:13:25.759 --> 00:13:28.879 It's a way for different systems to securely exchange info 291 00:13:28.960 --> 00:13:33.000 about authentication and authorization. It's often used in businesses for 292 00:13:33.080 --> 00:13:35.240 single sign on. You know where you log in once 293 00:13:35.240 --> 00:13:37.639 and you can access multiple applications. 294 00:13:37.120 --> 00:13:39.039 Right, makes things easier for users exactly. 295 00:13:39.399 --> 00:13:42.600 But of course hackers have found ways to attack SAML too. 296 00:13:43.240 --> 00:13:44.600 No surprise there, AMLL. 297 00:13:44.759 --> 00:13:47.600 It uses XML, and that makes it vulnerable to something 298 00:13:47.639 --> 00:13:51.799 called XML external entity injection attacks or x e XX. 299 00:13:52.080 --> 00:13:52.720 I think I heard of that. 300 00:13:52.840 --> 00:13:56.080 Yeah, it's all about exploiting how XML documents are processed. 301 00:13:56.240 --> 00:14:00.879 Hackers can craft these malicious XML documents okay, and trick 302 00:14:00.960 --> 00:14:04.200 the server into accessing external entities and that can lead 303 00:14:04.240 --> 00:14:07.159 to oh, all sorts of bad stuff, sensitive data leaks, 304 00:14:07.399 --> 00:14:10.879 denial of service attacks, even remote code execution. 305 00:14:11.279 --> 00:14:14.639 So it's like turning the XML processing into a weapon exactly. 306 00:14:14.679 --> 00:14:17.200 They can use it to read files from the server, okay, 307 00:14:17.200 --> 00:14:19.759 access internal networks, even run commands. 308 00:14:19.799 --> 00:14:23.399 Wow, that's a lot of power from one seemingly simple attack. 309 00:14:23.559 --> 00:14:26.039 It is, so if you're implementing SAML, you've got to 310 00:14:26.080 --> 00:14:28.080 be really careful about how you can figure that XML 311 00:14:28.120 --> 00:14:28.759 parser right. 312 00:14:28.799 --> 00:14:30.720 Make sure it's not doing anything it shouldn't. 313 00:14:30.399 --> 00:14:34.200 Be doing exactly. Disable external entity resolution if you don't 314 00:14:34.200 --> 00:14:38.679 absolutely need it, and always sanitize any external input before 315 00:14:38.720 --> 00:14:40.679 you even think about treating it as XML. 316 00:14:40.720 --> 00:14:42.600 Treat it with extreme caution exactly. 317 00:14:43.080 --> 00:14:46.399 And the book also mentions other SAMMEL attacks, things like 318 00:14:46.440 --> 00:14:48.840 signature stripping and XML signature wrapping. 319 00:14:48.960 --> 00:14:51.639 So it's like a whole world of vulnerabilities within SAML. 320 00:14:51.799 --> 00:14:54.159 It can be if you're not careful. Now let's talk 321 00:14:54.159 --> 00:14:57.679 about both two point zero. That's another popular authorization protocol. 322 00:14:57.840 --> 00:14:59.840 Yeah, oh, I see that all the time logging into 323 00:15:00.000 --> 00:15:01.840 websites with my Google account. 324 00:15:01.600 --> 00:15:05.960 Or Facebook, right exactly. OATH is all about delegating authorization. 325 00:15:06.720 --> 00:15:10.080 So instead of sharing your password with a third party app, right, 326 00:15:10.120 --> 00:15:12.720 you just give them permission to access your account through 327 00:15:12.759 --> 00:15:14.000 this secure process. 328 00:15:14.159 --> 00:15:17.000 Much safer than typing in your password everywhere, way safer. 329 00:15:17.480 --> 00:15:21.000 But like any complex system, OATH two point zero has 330 00:15:21.039 --> 00:15:22.279 its own weaknesses, like. 331 00:15:22.279 --> 00:15:24.480 What give me an example of something that would keep 332 00:15:24.480 --> 00:15:25.519 a developer up at night. 333 00:15:25.600 --> 00:15:29.840 Okay, so one common attack is insufficient redirect URI validation 334 00:15:30.159 --> 00:15:31.240 redirect URI. 335 00:15:31.559 --> 00:15:31.919 What's that? 336 00:15:32.240 --> 00:15:34.960 So when you authorize a third party app with OTH, 337 00:15:35.360 --> 00:15:39.399 there's this redirect URI that tells your browser where to 338 00:15:39.440 --> 00:15:41.000 go after you've given permission. 339 00:15:41.080 --> 00:15:43.039 Okay, so it's like the return address exactly. 340 00:15:43.600 --> 00:15:48.039 Now, if the app doesn't properly validate those redirect URIs, 341 00:15:48.840 --> 00:15:50.960 a hacker can create a malicious one and. 342 00:15:50.960 --> 00:15:53.360 Send the user to a fake website exactly. 343 00:15:53.840 --> 00:15:56.759 The user thinks they're going back to the legitimate app. 344 00:15:57.039 --> 00:15:59.240 But they're actually giving their info to the hacker. 345 00:15:59.320 --> 00:16:03.279 That's right. And the book goes into other obooth vulnerabilities too, 346 00:16:03.360 --> 00:16:06.120 things like cross site request forgery, Yeah I've heard of 347 00:16:06.120 --> 00:16:09.679 that one, and authorization code replay attacks. So even with 348 00:16:09.759 --> 00:16:13.360 these modern authorization protocols, there's still plenty of room for error. 349 00:16:13.759 --> 00:16:17.399 It seems like everywhere we look there's another potential vulnerability. 350 00:16:17.480 --> 00:16:20.120 It's a constant game of cat and mouse. Attackers are 351 00:16:20.120 --> 00:16:22.159 always finding new ways to exploit things. 352 00:16:22.480 --> 00:16:24.960 This deep dive is definitely making me rethink my whole 353 00:16:24.960 --> 00:16:26.120 approach to security. 354 00:16:26.200 --> 00:16:29.639 It's all about awareness. The more you know about these vulnerabilities, 355 00:16:29.759 --> 00:16:31.360 the better you can defend against them. 356 00:16:31.480 --> 00:16:33.080 Right, So what comes next? 357 00:16:33.480 --> 00:16:35.960 Well, in part three, we'll take all this information we've 358 00:16:35.960 --> 00:16:38.759 covered and we'll distill it down into some key takeaways, 359 00:16:38.799 --> 00:16:41.720 some actionable advice you can actually use to make your 360 00:16:41.759 --> 00:16:43.000 systems more secure. 361 00:16:43.799 --> 00:16:47.039 Okay, we've gone through a lot. Yeah, we have decerialization, 362 00:16:47.279 --> 00:16:50.480 sam l O Walth all those vulnerabilities, right, I gotta 363 00:16:50.480 --> 00:16:52.000 be honest, it's kind of overwhelming. 364 00:16:52.120 --> 00:16:52.960 I can't understand. 365 00:16:52.960 --> 00:16:56.720 That makes you realize just how many ways a hacker 366 00:16:56.799 --> 00:16:58.159 could get into an application. 367 00:16:58.799 --> 00:17:01.320 But that's not the point of this deep dive, right. 368 00:17:01.399 --> 00:17:04.359 The goal isn't to scare you. It's to give you 369 00:17:04.400 --> 00:17:07.920 the knowledge you need to build things better, more secure systems. 370 00:17:08.160 --> 00:17:11.599 Okay, so let's talk defense. If I'm building a web app, 371 00:17:12.119 --> 00:17:15.000 what are the biggest lessons here the must dos to 372 00:17:15.079 --> 00:17:16.680 protect myself from all these attacks? 373 00:17:16.839 --> 00:17:19.119 I think the biggest thing is security. It's not just 374 00:17:19.160 --> 00:17:21.680 a checklist, it's a way of thinking. You got to 375 00:17:21.720 --> 00:17:23.440 constantly be thinking like a hacker. 376 00:17:24.000 --> 00:17:26.960 Easy to say, hard to do, huh, Right. 377 00:17:27.160 --> 00:17:29.359 But seriously, you've got to imagine how they try to 378 00:17:29.400 --> 00:17:30.400 exploit your app. 379 00:17:30.640 --> 00:17:33.640 But how do I get into that hacker mindset. I'm 380 00:17:33.640 --> 00:17:34.680 not a security expert. 381 00:17:35.119 --> 00:17:37.160 Well, this book is a good start. It shows you 382 00:17:37.200 --> 00:17:39.680 the common attack patterns. Okay, so you can start to 383 00:17:39.680 --> 00:17:42.359 see your app through their eyes, and then you can 384 00:17:42.359 --> 00:17:46.160 build defenses that actually address those vulnerabilities. 385 00:17:46.319 --> 00:17:49.480 So it's not just about generic security tools, No, it's 386 00:17:49.519 --> 00:17:51.640 about understanding the specific threats. 387 00:17:51.359 --> 00:17:55.160 You face exactly now. One thing that keeps coming up 388 00:17:55.200 --> 00:17:59.799 again and again in this deep dive input validation and sanitization. 389 00:18:00.119 --> 00:18:02.000 Right, assume all user input. 390 00:18:01.759 --> 00:18:06.079 Is evil exactly. Never trust it, validate it, sanitize it, 391 00:18:06.240 --> 00:18:08.559 escape it properly before you use it for anything. 392 00:18:08.720 --> 00:18:10.839 Queries commands, anything like. 393 00:18:10.799 --> 00:18:12.880 That prevents a whole bunch of attacks right there. 394 00:18:12.920 --> 00:18:17.440 Doable injection, cross site scripting, even those deserialization attacks, all 395 00:18:17.480 --> 00:18:17.720 of them. 396 00:18:17.759 --> 00:18:20.440 It's like having a security checkpoint at the entrance to your. 397 00:18:20.319 --> 00:18:22.599 App, carefully screening everything that comes in. 398 00:18:22.640 --> 00:18:28.599 Another big one, secure configuration and patching strong passwords, access controls, 399 00:18:29.079 --> 00:18:32.200 disabling anything you don't need, okay, and keep your software 400 00:18:32.279 --> 00:18:34.799 up to date. Those security patches are crucial. 401 00:18:35.319 --> 00:18:37.720