WEBVTT 1 00:00:00.120 --> 00:00:03.600 Welcome to your deep dive. We're cracking open web hacking 2 00:00:03.680 --> 00:00:07.000 one oh one today, a book you specifically requested. 3 00:00:07.120 --> 00:00:08.640 Oh this is a good one. Yeah. 4 00:00:08.720 --> 00:00:11.320 It's all about ethical hacking. And I think what makes 5 00:00:11.400 --> 00:00:15.119 this duck dive particularly interesting is all these stories about 6 00:00:15.160 --> 00:00:20.760 vulnerabilities founding companies you use every day, Google, Shopify, even Twitter. 7 00:00:21.079 --> 00:00:24.399 What's fascinating is the author Pete Yorski. Yeah, he's a 8 00:00:24.440 --> 00:00:28.000 hacker himself, so he doesn't just list vulnerabilities. He shows 9 00:00:28.000 --> 00:00:30.280 you how they were discovered, right, and he's got the 10 00:00:30.320 --> 00:00:33.000 team from hacker one chime me in with their insights. Yeah, 11 00:00:33.079 --> 00:00:35.439 which is really cool because hacker one's a leading bug 12 00:00:35.479 --> 00:00:36.359 bounty platform. 13 00:00:36.479 --> 00:00:39.039 That's right, So we're getting like the inside scoop from 14 00:00:39.039 --> 00:00:39.640 the pros here. 15 00:00:39.840 --> 00:00:40.280 Yeah. 16 00:00:40.359 --> 00:00:42.840 Now, before we jump into the juicy stuff, can you 17 00:00:42.920 --> 00:00:44.719 just set the stage for us, like, how does the 18 00:00:44.799 --> 00:00:47.240 Internet even work at a basic level? I think that 19 00:00:47.280 --> 00:00:49.439 will help us understand these vulnerabilities better. 20 00:00:49.679 --> 00:00:50.000 Sure. 21 00:00:50.200 --> 00:00:52.880 So, at its core, the Internet is all about communication 22 00:00:52.960 --> 00:00:56.240 between systems. Okay, think of it as like sending letters 23 00:00:56.280 --> 00:00:59.200 back and forth, but digitally, each message has a specific 24 00:00:59.280 --> 00:01:03.240 purpose like retrieving information or sending data, and follows a 25 00:01:03.240 --> 00:01:06.560 set of rules called protocols, kind of like the postal system. 26 00:01:06.599 --> 00:01:06.920 Okay. 27 00:01:06.959 --> 00:01:10.120 One of the most important protocols is HTTP, the language 28 00:01:10.159 --> 00:01:12.319 your web browser uses to talk to websites. 29 00:01:12.400 --> 00:01:15.519 Okay, so we have our messages and they're following these 30 00:01:15.599 --> 00:01:19.000 rules these protocols, right, But how does a hacker exploit that? 31 00:01:19.319 --> 00:01:22.760 Well, one way is through something called HTML injection. Okay, 32 00:01:23.000 --> 00:01:26.200 it's like sneaking an extra line into a movie script. Huh, 33 00:01:26.400 --> 00:01:31.400 potentially changing the whole scene. Attackers inject HTML code into 34 00:01:31.439 --> 00:01:34.439 a web page, which can alter its appearance or even 35 00:01:34.480 --> 00:01:35.159 trick users. 36 00:01:35.239 --> 00:01:37.480 That sounds sneaky. Does the book have any like real 37 00:01:37.519 --> 00:01:38.719 world examples of this? 38 00:01:38.959 --> 00:01:39.359 It does. 39 00:01:39.560 --> 00:01:43.000 One example involves Coinbase, the cryptocurrency platform. 40 00:01:43.120 --> 00:01:43.400 Okay. 41 00:01:43.760 --> 00:01:46.560 A hacker found a way to bypass their security filters 42 00:01:47.159 --> 00:01:50.359 using something called URL encoding. Okay, it's like using a 43 00:01:50.400 --> 00:01:52.640 secret code to slip a message past security. 44 00:01:52.719 --> 00:01:53.079 Okay. 45 00:01:53.640 --> 00:01:56.359 They were able to inject a fake login form that 46 00:01:56.439 --> 00:01:57.959 could have stolen user credentials. 47 00:01:58.159 --> 00:02:01.159 Wait, so RL encoding is kind of like disguising something 48 00:02:01.280 --> 00:02:04.480 dangerous as harmless text. How does that even work? 49 00:02:04.680 --> 00:02:08.000 Imagine you have a message with characters that aren't allowed 50 00:02:08.000 --> 00:02:09.039 by the system you're using. 51 00:02:09.159 --> 00:02:09.400 Right. 52 00:02:09.719 --> 00:02:14.520 URL encoding converts those characters into a format that is allowed. Okay, 53 00:02:14.680 --> 00:02:16.719 think of it as like translating a message into a 54 00:02:16.759 --> 00:02:18.719 different language that the system understands. 55 00:02:18.759 --> 00:02:19.159 Gotcha. 56 00:02:19.560 --> 00:02:22.879 And at its root, it's based on ASCI, which is 57 00:02:22.919 --> 00:02:25.000 a way to represent characters as numbers. 58 00:02:25.240 --> 00:02:28.280 So the website thinks it's processing regular text, but it's 59 00:02:28.319 --> 00:02:33.080 actually executing malicious code. That's scary. Exactly what other tricks 60 00:02:33.080 --> 00:02:35.639 do you hackers have up their sleeves? What about HTTP 61 00:02:35.759 --> 00:02:37.560 parameter pollution? Ah? 62 00:02:37.639 --> 00:02:40.639 Yes, this one's all about messing with the instruction sent 63 00:02:40.719 --> 00:02:43.520 in those digital letters we talked about. Okay, you slip 64 00:02:43.639 --> 00:02:46.800 extra hidden instructions into a request to change how a 65 00:02:46.840 --> 00:02:49.800 website behaves. It's like secretly adding an ingredient to a 66 00:02:49.840 --> 00:02:52.039 recipe to completely change the outcome. 67 00:02:52.199 --> 00:02:54.159 This is where it gets really interesting. Are there any 68 00:02:54.159 --> 00:02:55.439 examples of this in the book. 69 00:02:55.560 --> 00:02:58.280 Oh, there are a few good ones involving Twitter. One 70 00:02:58.360 --> 00:03:03.199 hacker managed to unsubscribe users from email notifications just by 71 00:03:03.199 --> 00:03:06.280 adding an extra parameter to the request. It's amazing how 72 00:03:06.719 --> 00:03:10.080 such a small tweak can have such a significant impact. 73 00:03:10.280 --> 00:03:12.639 Yeah, it's like pushing the wrong button and causing a 74 00:03:12.879 --> 00:03:14.039 system wide meltdown. 75 00:03:14.199 --> 00:03:14.360 Right? 76 00:03:14.759 --> 00:03:16.319 What else did the book say about Twitter? 77 00:03:16.879 --> 00:03:21.039 There's another vulnerability mentioned involving web intens. These are pre 78 00:03:21.120 --> 00:03:24.960 built functions for things like following someone or liking a tweet. Okay, 79 00:03:25.599 --> 00:03:28.039 the hacker found a way to manipulate them using this 80 00:03:28.159 --> 00:03:32.479 same parameter pollution technique. Imagine clicking a link thinking you're 81 00:03:32.479 --> 00:03:35.199 going to follow a celebrity, but it actually makes you 82 00:03:35.240 --> 00:03:36.840 follow some random bought account. 83 00:03:37.039 --> 00:03:40.520 Oh wow, that's seriously sneaky. It's like those trick birthday 84 00:03:40.520 --> 00:03:42.680 candles that relight after you blow them out. You think 85 00:03:42.719 --> 00:03:45.439 you've got it under control, but nope, exactly. So if 86 00:03:45.479 --> 00:03:48.280 a hacker can manipulate something as simple as a follow button, 87 00:03:48.479 --> 00:03:49.759 what else are they capable of? 88 00:03:50.680 --> 00:03:53.680 Well, let's talk about CRLF injection. Okay, so it's a 89 00:03:53.719 --> 00:03:57.159 bit more technical, but equally impactful. Cr LEFT stands for 90 00:03:57.520 --> 00:04:01.159 carriage return line feed, which is basically the code that 91 00:04:01.159 --> 00:04:03.000 tells a computer to start a new line. 92 00:04:03.199 --> 00:04:05.960 Okay, so we're talking about exploiting line breaks. Ye, how 93 00:04:06.000 --> 00:04:06.919 is that even possible? 94 00:04:07.319 --> 00:04:12.240 By injecting CRLs characters at specific points, attackers can manipulate 95 00:04:12.319 --> 00:04:16.199 how a website processes requests and responses. This could lead 96 00:04:16.240 --> 00:04:17.920 to something called cash poisoning. 97 00:04:18.240 --> 00:04:21.399 Cash poisoning that sounds like a recipe for disaster it 98 00:04:21.480 --> 00:04:23.279 can be what exactly does that mean? 99 00:04:23.560 --> 00:04:26.959 Websites often store frequently accessed content in a cash to 100 00:04:27.000 --> 00:04:30.639 speed things up. A hacker could inject malicious code into 101 00:04:30.680 --> 00:04:33.519 that cache, than anyone who visits the site and loads 102 00:04:33.560 --> 00:04:36.279 that cased content could end up running that malicious code. 103 00:04:36.360 --> 00:04:38.639 So it's like contaminating a water supply. Everyone who drinks 104 00:04:38.639 --> 00:04:41.319 from it gets sick. What other havoc can hackers reek 105 00:04:41.439 --> 00:04:43.600 with CRLF injection? 106 00:04:43.839 --> 00:04:47.680 They could potentially hijack user sessions. Imagine a hacker stealing 107 00:04:47.720 --> 00:04:50.560 your logging cookies, giving them axis to your account without 108 00:04:50.600 --> 00:04:53.920 even knowing your password. The book highlights a particularly dramatic 109 00:04:53.959 --> 00:04:57.439 example involving Twitter. A hacker exploited a bug in the 110 00:04:57.439 --> 00:05:01.399 Firefox browser to inject CRF character, potentially allowing them to 111 00:05:01.439 --> 00:05:02.600 steal session information. 112 00:05:02.839 --> 00:05:05.040 So even a bug and a browser can become a 113 00:05:05.040 --> 00:05:07.839 weapon in the hands of a skilled hacker. That's a 114 00:05:07.879 --> 00:05:11.759 stark reminder that security is a complex web and every 115 00:05:11.920 --> 00:05:15.720 thread is important. Speaking of webs let's talk about cross 116 00:05:15.720 --> 00:05:18.040 site request forgery or CSRF. 117 00:05:18.319 --> 00:05:22.120 CSRF is all about tricking a user's browser into performing 118 00:05:22.160 --> 00:05:25.000 actions on a website where they're already logged in. Okay, 119 00:05:25.120 --> 00:05:26.839 think of it this way. You're logged into your online 120 00:05:26.839 --> 00:05:29.319 banking and then you click a link in a seemingly 121 00:05:29.319 --> 00:05:32.079 harmless email. That link could be designed to trigger a 122 00:05:32.120 --> 00:05:35.360 transaction transferring money out of your account without you ever 123 00:05:35.439 --> 00:05:36.000 realizing it. 124 00:05:36.160 --> 00:05:39.040 That's terrifying. So you're tricked into doing something you never intended, 125 00:05:39.160 --> 00:05:41.720 like a digital puppet master pulling your strings. 126 00:05:41.399 --> 00:05:44.600 Exactly, and it can be incredibly subtle. The book gives 127 00:05:44.600 --> 00:05:47.120 an example where a hacker was able to export user 128 00:05:47.199 --> 00:05:52.079 data from Shopify by exploiting a CSRF vulnerability. They created 129 00:05:52.079 --> 00:05:54.639 a malicious link that, when clicked by a logged in 130 00:05:54.680 --> 00:05:58.839 Shopify user, triggered the export function without proper authorization. 131 00:05:59.240 --> 00:06:03.920 Wow. W Seemingly harmless actions like clicking a link can 132 00:06:04.000 --> 00:06:07.360 be dangerous if you're not careful. It's a good reminder 133 00:06:07.399 --> 00:06:10.360 to be wary of anything that seems suspicious, even if 134 00:06:10.399 --> 00:06:11.800 it comes from a trusted source. 135 00:06:12.040 --> 00:06:14.839 Absolutely, it's all about being aware of the potential risks 136 00:06:15.079 --> 00:06:16.680 and taking steps to protect yourself. 137 00:06:17.000 --> 00:06:18.920 Okay, let's shift gears a bit and talk about a 138 00:06:18.959 --> 00:06:23.600 different kind of vulnerability. Application logic vulnerabilities. What makes these 139 00:06:23.600 --> 00:06:25.800 different from the injection attacks we've been discussing. 140 00:06:26.160 --> 00:06:31.240 Instead of injecting malicious code directly, these vulnerabilities exploit flaws 141 00:06:31.240 --> 00:06:34.199 in how the application's code works. It's like finding a 142 00:06:34.240 --> 00:06:36.079 loophole in a contract to get what you want. 143 00:06:36.279 --> 00:06:38.079 So it's not about breaking the rules, but bending them. 144 00:06:38.240 --> 00:06:39.000 Yeah, clever. 145 00:06:39.360 --> 00:06:40.839 Does the book have any examples of this? 146 00:06:41.120 --> 00:06:41.399 Yes. 147 00:06:41.959 --> 00:06:45.600 A hacker named Igor Homo coof exploited GitHub by taking 148 00:06:45.639 --> 00:06:48.519 advantage of a flaw and how their code handled data updates. 149 00:06:48.920 --> 00:06:52.040 He was able to manipulate sensitive information, which had some 150 00:06:52.160 --> 00:06:56.279 unexpected consequences. It shows that sometimes the most dangerous vulnerabilities 151 00:06:56.319 --> 00:07:00.120 aren't about boot force attacks, but rather understanding the systems 152 00:07:00.160 --> 00:07:02.439 logic and finding those subtle weaknesses. 153 00:07:02.680 --> 00:07:05.160 It's like that saying, give me a lever long enough 154 00:07:05.160 --> 00:07:06.879 and a full chrume on which to place it, and 155 00:07:06.920 --> 00:07:09.120 I shall move the world right. Hackers seem to be 156 00:07:09.240 --> 00:07:11.560 masters at finding those levers and fulcrums. 157 00:07:11.639 --> 00:07:14.680 That's a great analogy. It requires a deep understanding of 158 00:07:14.680 --> 00:07:18.639 how applications work and an eye for spotting inconsistencies. 159 00:07:19.079 --> 00:07:22.480 Now, speaking of inconsistencies, let's talk about cross site scripting. 160 00:07:22.680 --> 00:07:26.399 Or EXSS. That sounds like another one of those sneaky attacks. 161 00:07:26.800 --> 00:07:31.879 XSS is all about injecting malicious JavaScript code into a website, 162 00:07:32.439 --> 00:07:36.040 which is then executed by other users. It's like planting 163 00:07:36.079 --> 00:07:39.959 a trap that unsuspecting visitors will trigger. A simple example 164 00:07:40.000 --> 00:07:42.199 would be injecting code that creates a pop up alert, 165 00:07:42.199 --> 00:07:44.079 but obviously it can get much more. 166 00:07:43.879 --> 00:07:44.560 Serious than that. 167 00:07:44.680 --> 00:07:46.680 Oh I bet so what kind of damage could a 168 00:07:46.680 --> 00:07:48.040 hacker do with XSS? 169 00:07:48.240 --> 00:07:52.199 They could potentially steal user cookies, redirect them to malicious websites, 170 00:07:52.519 --> 00:07:55.399 or even take control of their entire browser session. The 171 00:07:55.439 --> 00:07:59.040 book shares a few examples of XSS vulnerabilities found on Shopify. 172 00:07:59.399 --> 00:08:02.519 One involved basic input field on their wholesale site that 173 00:08:02.639 --> 00:08:03.759 wasn't properly secure. 174 00:08:03.920 --> 00:08:06.680 So even something as simple as an input field can 175 00:08:06.759 --> 00:08:11.879 be vulnerable if developers aren't careful. What other EXSS examples 176 00:08:12.079 --> 00:08:13.399 stood out to you from the book? 177 00:08:13.519 --> 00:08:17.560 There's another one involving Shopify. This time the vulnerability wasn't 178 00:08:17.560 --> 00:08:20.839 in an obvious place like an input field, but rather 179 00:08:20.879 --> 00:08:24.160 in the name property of a file input. Hackers are 180 00:08:24.199 --> 00:08:28.600 always looking for those unconventional attack vectors, those unexpected places 181 00:08:28.639 --> 00:08:30.600 where vulnerabilities might be hiding. 182 00:08:30.519 --> 00:08:32.320 So you really have to think like a hacker to 183 00:08:32.360 --> 00:08:35.360 find these hidden vulnerabilities. It's like playing a game of 184 00:08:35.440 --> 00:08:38.360 hide and seek, but with potentially disastrous consequences. 185 00:08:38.519 --> 00:08:40.279 That's why it's so important for developers to have a 186 00:08:40.279 --> 00:08:43.240 strong security mindset and to be constantly on the lookout 187 00:08:43.279 --> 00:08:46.720 for potential weaknesses. It's a continuous process of learning and improvement. 188 00:08:47.039 --> 00:08:50.039 Speaking of continuous processes, let's move on to another big one, 189 00:08:50.279 --> 00:08:54.159 SQL injection or SQL what's the gist of this attack? 190 00:08:54.399 --> 00:08:57.960 Sequal injection targets a website's database, which is like the 191 00:08:57.960 --> 00:09:02.440 brain of many web applications. Hackers inject malicious sequel code 192 00:09:02.440 --> 00:09:05.200 into a website, aiming to access sensitive data or even 193 00:09:05.200 --> 00:09:06.919 take control of the entire database server. 194 00:09:07.039 --> 00:09:09.480 So instead of just changing what the user sees, they're 195 00:09:09.519 --> 00:09:12.519 going straight for the source, right bold move. How do 196 00:09:12.559 --> 00:09:13.399 they pull this off? 197 00:09:13.720 --> 00:09:17.360 It often involves exploiting vulnerabilities in web forms like a 198 00:09:17.399 --> 00:09:21.360 search field where users can input data. If the form 199 00:09:21.399 --> 00:09:25.200 isn't properly protected, a hacker can inject SQL code into 200 00:09:25.240 --> 00:09:29.200 their input. The book has a particularly gripping example of 201 00:09:29.240 --> 00:09:31.440 a major druple sequel vulnerability. 202 00:09:31.720 --> 00:09:34.159 Druple that's a popular content management system. 203 00:09:34.200 --> 00:09:35.120 Right it is? 204 00:09:35.159 --> 00:09:36.639 Tell me more about this vulnerability. 205 00:09:36.759 --> 00:09:39.919 In twenty fourteen, Drupele was hit with a critical vulnerability 206 00:09:39.960 --> 00:09:42.960 that stemmed from a single coding error in its core software. 207 00:09:43.600 --> 00:09:46.320 It was a simple mistake, but it allowed attackers to 208 00:09:46.360 --> 00:09:49.559 potentially gain complete control of millions of websites. 209 00:09:49.679 --> 00:09:50.080 Wow. 210 00:09:50.200 --> 00:09:53.480 They could steal user data, dephase websites, or even use 211 00:09:53.519 --> 00:09:55.639 the compromise sites to launch further attacks. 212 00:09:55.799 --> 00:09:58.279 Wow. That's a stark reminder of how a seemingly small 213 00:09:58.320 --> 00:10:02.159 coding mistake can have catastrophic consequences. It's like the butterfly 214 00:10:02.200 --> 00:10:05.240 effect in action, but with digital chaos instead of weather patterns. 215 00:10:05.440 --> 00:10:07.799 It also highlights the importance of staying up to date 216 00:10:07.799 --> 00:10:11.120 with security patches and following best practices for secure coding. 217 00:10:11.360 --> 00:10:15.240 Okay, let's keep this hacking train rolling. What about open redirects. 218 00:10:15.720 --> 00:10:18.240 The name sounds a little less sinister than some of 219 00:10:18.240 --> 00:10:19.360 the others we've talked about. 220 00:10:19.440 --> 00:10:20.120 Don't be fooled. 221 00:10:20.320 --> 00:10:22.559 Open redirects are all about exploiting trust. 222 00:10:22.919 --> 00:10:23.320 Okay. 223 00:10:23.440 --> 00:10:26.120 Imagine clicking a link on a website you trust, thinking 224 00:10:26.159 --> 00:10:29.440 you're going to a legitimate page, but instead you're redirected 225 00:10:29.440 --> 00:10:32.720 to a malicious website designed to steal your information. 226 00:10:32.600 --> 00:10:35.159 So you're basically being tricked into walking into a trap 227 00:10:35.240 --> 00:10:37.919 like those cartoons where the character follows a trail of 228 00:10:37.960 --> 00:10:40.799 candy right into a cage right. Are there any real 229 00:10:40.879 --> 00:10:43.320 world examples of open redirects in the book. 230 00:10:43.399 --> 00:10:45.679 Yes, a few involving Shopify. 231 00:10:46.000 --> 00:10:46.480 Oh. 232 00:10:46.519 --> 00:10:49.720 In one case, a hacker manipulated a theme installation page 233 00:10:49.879 --> 00:10:53.799 to redirect users to an external domain. Another example involved 234 00:10:53.840 --> 00:10:57.480 exploiting a redirect function to bypass Shopify security measures and 235 00:10:57.639 --> 00:11:01.000 access sensitive information. It just goes to show that you 236 00:11:01.039 --> 00:11:03.360 can't always trust what you see online, even on sites 237 00:11:03.440 --> 00:11:04.200 you think you're secure. 238 00:11:04.360 --> 00:11:07.039 That's a good reminder to be cautious and to always 239 00:11:07.120 --> 00:11:09.600 check the URL before clicking on a link, especially if 240 00:11:09.600 --> 00:11:10.559 it seems suspicious. 241 00:11:10.759 --> 00:11:15.200 Speaking of things that seem suspicious, let's talk about subdomain takeover. 242 00:11:16.279 --> 00:11:18.879 It's a bit like squatting on an abandoned property in 243 00:11:18.919 --> 00:11:19.759 the digital world. 244 00:11:20.080 --> 00:11:21.519 Intriguing Tell me more about this. 245 00:11:21.600 --> 00:11:26.279 Digital squatting attackers target subdomains that are pointing to unused 246 00:11:26.320 --> 00:11:30.759 third party services. They then register those subdomains with the 247 00:11:30.759 --> 00:11:34.840 third party service, effectively hijacking any traffic meant for the 248 00:11:34.879 --> 00:11:35.919 original sub domain. 249 00:11:36.200 --> 00:11:38.960 So You're basically claiming a forgotten corner of the Internet 250 00:11:39.000 --> 00:11:41.799 and using it for your own nefarious purposes. That's pretty clever, 251 00:11:41.879 --> 00:11:42.600 I have to admit. 252 00:11:42.840 --> 00:11:45.399 The book shares a couple of interesting examples, including one 253 00:11:45.440 --> 00:11:50.440 involving Ubiquidwitch, a networking technology company. Okay, a hacker took 254 00:11:50.440 --> 00:11:52.360 over one of their subdomains because it was pointing to 255 00:11:52.399 --> 00:11:55.039 an unused Amazon S three bucket. 256 00:11:55.240 --> 00:11:58.840 It's like finding a forgotten storage unit full of valuable stuff. 257 00:11:58.879 --> 00:12:02.279 So even seemingly in significant subdomains can be valuable targets 258 00:12:02.320 --> 00:12:04.639 for hackers. What other examples did the book have? 259 00:12:04.919 --> 00:12:07.919 There was another one involving scan dot me, a company 260 00:12:07.919 --> 00:12:09.039 acquired by Snapchat. 261 00:12:09.159 --> 00:12:09.519 Okay. 262 00:12:09.600 --> 00:12:12.320 The hacker claimed a subdomain that was pointing to an 263 00:12:12.399 --> 00:12:16.799 unused Zendesk account, potentially gaining access to sensitive support tickets. 264 00:12:16.960 --> 00:12:20.000 It's amazing how these seemingly simple oversights can lead to 265 00:12:20.039 --> 00:12:23.679 such serious security breaches. It's like leaving the keys to 266 00:12:23.720 --> 00:12:25.360 your house under the welcome map. 267 00:12:25.799 --> 00:12:29.279 The book also includes a fascinating high level example of 268 00:12:29.320 --> 00:12:33.399 a subdomain takeover exploit on Facebook. Oh Facebook, Yeah. The 269 00:12:33.399 --> 00:12:36.879 hacker Philly pair Wood, was able to hijack access tokens 270 00:12:37.120 --> 00:12:41.440 by targeting a misconfigured app. This exploit leveraged opethe, a 271 00:12:41.480 --> 00:12:45.240 protocol that allows users to grant third party apps access 272 00:12:45.240 --> 00:12:47.679 to their accounts without sharing their passwords. 273 00:12:48.039 --> 00:12:51.080 So by taking over the subdomain, the hacker could potentially 274 00:12:51.120 --> 00:12:54.840 intercept those access tokens and gain access to user accounts. 275 00:12:55.120 --> 00:12:57.639 That's wild. I'm starting to realize that security is like 276 00:12:57.639 --> 00:12:59.960 a game of chess where every move matters. 277 00:13:00.080 --> 00:13:01.320 That's a great way to think about it. 278 00:13:01.320 --> 00:13:03.919 It's a constant battle of wits between attackers and defenders, 279 00:13:04.039 --> 00:13:05.960 with each side trying to outmaneuver the other. 280 00:13:06.000 --> 00:13:09.879 All right, let's dive into another vulnerability XML external entity 281 00:13:10.000 --> 00:13:12.519 or XXC. That sounds like something out of a sci 282 00:13:12.559 --> 00:13:13.120 fi movie. 283 00:13:13.279 --> 00:13:16.360 It might sound complex, but the concept is pretty straightforward. 284 00:13:17.240 --> 00:13:21.120 XX vulnerabilities exploit how a website process is XML files. 285 00:13:21.879 --> 00:13:24.679 XML is a way to structure data, and it allows 286 00:13:24.679 --> 00:13:28.720 for the inclusion of external entities. Okay, hackers can craft 287 00:13:28.759 --> 00:13:33.240 malicious XML files that reference these external entities, potentially accessing 288 00:13:33.279 --> 00:13:36.200 sensitive data or even executing code on the server. 289 00:13:36.519 --> 00:13:38.720 So it's like sneaking a secret message within a seemingly 290 00:13:38.759 --> 00:13:40.639 harmless document. Very sneaky. 291 00:13:41.240 --> 00:13:44.039 The book uses a great analogy to illustrate this. A 292 00:13:44.159 --> 00:13:47.240 job board that allows users to upload their resumes in 293 00:13:47.360 --> 00:13:50.600 XML format. Okay, a hacker could create a resume that 294 00:13:50.639 --> 00:13:54.759 includes an external entity referencing the server's password file. Oh, 295 00:13:54.840 --> 00:13:57.879 if the job board system isn't properly protected, it could 296 00:13:57.960 --> 00:13:59.320 expose that sensitive data. 297 00:13:59.360 --> 00:14:02.200 That's a clever way to exploit a seemingly innocuous feature. 298 00:14:02.279 --> 00:14:04.519 It's like hiding a trojan horse inside a gift basket. 299 00:14:05.159 --> 00:14:07.799 What other examples of XX exploits does the book mention? 300 00:14:07.879 --> 00:14:09.840 Well, it's recky. Example involves the Google toolbar. 301 00:14:09.919 --> 00:14:10.679 Google Toolbar. 302 00:14:10.840 --> 00:14:13.919 Yeah, hackers were able to read sensitive server files by 303 00:14:13.919 --> 00:14:17.720 exploiting a vulnerability in the toolbar's button gallery, which allowed 304 00:14:17.720 --> 00:14:21.480 developers to upload XML files containing button metadata. 305 00:14:22.039 --> 00:14:25.480 Wow, even Google is an immune to these attacks. It 306 00:14:25.519 --> 00:14:28.120 seems like no matter how big or sophisticated a company is, 307 00:14:28.159 --> 00:14:31.000 there's always the potential for vulnerabilities. It makes you wonder 308 00:14:31.039 --> 00:14:33.360 what's the most dangerous vulnerability out there? 309 00:14:33.440 --> 00:14:36.639 Well, one that often comes with severe consequences is remote 310 00:14:36.679 --> 00:14:40.799 code execution. Okay, as the name suggests, it allows attackers 311 00:14:40.799 --> 00:14:43.799 to inject code that's then executed by the target server. 312 00:14:44.039 --> 00:14:46.360 So it's like planting a bomb that detonates right at 313 00:14:46.360 --> 00:14:49.000 the heart of the system. That sounds terrifying it can be. 314 00:14:49.399 --> 00:14:52.519 The book provides a chilling example involving a vulnerability in 315 00:14:52.559 --> 00:14:56.000 image Magic, a widely used image processing library. 316 00:14:56.080 --> 00:14:58.080 Image Magic I've heard of that it's used all over 317 00:14:58.080 --> 00:14:59.440 the Internet, right, it's. 318 00:14:59.360 --> 00:15:03.840 Exactly Countless websites and applications use it to handle image uploads, resizing, 319 00:15:04.080 --> 00:15:07.600 and other image related tasks. The vulnerability allowed attackers to 320 00:15:07.679 --> 00:15:10.879 inject malicious code into image files, which would then be 321 00:15:10.919 --> 00:15:15.080 executed when the server process those images. This vulnerability was 322 00:15:15.080 --> 00:15:17.600 widely exploited, and it shows how a flaw and a 323 00:15:17.639 --> 00:15:20.879 commonly used software component can have a ripple effect across 324 00:15:20.879 --> 00:15:21.879 the entire Internet. 325 00:15:22.120 --> 00:15:24.799 It's a stark reminder that security is only as strong 326 00:15:24.840 --> 00:15:28.320 as its weakest link. What's the specific example mentioned in 327 00:15:28.360 --> 00:15:28.799 the book. 328 00:15:28.960 --> 00:15:31.279 The book tells the story of a hacker named Ben 329 00:15:31.320 --> 00:15:36.000 Sedecor who exploited this image Magic vulnerability to gain remote 330 00:15:36.000 --> 00:15:39.000 code execution on Polyvor, a fashion website. 331 00:15:39.039 --> 00:15:39.879 Oh Polyvor. 332 00:15:39.960 --> 00:15:40.120 Yeah. 333 00:15:40.159 --> 00:15:43.039 He crafted a malicious image file that, when processed by 334 00:15:43.039 --> 00:15:45.720 the server, sent a confirmation message back to his own server. 335 00:15:46.000 --> 00:15:48.600 It's a fascinating glimpse into how these exploits work in 336 00:15:48.600 --> 00:15:49.320 the real world. 337 00:15:49.480 --> 00:15:52.480 So even something as seemingly harmless as uploading an image 338 00:15:52.519 --> 00:15:55.840 can be a security risk if the underlying software is vulnerable. 339 00:15:56.360 --> 00:15:59.399 It's a reminder to always be vigilant, both as developers 340 00:15:59.399 --> 00:16:00.120 and as users. 341 00:16:00.159 --> 00:16:02.080 Absolute security is everyone's responsibility. 342 00:16:02.200 --> 00:16:05.879 Okay, let's talk about another type of vulnerability, template injection. 343 00:16:06.559 --> 00:16:07.960 What can you tell me about this one. 344 00:16:08.200 --> 00:16:12.240 Templet injection exploits vulnerabilities in template engines, which are software 345 00:16:12.240 --> 00:16:16.000 components that dynamically generate web pages. Okay, imagine you have 346 00:16:16.039 --> 00:16:19.159 a website that displays user profiles, and each profile is 347 00:16:19.200 --> 00:16:23.559 generated using a template. An attacker might inject malicious code 348 00:16:23.639 --> 00:16:26.639 into that template, which would then be executed on the server, 349 00:16:27.000 --> 00:16:30.519 potentially giving them access to sensitive data or even control 350 00:16:30.519 --> 00:16:31.440 of the server itself. 351 00:16:31.720 --> 00:16:35.039 So it's like hijacking the blueprint for a building and 352 00:16:35.080 --> 00:16:38.600 making subtle changes that could compromise the entire structure. That's 353 00:16:38.639 --> 00:16:39.559 a clever analogy. 354 00:16:39.679 --> 00:16:40.159 I like that. 355 00:16:40.320 --> 00:16:43.759 There are two main types of template injection, server side 356 00:16:43.919 --> 00:16:48.080 SSTI and client side CSTI. As the name implies, happens 357 00:16:48.080 --> 00:16:50.919 on the server, while CSTI occurs on the client side 358 00:16:50.960 --> 00:16:55.200 in the user's browser. SSTI is generally considered more serious 359 00:16:55.240 --> 00:16:58.080 as it can potentially compromise the server, while CSTI is 360 00:16:58.120 --> 00:16:59.240 more limited in scope. 361 00:16:59.360 --> 00:17:01.799 So it's like the difference between poisoning the water supply 362 00:17:01.840 --> 00:17:05.559 at the source versus contaminating a single glass. What are 363 00:17:05.559 --> 00:17:08.000 some examples of SSTI vulnerabilities? 364 00:17:08.279 --> 00:17:11.839 The book mentions exploiting a vulnerability in flask, a popular 365 00:17:11.839 --> 00:17:16.720 Python web framework, and its default template engine gingitoo. By 366 00:17:16.759 --> 00:17:20.240 injecting malicious code into gingitoo templates, hackers were able to 367 00:17:20.240 --> 00:17:23.119 gain remote code execution on vulnerable servers. 368 00:17:23.200 --> 00:17:26.519 So this isn't just limited to Php and other web languages. 369 00:17:26.720 --> 00:17:27.200 Not at all. 370 00:17:27.599 --> 00:17:30.799 Template injection vulnerabilities can exist in any web framework that 371 00:17:30.880 --> 00:17:34.000 uses a template engine, regardless of the programming language. Interesting, 372 00:17:34.079 --> 00:17:36.920 it's all about finding those weak points where an attacker 373 00:17:36.960 --> 00:17:37.960 can inject their code. 374 00:17:38.079 --> 00:17:40.880 Speaking of weak points, what about CSDI? Does the book 375 00:17:40.920 --> 00:17:41.880 have any examples of that? 376 00:17:42.160 --> 00:17:42.759 Yes, it does. 377 00:17:43.119 --> 00:17:47.720 One example involves Uber's developer documentation website. The hacker James 378 00:17:47.759 --> 00:17:52.400 Kettle exploded a vulnerability and Angular js, a popular JavaScript framework, 379 00:17:52.599 --> 00:17:56.160 to inject malicious code that escaped the Angular sandbox and 380 00:17:56.319 --> 00:18:00.000 executed arbitrary JavaScript. This allowed him to hijack developer case 381 00:18:00.319 --> 00:18:01.480 and associated apps. 382 00:18:01.599 --> 00:18:04.400 So even client side frameworks like Angular JS can be 383 00:18:04.480 --> 00:18:07.880 vulnerable to template injection. It's like realizing that even the 384 00:18:07.880 --> 00:18:10.799 seemingly harmless decorations on a gingerbread house can be used 385 00:18:10.799 --> 00:18:11.599 to break in. 386 00:18:11.839 --> 00:18:14.960 It emphasizes that security needs to be considered at every 387 00:18:15.039 --> 00:18:17.400 layer of a web application, from the server to the client. 388 00:18:17.559 --> 00:18:19.799 All right, we've covered a lot of ground. Let's wrap 389 00:18:19.839 --> 00:18:23.920 things up with one final vulnerability, server side request forgery 390 00:18:24.640 --> 00:18:27.119 or SSRF. What's the lowdown on this one. 391 00:18:27.440 --> 00:18:31.799 SSRF vulnerabilities trick a server into making requests to other 392 00:18:31.839 --> 00:18:36.079 systems on the attacker's behalf. It's like using someone else's 393 00:18:36.079 --> 00:18:38.200 phone to make a call without them knowing. 394 00:18:38.640 --> 00:18:41.759 So you're leveraging the service trust and authority to make 395 00:18:41.799 --> 00:18:44.279 requests you wouldn't be able to make directly. That sounds 396 00:18:44.279 --> 00:18:47.160 pretty sneaky. Does the book have any real world examples 397 00:18:47.160 --> 00:18:47.400 of this? 398 00:18:47.640 --> 00:18:48.119 It does. 399 00:18:48.400 --> 00:18:53.200 One example involves essay and esports platform. The vulnerability allowed 400 00:18:53.240 --> 00:18:57.160 attackers to use essay servers to make requests to internal systems, 401 00:18:57.200 --> 00:19:00.880