WEBVTT 1 00:00:00.040 --> 00:00:02.520 All right, let's dive right in. Today we're going to 2 00:00:02.560 --> 00:00:06.360 be getting into secure programming, specifically how to write code 3 00:00:06.440 --> 00:00:11.519 that can withstand even the most persistent attacker. We're looking 4 00:00:11.519 --> 00:00:14.720 at secure programming with static analysis. It's a book by 5 00:00:14.720 --> 00:00:16.399 Brian Chess and Jacob West. 6 00:00:16.920 --> 00:00:19.199 Yeah, it's a really interesting read. It really gets into 7 00:00:19.480 --> 00:00:22.079 how to build security and right from the beginning instead 8 00:00:22.079 --> 00:00:24.000 of just you know, trying to patch things up later. 9 00:00:24.199 --> 00:00:26.440 Yeah. They really make a good point about secure code 10 00:00:26.519 --> 00:00:28.760 not being something you just like tack on at the end. 11 00:00:29.280 --> 00:00:31.320 It's it's really a whole different way of thinking. 12 00:00:31.359 --> 00:00:33.920 Absolutely. Yeah. And one of the uh, I think one 13 00:00:33.920 --> 00:00:36.200 of the key takeaways from the book is is this 14 00:00:36.320 --> 00:00:37.840 idea of static analysis. 15 00:00:38.439 --> 00:00:41.679 So for folks listening, you can think of static analysis 16 00:00:41.679 --> 00:00:45.119 like having a super smart code reviewer, like always looking 17 00:00:45.200 --> 00:00:47.560 over your shoulder. You know. It's it's really good at 18 00:00:47.640 --> 00:00:50.600 catching those little errors that sometimes even you know, really 19 00:00:50.679 --> 00:00:55.560 experienced programmers miss. But what makes these tools so effective, 20 00:00:55.600 --> 00:00:58.320 Like especially when we're talking about languages like C and Java, 21 00:00:58.840 --> 00:00:59.960 well both SEE and Java. 22 00:01:00.240 --> 00:01:03.119 They give developers a lot of power and flexibility, which 23 00:01:03.159 --> 00:01:05.640 is great, but you know, it's kind of like the 24 00:01:05.640 --> 00:01:09.280 old spider man quote. With great power comes great responsibility, 25 00:01:10.000 --> 00:01:13.319 especially when it comes to how memory is managed. If 26 00:01:13.319 --> 00:01:15.640 you make mistakes in these areas, you can end up 27 00:01:15.680 --> 00:01:20.239 with some pretty bad vulnerabilities, like the dreaded buffer overflow. 28 00:01:20.439 --> 00:01:23.560 Ooh, buffer overflows that sounds that sounds scary. 29 00:01:23.680 --> 00:01:26.200 They can be. Yeah. Imagine you have a container and 30 00:01:26.239 --> 00:01:29.519 it's designed to only hold a certain amount of data. Well, 31 00:01:29.680 --> 00:01:32.400 a buffer overflow happens when you try to put more 32 00:01:32.480 --> 00:01:33.400 data in than it. 33 00:01:33.359 --> 00:01:35.920 Can handle, like trying to fit ten pounds of potatoes 34 00:01:35.959 --> 00:01:37.079 into a five pound sack. 35 00:01:37.280 --> 00:01:41.319 Exactly. Yeah, But instead of potatoes spilling out everywhere, you 36 00:01:41.439 --> 00:01:44.200 have data that's spilling over into other parts of the memory. 37 00:01:44.519 --> 00:01:46.719 And this is where it gets really interesting. Especially you know, 38 00:01:46.719 --> 00:01:49.680 if you're thinking like an attacker, they can actually use 39 00:01:49.719 --> 00:01:53.239 this overflow to overwrite important parts of a program's memory. 40 00:01:53.319 --> 00:01:55.239 Oh okay, I see how this could be bad. 41 00:01:55.640 --> 00:01:58.079 It can lead to all sorts of things, crashing a program, 42 00:01:58.200 --> 00:02:01.719 corrupting data. You can even potentially hijack the whole application 43 00:02:01.760 --> 00:02:03.159 to run some malicious code. 44 00:02:03.400 --> 00:02:06.200 Oh yikes, that sounds like a real problem. 45 00:02:06.319 --> 00:02:09.680 It can be, and Chessman Wes used this really good 46 00:02:09.719 --> 00:02:12.599 example in the book from open ssh. Open Ssh is 47 00:02:12.719 --> 00:02:16.319 used for you know, secure remote access to servers, so 48 00:02:17.280 --> 00:02:19.080 you can imagine what would happen if someone were to 49 00:02:19.120 --> 00:02:22.240 find and exploit a buffer overflow in that software. 50 00:02:22.319 --> 00:02:24.319 Yeah, definitely not good, not good at all. 51 00:02:24.560 --> 00:02:26.879 And this's just one example. They also talk about some 52 00:02:26.960 --> 00:02:30.000 cases with send mail, which is another really widely used 53 00:02:30.039 --> 00:02:33.280 piece of software, and these examples show how even you know, 54 00:02:33.319 --> 00:02:35.960 what might seem like a simple error can have some 55 00:02:35.960 --> 00:02:37.280 pretty serious consequences. 56 00:02:37.439 --> 00:02:40.759 So it's really not just about writing code that works, 57 00:02:40.800 --> 00:02:43.199 but about writing code that works securely. 58 00:02:42.919 --> 00:02:45.840 Right exactly, And that's where static analysis really comes in. 59 00:02:46.080 --> 00:02:49.960 Static analysis tools can actually analyze your code and find 60 00:02:49.960 --> 00:02:54.240 these potential buffer overflows and other vulnerabilities before they become 61 00:02:54.280 --> 00:02:55.400 a real problem in the wild. 62 00:02:55.680 --> 00:02:59.960 It's almost like having a security guard, you know, watching 63 00:03:00.080 --> 00:03:01.800 your code and making sure no one can sneak in 64 00:03:01.840 --> 00:03:04.840 through the back door. But Chess and West don't just 65 00:03:04.840 --> 00:03:07.159 focus on buffer overflows in the book, right. 66 00:03:07.120 --> 00:03:10.560 Right, Yeah, They actually spend a lot of time talking 67 00:03:10.639 --> 00:03:15.319 about web applications, which, you know, that's an environment where 68 00:03:15.360 --> 00:03:19.199 you're constantly having to deal with user input and user 69 00:03:19.240 --> 00:03:22.199 input well, let's be honest, it can often be you know, 70 00:03:22.280 --> 00:03:23.400 a bit of a security headache. 71 00:03:23.439 --> 00:03:27.319 Oh yeah, you're right. User input that's unpredictable exactly. 72 00:03:27.360 --> 00:03:29.000 You never know what you're going to get, and that's 73 00:03:29.039 --> 00:03:33.159 why it's super important to validate and sanitize that input 74 00:03:33.199 --> 00:03:35.919 before you do anything with it. If you don't, you 75 00:03:35.919 --> 00:03:38.199 could be opening yourself up to well a whole host 76 00:03:38.199 --> 00:03:41.199 of vulnerabilities like cross site scripting or EXSS. 77 00:03:41.240 --> 00:03:44.759 Okay EXSS. So I've heard of this before, but I've 78 00:03:44.800 --> 00:03:47.479 never really understood exactly how it works. Is this something 79 00:03:47.520 --> 00:03:50.759 that you know, the average person listening should be worried about? 80 00:03:50.919 --> 00:03:56.120 Oh yeah, definitely. So imagine this scenario. An attacker. Let's 81 00:03:56.159 --> 00:03:59.560 say they inject some you know, bad JavaScript code into 82 00:03:59.719 --> 00:04:03.080 a comment field on a website. Now, if that website 83 00:04:03.120 --> 00:04:06.759 isn't properly handling the user input, you know, making sure 84 00:04:06.840 --> 00:04:10.400 things are encoded properly, that malicious code could actually be 85 00:04:10.439 --> 00:04:13.080 executed in the browser of you know, anyone who visits 86 00:04:13.120 --> 00:04:13.599 that page. 87 00:04:13.759 --> 00:04:15.840 Oh so, it's like like planting a little bomb that 88 00:04:15.879 --> 00:04:17.480 goes off when someone comes across it. 89 00:04:17.480 --> 00:04:19.879 It's a good analogy. Yeah, and the consequences can be 90 00:04:19.879 --> 00:04:22.480 pretty bad. You can steal cookies, you can hijack accounts. 91 00:04:22.639 --> 00:04:26.959 You can even redirect users to other malicious websites. 92 00:04:27.120 --> 00:04:30.800 Oh, okay, EXSS is definitely something to watch out for. 93 00:04:30.519 --> 00:04:33.319 For sure, Jess and West. They actually use a really 94 00:04:33.319 --> 00:04:36.079 fascinating case study in the book about MySpace. So my 95 00:04:36.240 --> 00:04:39.360 Space tried to block these EXSS vulnerabilities, but you know what, 96 00:04:39.800 --> 00:04:42.600 clever attackers kept finding ways around their defenses. 97 00:04:42.920 --> 00:04:45.360 That's kind of scary, this cat and mouse game between 98 00:04:45.399 --> 00:04:46.600 developers and attackers. 99 00:04:46.879 --> 00:04:48.839 Yeah, it really shows why you need to have this 100 00:04:48.920 --> 00:04:51.920 proactive approach to security. You always have to be thinking 101 00:04:51.959 --> 00:04:54.120 like an attacker, asking yourself, you know, how could this 102 00:04:54.199 --> 00:04:57.839 be misused? And that's where static analysis tools, you know, 103 00:04:57.920 --> 00:04:59.800 they can be a real life saver. They can help 104 00:04:59.800 --> 00:05:03.360 you find those potential excess as vulnerabilities before they become 105 00:05:03.360 --> 00:05:04.000 a real problem. 106 00:05:04.079 --> 00:05:07.680 So it's really about catching these problems early on, before 107 00:05:07.720 --> 00:05:08.920 they can do any damage. 108 00:05:09.079 --> 00:05:13.040 Exactly. Yeah. But let's shift gears for a minute and 109 00:05:13.040 --> 00:05:16.319 talk about something that might seem a little less exciting. 110 00:05:16.480 --> 00:05:18.720 Let's talk about passwords and secrets. 111 00:05:18.839 --> 00:05:22.560 Ah, passwords, those little strings of characters that cause so 112 00:05:22.639 --> 00:05:23.439 many problems. 113 00:05:23.439 --> 00:05:26.480 They really can. Yeah. Yeah, And one of the biggest 114 00:05:26.519 --> 00:05:30.759 mistakes developers make is hard coding passwords right into their code. 115 00:05:31.079 --> 00:05:33.240 Okay, yeah, I can see how that wouldn't be good. 116 00:05:33.399 --> 00:05:35.279 Yeah, it's like leaving your house key under the doormat. 117 00:05:35.519 --> 00:05:38.279 If someone can access your code, well they've got your passwords. 118 00:05:38.279 --> 00:05:40.680 It's that easy. And actually, Chess and West highlight this 119 00:05:40.720 --> 00:05:43.759 real world example in the book, a system that was 120 00:05:43.759 --> 00:05:46.959 written in Java that got this wrong. Their passwords were 121 00:05:46.959 --> 00:05:48.600 exposed for anyone to see. 122 00:05:48.759 --> 00:05:51.120 Okay, yeah, that's definitely something to avoid. So what's the 123 00:05:52.040 --> 00:05:54.600 right way to handle passwords? 124 00:05:54.959 --> 00:05:57.519 Well, there's some best practices, but that the key is 125 00:05:57.800 --> 00:06:00.920 to never store passwords directly in your code. Instead, you 126 00:06:00.920 --> 00:06:04.720 should use secure hashing algorithms, so, you know, store passwords 127 00:06:04.920 --> 00:06:08.360 in a way that makes them almost impossible to reverse engineer. 128 00:06:08.480 --> 00:06:11.439 Hm hmm okay, so no ah, head and keys under 129 00:06:11.480 --> 00:06:15.000 the doormat, got it? What about what about systems that 130 00:06:15.040 --> 00:06:17.639 already have a lot of you know, power and access. 131 00:06:18.000 --> 00:06:20.040 That's a really good point. And Chess and West they 132 00:06:20.360 --> 00:06:24.360 dedicate a whole chapter to privileged programs. These are programs 133 00:06:24.399 --> 00:06:27.600 that you know, have special access, like the root user 134 00:06:27.639 --> 00:06:31.800 on Linux. If these programs get compromised, well, the damage 135 00:06:31.800 --> 00:06:32.959 can be pretty significant. 136 00:06:33.000 --> 00:06:35.199 It's like giving someone, you know, the master key to 137 00:06:35.240 --> 00:06:35.839 your whole house. 138 00:06:36.199 --> 00:06:38.920 Exactly. Yeah, that's why the principle of these privilege is 139 00:06:38.959 --> 00:06:42.519 so important. You only want to give programs the access 140 00:06:42.560 --> 00:06:45.920 that they absolutely need, nothing more. They have some great 141 00:06:45.920 --> 00:06:50.800 examples in the book about about how dropping privileges, like 142 00:06:50.959 --> 00:06:54.000 you know, running program as a less privileged user can 143 00:06:54.079 --> 00:06:56.560 help to limit the damage if an attack does happen. 144 00:06:56.680 --> 00:06:59.040 Oh, that's that's interesting. It's kind of like like having 145 00:06:59.079 --> 00:07:02.240 different keys for different rooms in your house. Like I 146 00:07:02.240 --> 00:07:05.279 wouldn't give you a guest the key to your safe, 147 00:07:05.279 --> 00:07:06.000 would you, right? 148 00:07:06.079 --> 00:07:09.160 Exactly. It's all about limiting, you know, the potential damage. 149 00:07:09.199 --> 00:07:11.439 And this applies to software too. When you limit the 150 00:07:11.480 --> 00:07:14.199 privileges of your programs, you make it a lot harder 151 00:07:14.199 --> 00:07:16.360 for an attacker to get access to your whole system. 152 00:07:16.759 --> 00:07:20.160 So we've talked about buffer overflows, We've talked about EXSS, 153 00:07:20.279 --> 00:07:23.759 we've talked about passwords, the importance of limiting privileges. Seems 154 00:07:23.759 --> 00:07:25.879 like there's a lot to think about when it comes 155 00:07:25.920 --> 00:07:27.399 to writing secure code. 156 00:07:27.920 --> 00:07:31.160 There is. Yeah, But the good news is static analysis 157 00:07:31.199 --> 00:07:34.319 tools can help with all of this. They can, you know, 158 00:07:34.839 --> 00:07:37.519 analyze your code for these vulnerabilities and even give you 159 00:07:37.560 --> 00:07:38.920 some advice on how to fix them. 160 00:07:39.000 --> 00:07:41.720 So these tools aren't just about finding the problems. They 161 00:07:41.759 --> 00:07:43.079 actually help you solve. 162 00:07:42.879 --> 00:07:46.079 Them too, exactly. They're like a security consultant built right 163 00:07:46.120 --> 00:07:47.519 into your development process. 164 00:07:47.600 --> 00:07:48.639 Okay, that makes sense. 165 00:07:48.680 --> 00:07:50.279 And then the next part of our deep dive, we're 166 00:07:50.279 --> 00:07:52.040 going to actually see some of these tools in action. 167 00:07:52.439 --> 00:07:53.000 That's good. 168 00:07:53.199 --> 00:07:56.800 Well, we'll walk through how these tools actually work. You know, 169 00:07:56.839 --> 00:08:00.639 how they build models of your code, trace data flow, 170 00:08:01.279 --> 00:08:04.920 and use rules to find those those tricky problems. 171 00:08:05.160 --> 00:08:06.519 Okay, yeah, I'm excited for that. 172 00:08:06.800 --> 00:08:10.399 And you know it's it's not magic, but it's it's 173 00:08:10.399 --> 00:08:10.959 pretty close. 174 00:08:11.160 --> 00:08:12.519 It's pretty cool, it really is. 175 00:08:13.199 --> 00:08:15.720 Okay. So we've talked a lot about, you know, why 176 00:08:15.759 --> 00:08:19.160 secure programming is so important, but now let's get into 177 00:08:19.199 --> 00:08:22.879 the how. How can we actually use these static analysis 178 00:08:22.879 --> 00:08:26.000 tools to find those vulnerabilities that might be hiding in 179 00:08:26.040 --> 00:08:26.480 our code. 180 00:08:26.600 --> 00:08:29.160 Yeah, let's let's get into it. I'm ready to put 181 00:08:29.160 --> 00:08:31.319 on my detective hat and start hunting for bugs. 182 00:08:31.360 --> 00:08:34.200 All right. Well, the first thing to remember is static 183 00:08:34.200 --> 00:08:37.559 analysis tools they're not magic. You know, they need a 184 00:08:37.559 --> 00:08:39.519 little bit of help to know what to look for, 185 00:08:39.720 --> 00:08:41.279 and that's where rules come in. 186 00:08:41.639 --> 00:08:44.399 Rules like a set of instructions that tell the tool 187 00:08:44.679 --> 00:08:47.120 you know, hey, this is a potential problem exactly. 188 00:08:47.399 --> 00:08:49.120 And the cool thing about these rules is you can 189 00:08:49.159 --> 00:08:52.039 customize them so you know, they fit your your specific 190 00:08:52.120 --> 00:08:54.559 needs how you code. You can define rules to make 191 00:08:54.559 --> 00:08:58.720 sure everyone's following coding standards. You can identify common security problems, 192 00:08:58.960 --> 00:09:01.240 and you can even model how how you know external 193 00:09:01.279 --> 00:09:03.039 libraries behave Oh. 194 00:09:02.919 --> 00:09:05.679 Okay, so it's not just like one size fits all. 195 00:09:05.679 --> 00:09:08.559 You can actually make the analysis specific to your project 196 00:09:08.559 --> 00:09:09.879 and environment exactly. 197 00:09:10.279 --> 00:09:13.480 And one of the one of the most powerful and 198 00:09:13.559 --> 00:09:17.360 common types of rules is what we call taint propagation rules. 199 00:09:17.919 --> 00:09:21.360 Taint propagation Okay, now that that sounds interesting. What's that 200 00:09:21.399 --> 00:09:21.840 all about? 201 00:09:22.120 --> 00:09:24.320 So imagine you're you're tracking a drop of ink as 202 00:09:24.360 --> 00:09:27.840 it spreads through water. Yeah, taint propagation rules. They work 203 00:09:27.840 --> 00:09:32.200 in a similar way. They let you track how potentially 204 00:09:32.320 --> 00:09:36.240 dangerous data or like tainted data moves through your program. 205 00:09:36.480 --> 00:09:39.960 Okay, So so if you have you know, user input 206 00:09:40.000 --> 00:09:41.759 coming into your program, which we know can be a 207 00:09:41.759 --> 00:09:45.200 bit unpredictable, you can like tag it as tainted and 208 00:09:45.240 --> 00:09:47.000 then see where it goes exactly. 209 00:09:47.039 --> 00:09:50.720 And if that if that tainted data ends up reaching 210 00:09:50.799 --> 00:09:53.559 you know, some sensitive operation like writing to a file 211 00:09:53.639 --> 00:09:57.000 or executing a system command. Then the tool can be like, hey, 212 00:09:57.080 --> 00:09:59.320 wait a minute, this this might be a problem. 213 00:09:59.480 --> 00:10:02.720 So, like, if you have tainted data that ends up 214 00:10:02.720 --> 00:10:07.080 in a SQL query without being checked properly, that would 215 00:10:07.080 --> 00:10:08.639 be a red flag for SQL injection. 216 00:10:08.759 --> 00:10:11.519 Right, you got it, And that's just one example. Tained 217 00:10:11.519 --> 00:10:14.399 propagation rules can be used to find a ton of 218 00:10:14.399 --> 00:10:19.960 different vulnerabilities cross sight scripting, command injection, path traversal attacks, 219 00:10:20.000 --> 00:10:20.480 you name it. 220 00:10:20.600 --> 00:10:23.519 Wow, So it's almost like you have a security camera 221 00:10:23.720 --> 00:10:26.240 that's following that data around making sure it doesn't end 222 00:10:26.320 --> 00:10:27.600 up somewhere it's not supposed to be. 223 00:10:27.679 --> 00:10:29.320 Yeah, that's a great way to put it. But tained 224 00:10:29.360 --> 00:10:31.679 propagation rules there's just one piece of the puzzle. You 225 00:10:31.720 --> 00:10:35.480 also have structural rules. These rules they look at the 226 00:10:35.919 --> 00:10:38.080 overall structure of your code, so they're looking. 227 00:10:37.879 --> 00:10:40.799 For patterns that could indicate a vulnerability even if there's 228 00:10:40.919 --> 00:10:44.320 no tainted data involved exactly. 229 00:10:44.559 --> 00:10:48.000 So, for example, a structural rule might flag the use 230 00:10:48.039 --> 00:10:54.039 of like a dangerous function like strecb in C that 231 00:10:54.039 --> 00:10:57.799 function is notorious for buffer overflows, or you know, it 232 00:10:57.879 --> 00:11:00.000 might check to see if you have empty catch blocks 233 00:11:00.120 --> 00:11:04.080 in Java, which can actually hide errors and lead to vulnerabilities. 234 00:11:04.200 --> 00:11:06.799 So it's like having a building inspector come in and 235 00:11:06.840 --> 00:11:08.679 make sure the foundation of your code is solid. 236 00:11:08.720 --> 00:11:12.159 Oh like that analogy, And then you have configuration rules. 237 00:11:12.159 --> 00:11:14.519 Those are used to model, you know, how your environment 238 00:11:14.559 --> 00:11:16.320 behaves and how external systems work. 239 00:11:16.399 --> 00:11:19.879 Okay, so if you're using a specific framework or library, 240 00:11:20.200 --> 00:11:23.480 you can actually create rules that define how it interacts 241 00:11:23.519 --> 00:11:25.279 with your code and what kind of security risks there 242 00:11:25.360 --> 00:11:26.279 might be precisely. 243 00:11:26.799 --> 00:11:28.600 And that helps to make sure that the results you 244 00:11:28.639 --> 00:11:31.960 get from your static analysis are tailored to your specific 245 00:11:32.039 --> 00:11:33.440 environment and how you code things. 246 00:11:33.679 --> 00:11:35.919 So we've got all these different kinds of rules working 247 00:11:35.960 --> 00:11:42.679 together to give us this comprehensive security analysis. What happens next, Like, 248 00:11:42.759 --> 00:11:45.559 once the tool has analyzed all the code, what do 249 00:11:45.600 --> 00:11:46.080 we see? 250 00:11:46.159 --> 00:11:50.120 Well, the tool will generate a report, and that report 251 00:11:50.200 --> 00:11:54.480 highlights any potential vulnerabilities. It's dound. But let's be honest, 252 00:11:54.679 --> 00:11:58.240 sometimes these reports can be a bit overwhelming, especially for 253 00:11:58.320 --> 00:11:59.600 you know, for larger projects. 254 00:12:00.080 --> 00:12:02.799 Yeah, I can imagine. It's like trying to drink from 255 00:12:02.799 --> 00:12:05.720 a fire hose. How do you even start to make 256 00:12:05.759 --> 00:12:07.480 sense of it all and figure out what to focus 257 00:12:07.480 --> 00:12:07.960 on first. 258 00:12:08.480 --> 00:12:11.120 That's where a really good static analysis tool, that's where 259 00:12:11.120 --> 00:12:13.559 it really shines. A good tool, it'll give you clear, 260 00:12:13.639 --> 00:12:16.759 concise reports, it'll highlight the most critical vulnerabilities, and it 261 00:12:16.759 --> 00:12:20.200 will help you understand you know, how bad each finding 262 00:12:20.320 --> 00:12:22.159 is and what kind of impact it could have. 263 00:12:22.320 --> 00:12:25.320 So it's not just about giving you a list of problems. 264 00:12:25.360 --> 00:12:29.320 It's about giving you some context and some actionable insights exactly. 265 00:12:29.639 --> 00:12:33.200 The tool should help you understand why a particular piece 266 00:12:33.200 --> 00:12:35.799 of code is being flagged. You know, how could it 267 00:12:35.840 --> 00:12:38.679 be exploited, what steps can you take to fix it. 268 00:12:38.679 --> 00:12:42.080 It might even suggest like specific code changes or best 269 00:12:42.120 --> 00:12:43.120 practices to follow. 270 00:12:43.519 --> 00:12:47.519 So it's almost like having a security expert sitting next 271 00:12:47.559 --> 00:12:50.559 to you, walking you through the results and helping you 272 00:12:50.639 --> 00:12:51.879 understand what to do next. 273 00:12:52.360 --> 00:12:54.240 Yeah, that's a great way to think about it. And 274 00:12:54.240 --> 00:12:57.320 the more you use these static analysis tools, the better 275 00:12:57.399 --> 00:13:01.000 you get at, you know, spotting and fixing potential problems 276 00:13:01.039 --> 00:13:03.200 early on in the development process, which can save you 277 00:13:03.240 --> 00:13:04.879 a lot of time and headaches later down the road. 278 00:13:05.240 --> 00:13:08.480 Okay, so let's say we've run our analysis, we've got 279 00:13:08.519 --> 00:13:10.960 our report, and we're ready to start, you know, digging 280 00:13:10.960 --> 00:13:13.360 in and looking at the findings. What what are some 281 00:13:13.440 --> 00:13:15.440 things we should be looking for? What are the key things? 282 00:13:15.519 --> 00:13:17.399 Okay, well, one of the most important things is to 283 00:13:17.480 --> 00:13:22.440 understand how serious each vulnerability is, because you know, not 284 00:13:22.559 --> 00:13:25.440 all vulnerabilities are created equal. Some are a lot riskier 285 00:13:25.480 --> 00:13:25.879 than others. 286 00:13:26.279 --> 00:13:28.759 Yeah, that makes sense. Like a buffer overflow that could 287 00:13:29.159 --> 00:13:31.799 you know, let someone execute code remotely. That's a much 288 00:13:31.840 --> 00:13:36.159 bigger dale than you know, some minor coding style issue. 289 00:13:36.360 --> 00:13:39.000 So how do how do we prioritize these findings? 290 00:13:39.600 --> 00:13:44.120 Most tools use a bunch of factors to assess the severity, 291 00:13:44.320 --> 00:13:46.639 you know, like what kind of vulnerability is it, what 292 00:13:46.679 --> 00:13:49.320 could the impact be, and how likely is it that 293 00:13:49.360 --> 00:13:52.480 someone could actually exploit it. They usually assign each finding 294 00:13:52.840 --> 00:13:55.440 a level like critical, high, medium, or low. 295 00:13:55.679 --> 00:13:58.000 Okay, so you should probably focus on those critical and 296 00:13:58.080 --> 00:13:59.399 high ones first, right. 297 00:13:59.320 --> 00:14:03.240 Absolutely, But you also need to understand the context of 298 00:14:03.279 --> 00:14:07.200 each vulnerability. Like a low severity vulnerability in a really 299 00:14:07.200 --> 00:14:11.519 critical system I might still need attention, while a high 300 00:14:11.559 --> 00:14:14.679 severity vulnerability to the system that's not that important might 301 00:14:14.720 --> 00:14:16.039 not be as much of a priority. 302 00:14:16.320 --> 00:14:19.240 Okay, so severity is important, but we also need to 303 00:14:19.799 --> 00:14:21.879 think about the bigger picture. What else should we be 304 00:14:21.919 --> 00:14:22.440 looking at. 305 00:14:22.559 --> 00:14:24.960 You should also pay attention to the confidence level that's 306 00:14:24.960 --> 00:14:26.039 assigned to each finding. 307 00:14:26.440 --> 00:14:28.799 Confidence level, what exactly does that mean? 308 00:14:29.039 --> 00:14:33.639 It's basically how certain the tool is that the finding 309 00:14:33.720 --> 00:14:37.879 is actually a real vulnerability. Static analysis tools are they're 310 00:14:37.919 --> 00:14:42.440 really smart, but they're they're not perfect. Okay. Yeah, Sometimes 311 00:14:42.440 --> 00:14:44.919 they can flag something as a vulnerability when it's actually 312 00:14:45.200 --> 00:14:47.480 not a problem. Those are called false positives. 313 00:14:47.759 --> 00:14:51.279 So a high confidence finding means it's more likely to 314 00:14:51.320 --> 00:14:54.159 be a real vulnerability than a low confidence finding. 315 00:14:54.320 --> 00:14:58.120 Exactly. And a good tool will give you information to 316 00:14:58.200 --> 00:15:00.480 help you decide how much you can trust each finding. 317 00:15:00.919 --> 00:15:05.559 Okay, so we're looking at severity, context, confidence level, anything else. 318 00:15:05.639 --> 00:15:07.879 To keep in mind, you should. 319 00:15:07.600 --> 00:15:09.919 Also take a look at the recommendations the tool gives 320 00:15:09.960 --> 00:15:11.679 you for fixing each vulnerability. 321 00:15:11.799 --> 00:15:14.279 Oh so, so the tool doesn't just tell you what's wrong, 322 00:15:14.279 --> 00:15:16.440 it actually gives you some guidance on how to fix 323 00:15:16.480 --> 00:15:17.120 it exactly. 324 00:15:17.200 --> 00:15:20.440 Yeah, and those recommendations could be anything from like simple 325 00:15:20.519 --> 00:15:25.200 code changes to more more complicated architectural modifications. 326 00:15:25.200 --> 00:15:27.080 Okay, so it's not just leaving you hanging, it's it's 327 00:15:27.080 --> 00:15:29.639 giving your roadmap for how to fix things. 328 00:15:29.919 --> 00:15:33.159 Right. But before you go and start changing your code, 329 00:15:33.399 --> 00:15:36.200 it's really important to validate each finding and make sure 330 00:15:36.200 --> 00:15:37.919 it's a real vulnerability. 331 00:15:38.080 --> 00:15:41.000 Ah, So we need to do some manual checking before 332 00:15:41.039 --> 00:15:43.440 we start hacking away at our code. 333 00:15:43.679 --> 00:15:47.320 You got it. Static analysis tools are they're powerful, but 334 00:15:47.360 --> 00:15:50.080 they're not perfect. You know. They can have those false 335 00:15:50.120 --> 00:15:53.879 positives and sometimes they might even miss real vulnerabilities. 336 00:15:54.200 --> 00:15:57.320 So even with these really sophisticated tools, we still need 337 00:15:57.360 --> 00:15:59.759 to use our own judgment and expertise. 338 00:16:00.039 --> 00:16:02.240 Absolutely, and that's exactly what we're going to do in 339 00:16:02.279 --> 00:16:04.039 the next part of our deep dives. We're going to 340 00:16:04.080 --> 00:16:06.360 take all of this knowledge. We're going to analyze some 341 00:16:06.480 --> 00:16:09.440 sample code with a real static analysis. Cool. 342 00:16:09.559 --> 00:16:12.440 Okay, I'm really looking forward to seeing these tools and action. 343 00:16:12.559 --> 00:16:15.399 So stay tuned, folks, we'll be right back to explore 344 00:16:15.440 --> 00:16:20.360 the world of real world code analysis. Okay, So we've 345 00:16:20.480 --> 00:16:22.840 we've talked about all the theory, we've looked at the tools, 346 00:16:23.120 --> 00:16:26.039 but now it's time to actually see static analysis in action. 347 00:16:26.879 --> 00:16:29.519 You know, roll our sleeves and get our hands a 348 00:16:29.559 --> 00:16:30.120 little dirty. 349 00:16:30.320 --> 00:16:33.200 Absolutely. Yeah, let's dive into some real coat and see 350 00:16:33.200 --> 00:16:33.799 what we can find. 351 00:16:33.960 --> 00:16:37.480 All right, So for this, for this little demonstration, We've 352 00:16:37.480 --> 00:16:40.559 got a simple Java web application. It's a it's basically 353 00:16:40.600 --> 00:16:43.639 a log in system. But you know, as we all know, 354 00:16:43.840 --> 00:16:48.000 even even simple systems can have can have hidden vulnerabilities. 355 00:16:48.039 --> 00:16:51.200 Oh yeah, definitely. You don't need complexity to have security flaws, 356 00:16:51.200 --> 00:16:53.840 that's for sure. So for this deep dive, we're going 357 00:16:53.879 --> 00:16:57.879 to be using a pretty popular commercial static analysis tool. 358 00:16:57.919 --> 00:17:02.279 It's called Fortify Source Code Analyzer or Fortify s c A. 359 00:17:02.440 --> 00:17:06.319 For sure SCA. All right, so how does this How 360 00:17:06.319 --> 00:17:08.680 does this all work? Do we just like point Fortify 361 00:17:08.720 --> 00:17:10.039 at our code and let it do its thing? 362 00:17:10.119 --> 00:17:12.559 Pretty much? Yeah, We feed the source code into Fortify 363 00:17:12.720 --> 00:17:15.079 s c A and then it goes to work. It 364 00:17:15.119 --> 00:17:17.400 analyzes the code based on a set of you know, 365 00:17:17.440 --> 00:17:19.319 predefined rules and configurations. 366 00:17:19.400 --> 00:17:22.240 So it's kind of like setting a bloodhound on the 367 00:17:22.279 --> 00:17:24.839 trail of a cent, except in this case, the scent 368 00:17:25.000 --> 00:17:25.960 is vulnerabilities. 369 00:17:26.160 --> 00:17:29.799 Huh Yeah, I like that analogy. Fortify SCA sniffs out 370 00:17:29.799 --> 00:17:33.519 those weaknesses in the code, and and once the analysis 371 00:17:33.559 --> 00:17:36.079 is completed, it gives us a report that highlights any 372 00:17:36.119 --> 00:17:37.519 potential issues that is found. 373 00:17:37.680 --> 00:17:42.200 Okay, all right, so let's see what this security bloodhound 374 00:17:42.240 --> 00:17:44.920 can dig up. What kind of vulnerabilities are we are 375 00:17:44.920 --> 00:17:46.039 we hoping to find here? 376 00:17:46.279 --> 00:17:49.440 Well, I mean, based on what we've talked about, SQL 377 00:17:49.480 --> 00:17:52.839 injection is always a big concern with with web applications, 378 00:17:53.200 --> 00:17:56.240 especially those dealing with you know, user logins. 379 00:17:55.960 --> 00:17:59.599 Right, sql injection the villain that always seems to come back. 380 00:18:00.559 --> 00:18:02.680 So let's let's see a fortify s c A can 381 00:18:02.680 --> 00:18:08.839 spot any any potential SQL injection vulnerabilities in our login 382 00:18:08.920 --> 00:18:11.880 system here? All right, okay, so it looks like fortifyica 383 00:18:11.960 --> 00:18:14.559 is found something. It's flagged dis section of code where 384 00:18:14.599 --> 00:18:16.960 the where the log in system is building a SQL 385 00:18:17.000 --> 00:18:19.400 query using string concatenation. 386 00:18:19.680 --> 00:18:22.359 Oh okay, that's a that's a classic red flag for 387 00:18:22.359 --> 00:18:25.400 SQL injection, right, Like, if you're you're directly putting user 388 00:18:25.440 --> 00:18:28.400 input into the query without shading it properly. It's it's 389 00:18:28.440 --> 00:18:31.160 basically like leaving the door wide open for an attacker. 390 00:18:31.319 --> 00:18:34.359 Exactly. Yeah, an attacker could could manipulate that user input, 391 00:18:34.480 --> 00:18:37.480 change the SQL query and and potentially gain access to 392 00:18:37.519 --> 00:18:38.039 the database. 393 00:18:38.119 --> 00:18:38.680 Oh that's not. 394 00:18:38.680 --> 00:18:41.680 Good, not good at all. And uh and that's exactly 395 00:18:41.759 --> 00:18:43.960 what fortify s c A is designed to catch. It's 396 00:18:44.000 --> 00:18:47.519 it's following that user input or that tainted data as 397 00:18:47.519 --> 00:18:50.240 we call it, and it flags any instances where that 398 00:18:50.359 --> 00:18:54.240 data reaches you know, sensitive operation, like like a database query. 399 00:18:54.799 --> 00:18:57.200 So it's like, uh, fortify s c A is playing 400 00:18:57.240 --> 00:18:59.400 a game of connect the dots, you know, between the 401 00:18:59.480 --> 00:19:03.079