WEBVTT 1 00:00:00.000 --> 00:00:03.520 All right, listeners, get ready to dive deep. We've got 2 00:00:03.520 --> 00:00:05.519 some fascinating stuff done pack today. 3 00:00:05.599 --> 00:00:07.360 Yeah, this is exciting you guys sent. 4 00:00:07.280 --> 00:00:11.400 Us excerpts from the cert Oracle Secure Coding Standard for Java. 5 00:00:11.519 --> 00:00:12.480 Oh that's a good one. 6 00:00:12.560 --> 00:00:15.359 It's like the holy grail of secure Java development. 7 00:00:15.439 --> 00:00:15.560 Yea. 8 00:00:16.120 --> 00:00:18.920 Even James Gosling himself endorses this thing. 9 00:00:18.960 --> 00:00:21.640 He does. Yeah, it's the real deal. We're talking enterprise 10 00:00:21.679 --> 00:00:24.440 grade best practices, the stuff they use to build the 11 00:00:24.519 --> 00:00:27.280 systems that run well practically everything exactly. 12 00:00:27.399 --> 00:00:30.879 And the goal today is to pull out the absolute 13 00:00:31.640 --> 00:00:35.479 key nuggets of wisdom from this standard. Wow, the stuff 14 00:00:35.520 --> 00:00:38.840 that's going to help you guys write seriously secure Java code. 15 00:00:38.920 --> 00:00:41.079 Absolutely, And just to add to that, it's not just 16 00:00:41.119 --> 00:00:43.600 theory we're talking about here, right. The introduction of this 17 00:00:43.679 --> 00:00:47.079 standard actually points out that a crazy sixty four percent 18 00:00:47.079 --> 00:00:49.159 of vulnerability is back in two thousand and four. And 19 00:00:49.240 --> 00:00:51.439 this is still relevant today, by the way, Yeah, sixty 20 00:00:51.520 --> 00:00:54.679 four percent. They were just simple coding errors. Wow, So 21 00:00:54.759 --> 00:00:56.600 this is stuff that has real world implications. 22 00:00:56.880 --> 00:00:59.920 That is a so bring statistic. Okay, So before we 23 00:01:00.079 --> 00:01:02.439 get into the really nitty gritty details, let's just sort 24 00:01:02.479 --> 00:01:05.280 of scent the stage a little bit. What exactly is 25 00:01:05.319 --> 00:01:09.000 a coding standard and why should developers even care about 26 00:01:09.000 --> 00:01:09.519 this stuff? 27 00:01:09.680 --> 00:01:12.799 That's a great question. Think of a coding standard as 28 00:01:13.040 --> 00:01:17.040 a blueprint for secure development. It's a set of rules, 29 00:01:17.120 --> 00:01:20.200 a set of guidelines that are really there to eliminate 30 00:01:20.280 --> 00:01:23.280 those really common coding mistakes, right, the ones that we 31 00:01:23.319 --> 00:01:25.799 all make, let's be honest, that can just open up 32 00:01:25.799 --> 00:01:28.439 these huge security holes in our applications. 33 00:01:28.519 --> 00:01:30.959 Right, So it's all about being proactive exactly. 34 00:01:31.000 --> 00:01:34.400 It's all about prevention, you know, preventing these issues before 35 00:01:34.439 --> 00:01:36.400 they even have a chance to become a problem. 36 00:01:36.560 --> 00:01:39.439 And this standard is serious business. I mean, it even 37 00:01:39.480 --> 00:01:43.560 has different levels of conformants. Like there's nonconforming, which I 38 00:01:43.560 --> 00:01:44.920 guess is self explanatory, so. 39 00:01:44.959 --> 00:01:46.359 You're not following the rules. 40 00:01:46.120 --> 00:01:49.920 Conforming, you're crying. And then there's the like gold standard 41 00:01:50.200 --> 00:01:52.239 provably conforming, right. 42 00:01:52.359 --> 00:01:55.239 And those levels are there to help organizations figure out 43 00:01:55.280 --> 00:01:57.280 where they stand security wise. 44 00:01:57.359 --> 00:01:57.519 Right. 45 00:01:58.439 --> 00:02:01.439 But there's this really cool thing called the deviation procedure. 46 00:02:02.640 --> 00:02:06.799 So sometimes there are very specific reasons why you might 47 00:02:06.879 --> 00:02:08.159 need to deviate from a rule. 48 00:02:08.240 --> 00:02:09.800 Okay, so it's kind of like a break glass in 49 00:02:09.840 --> 00:02:11.199 case of emergency kind of thing. 50 00:02:11.360 --> 00:02:15.240 Exactly, but the standards really really clear about this. Security 51 00:02:15.280 --> 00:02:21.280 cannot be sacrificed for performance ever, that's non negotiable. 52 00:02:20.960 --> 00:02:22.560 No shortcuts when it comes to security. 53 00:02:22.639 --> 00:02:26.360 Got it now, Java itself is often considered a pretty 54 00:02:26.360 --> 00:02:29.240 secure language, right, I mean, what is it about Java 55 00:02:29.280 --> 00:02:31.439 that makes it so special in the security department. 56 00:02:31.719 --> 00:02:34.479 Well, Java was really designed with security in mind from 57 00:02:34.520 --> 00:02:37.360 the very beginning. Okay, So there are features like automatic 58 00:02:37.400 --> 00:02:41.319 bounds checking. You know, there's no explicit pointers in Java, 59 00:02:41.360 --> 00:02:43.439 which is a good thing, right. And there's this thing 60 00:02:43.479 --> 00:02:47.360 called the bytecode verifier that's constantly checking for violations, you know, 61 00:02:47.759 --> 00:02:49.719 making sure that the code is playing by the rules. 62 00:02:49.840 --> 00:02:52.240 So Java itself is kind of like a fortress already 63 00:02:52.280 --> 00:02:55.080 pretty well defended. Yeah, you could say that that even 64 00:02:55.120 --> 00:02:59.240 the strongest fortress can be compromised if the people inside 65 00:02:59.280 --> 00:03:02.960 aren't careful, right, the human element, that's often the weakest link. 66 00:03:03.080 --> 00:03:04.039 We can make mistakes. 67 00:03:04.080 --> 00:03:06.840 So even with the best intentions, developers can still mess 68 00:03:06.879 --> 00:03:09.080 things up. What's a common area where things tend to 69 00:03:09.080 --> 00:03:09.479 go wrong? 70 00:03:09.719 --> 00:03:15.840 Ah concurrency. Ah concurrency powerful tool for building responsive applications, 71 00:03:15.840 --> 00:03:19.759 but it's also like opening a Pandora's box of security issues. 72 00:03:19.879 --> 00:03:24.000 Yeah, concurrency the double edged sword. You've got multiple threads 73 00:03:24.039 --> 00:03:26.800 all running around, potentially step it on each other's toes, 74 00:03:26.800 --> 00:03:29.080 messing with data. It's a lot to keep. 75 00:03:28.960 --> 00:03:31.840 Track of exactly. You have data races where you've got 76 00:03:32.000 --> 00:03:35.080 multiple threads trying to access and modify the same data 77 00:03:35.120 --> 00:03:39.319 at the same time, right, leading to unpredictable results total chaos. 78 00:03:39.759 --> 00:03:43.280 Then you have visibility issues where changes made by one 79 00:03:43.360 --> 00:03:45.520 thread aren't immediately visible to the others. 80 00:03:45.840 --> 00:03:46.360 Oh right. 81 00:03:46.439 --> 00:03:48.680 And then, just to make things even more interesting, there's 82 00:03:48.759 --> 00:03:53.039 the unpredictable order in which threads might actually execute. It 83 00:03:53.080 --> 00:03:55.159 makes it so hard to figure out what the program's 84 00:03:55.199 --> 00:03:55.560 going to do. 85 00:03:56.000 --> 00:03:59.319 It sounds like a recipe for disaster. So how does 86 00:03:59.360 --> 00:04:03.759 the cert standard help us navigate this concurrency mindfield? How 87 00:04:03.759 --> 00:04:04.560 do we stay safe? 88 00:04:05.280 --> 00:04:08.120 Well? One way it does this is by really emphasizing 89 00:04:08.120 --> 00:04:10.319 the concept of happens before relationships. 90 00:04:10.439 --> 00:04:11.960 Happens before relationships. 91 00:04:12.039 --> 00:04:14.680 Okay, Yeah, it's a way to bring order to the 92 00:04:14.759 --> 00:04:19.759 chaos of concurrency. It's basically defining a strict order of operations. Okay, 93 00:04:19.839 --> 00:04:22.399 even when you have all these threads running around. For example, 94 00:04:22.439 --> 00:04:26.639 think about releasing an object's intrinsic lock that always happens 95 00:04:26.680 --> 00:04:29.399 before the next time that lock is acquired. It's a rule, 96 00:04:29.839 --> 00:04:32.079 and that helps prevent those data races. 97 00:04:32.319 --> 00:04:34.720 So happens before is like a set of traffic signals 98 00:04:34.720 --> 00:04:38.399 for threads, making sure they don't collide at intersections exactly. 99 00:04:38.519 --> 00:04:42.000 But how do you actually implement these happens before relationships 100 00:04:42.000 --> 00:04:44.600 in your code. That's where synchronization methods come. 101 00:04:44.519 --> 00:04:47.319 In, right, synchronization keeping those threads in check. Tell me 102 00:04:47.360 --> 00:04:49.000 more about these methods and how they work. 103 00:04:49.240 --> 00:04:51.959 Well, you've got several options, each with us own trade offs. 104 00:04:52.160 --> 00:04:55.360 There's volatile variables, which guarantee that changes are visible to 105 00:04:55.439 --> 00:04:59.519 all threads instantly. Then there are synchronized blocks, which allow 106 00:04:59.600 --> 00:05:02.639 only one thread at a time to access a protected 107 00:05:02.639 --> 00:05:06.000 section of code. And then you have atomic classes, which 108 00:05:06.040 --> 00:05:09.360 provide thread safe operations on individual variables. 109 00:05:09.600 --> 00:05:12.040 So many choices. How do we know which one to 110 00:05:12.079 --> 00:05:13.279 pick in a given situation. 111 00:05:13.639 --> 00:05:16.560 Well, the standard actually gives some excellent guidance on that. 112 00:05:16.720 --> 00:05:18.439 It even quotes Brian Goats. 113 00:05:18.680 --> 00:05:21.959 Oh yeah, I've heard of him, a concurrency guru, right. 114 00:05:21.839 --> 00:05:24.839 Exactly, and he says atomic classes are perfect for low 115 00:05:24.920 --> 00:05:28.000 contention situations. You know, when you don't have a ton 116 00:05:28.040 --> 00:05:31.199 of threads fighting over the same variable. But for those 117 00:05:31.240 --> 00:05:34.720 high contention situations blocks, you know, like those provided by 118 00:05:34.720 --> 00:05:37.040 synchronized blocks, those are a better choice. 119 00:05:37.079 --> 00:05:39.720 So choosing the right synchronization method is like choosing the 120 00:05:39.759 --> 00:05:42.000 right tool for the job. You wouldn't use a hammer 121 00:05:42.040 --> 00:05:43.839 to screw in a light bulb exactly. 122 00:05:44.319 --> 00:05:46.839 And speaking of choosing the right tool, another crucial part 123 00:05:46.879 --> 00:05:48.920 of secure coding is input validation. 124 00:05:49.439 --> 00:05:54.600 Uh, input validation. The golden rule never trust anything that 125 00:05:54.600 --> 00:05:55.680 comes from the outside world. 126 00:05:55.759 --> 00:05:59.720 You said it, and that means any external input user's environment, 127 00:05:59.839 --> 00:06:03.519 veriables data from the network, anything. Treat it all as 128 00:06:03.560 --> 00:06:07.720 potentially malicious, validate it, sanitize it before you even think 129 00:06:07.759 --> 00:06:08.399 about using it. 130 00:06:08.480 --> 00:06:11.120 Because if we skip that validation step, what kind of 131 00:06:11.120 --> 00:06:11.879 trouble are we in? 132 00:06:12.040 --> 00:06:15.319 Oh, the consequences can be severe. We're talking SQL injection, 133 00:06:15.639 --> 00:06:19.800 where malicious input messes with your database queries, command injection 134 00:06:19.959 --> 00:06:23.160 where attackers can run commands on your system. And then 135 00:06:23.399 --> 00:06:27.000 there are XML external entity attacks which exploit vulnerabilities in 136 00:06:27.160 --> 00:06:27.879 XML parsing. 137 00:06:28.199 --> 00:06:31.000 So basically, not validating input is like leaving your front 138 00:06:31.000 --> 00:06:33.360 door wide open with a big neon sign that says 139 00:06:33.519 --> 00:06:34.360 welcome hackers. 140 00:06:34.720 --> 00:06:37.839 Pretty much, but luckily The standard gives some very specific 141 00:06:37.920 --> 00:06:41.560 advice on how to protect yourself. Normalize those strings before validation, 142 00:06:41.639 --> 00:06:45.079 you know, make sure they're formatted consistently, use whitelists to 143 00:06:45.160 --> 00:06:48.720 only allow save input patterns, and sanitize that user input 144 00:06:48.759 --> 00:06:50.920 before you log it so you don't accidentally inject any 145 00:06:50.959 --> 00:06:51.720 malicious code. 146 00:06:51.759 --> 00:06:55.480 Okay, speaking of sneaky attacks, our source material also mentions 147 00:06:55.600 --> 00:06:59.920 character encodings as a potential security risk. Why is that 148 00:07:00.480 --> 00:07:02.360 they seem like such a low level detail. 149 00:07:02.600 --> 00:07:06.160 You'd be surprised how often character encoding mismatches can cause 150 00:07:06.279 --> 00:07:10.000 major data correction, especially when you're working with file imputed 151 00:07:10.040 --> 00:07:13.240 output or network stuff. Right, and the standard dives into 152 00:07:13.279 --> 00:07:17.199 a really tricky issue called trailing byte problem. This happens 153 00:07:17.240 --> 00:07:18.600 in multi byting codings. 154 00:07:18.720 --> 00:07:21.279 Trailing byte sounds ominous, it can be. 155 00:07:21.319 --> 00:07:23.639 Imagine you've got a buffer boundary right where your data 156 00:07:23.639 --> 00:07:25.920 gets split up, and a multi byte character it gets 157 00:07:25.959 --> 00:07:29.600 split across that boundary. Because of how these encodings work, 158 00:07:29.639 --> 00:07:32.639 those split bytes, they can get interpreted completely differently than 159 00:07:32.639 --> 00:07:33.360 what you intended. 160 00:07:33.480 --> 00:07:35.480 So it's like a word getting cut in half, and 161 00:07:35.600 --> 00:07:38.319 suddenly the second half takes on a whole new meaning. 162 00:07:38.360 --> 00:07:41.720 Exactly and It can happen even if the data looks 163 00:07:41.720 --> 00:07:44.600 fine at first glance. So the standard's advice is to 164 00:07:44.759 --> 00:07:48.000 always be super aware of your platform's default encoding. 165 00:07:48.279 --> 00:07:52.120 Okay, noted, always double check those encodings. Okay, get ready, 166 00:07:52.160 --> 00:07:54.879 We're about to go deep here. The next section in 167 00:07:54.920 --> 00:07:59.040 this standard is called Sneaky Subtleties. Yeah, what hidden dangers 168 00:07:59.079 --> 00:08:00.000 are we about to uncot? 169 00:08:00.439 --> 00:08:02.519 Oh? This is where it gets interesting, even for those 170 00:08:02.560 --> 00:08:06.199 seasoned Java developers up there. It's all about those little gotchas, 171 00:08:06.240 --> 00:08:09.240 those tiny details that can trip you up if you're 172 00:08:09.240 --> 00:08:10.319 not paying close attention. 173 00:08:10.600 --> 00:08:14.040 All right, color me intrigued. Give me the lowdown on 174 00:08:14.120 --> 00:08:16.560 these sneaky subtleties. What kind of things should we be 175 00:08:16.600 --> 00:08:17.279 watching out for? 176 00:08:18.040 --> 00:08:22.079 Well, one example is ignoring return values. The standard talks 177 00:08:22.079 --> 00:08:25.759 about the string dot replace method. Okay, because strings and 178 00:08:25.839 --> 00:08:29.519 Java are immutable, that replace method. It doesn't modify the 179 00:08:29.560 --> 00:08:32.600 original string, right, It returns a brand new string with 180 00:08:32.679 --> 00:08:35.840 the replacements. So if you ignore that return value, you're 181 00:08:35.879 --> 00:08:37.679 basically throwing away the results. 182 00:08:37.720 --> 00:08:40.080 Ah, So you have to assign that return value to 183 00:08:40.360 --> 00:08:41.480 a variable. 184 00:08:41.080 --> 00:08:45.080 Exactly, otherwise it's gone poof. Another sneaky trap is comparing 185 00:08:45.159 --> 00:08:49.320 boxed primitives, you know, things like integer or boolean, where 186 00:08:49.440 --> 00:08:52.240 primitive type is wrapped up in an object. Right when 187 00:08:52.240 --> 00:08:55.720 you use the double equals operator to compare those things 188 00:08:55.759 --> 00:08:57.840 get a little weird because of memmoization. 189 00:08:58.200 --> 00:09:01.759 Memoization. That's like when my web browser remembers my passwords 190 00:09:01.759 --> 00:09:03.559 so I don't have to type them in every single time. 191 00:09:03.720 --> 00:09:06.879 Sort of. It's basically cashing commonly used values to make 192 00:09:06.919 --> 00:09:11.480 things faster, but with boxed primitives it can cause unexpected results. 193 00:09:12.000 --> 00:09:14.879 Say you have two integer objects, both with the value 194 00:09:14.919 --> 00:09:19.279 one hundred. You'd think comparing them with moocitrals would return. 195 00:09:18.960 --> 00:09:20.799 True, right because they have the same value. 196 00:09:20.879 --> 00:09:23.720 Right, But because of memmalization, Java might be comparing the 197 00:09:23.759 --> 00:09:27.080 object references instead of the values themselves, so you might 198 00:09:27.080 --> 00:09:28.200 get a false result. 199 00:09:28.320 --> 00:09:30.159 So it's like you think you're comparing the contents of 200 00:09:30.159 --> 00:09:33.159 two boxes, but you're actually comparing the boxes themselves. That 201 00:09:33.279 --> 00:09:34.519 is tricky, tricky. 202 00:09:34.639 --> 00:09:38.320 Indeed, the standard is full of these insights. Another one 203 00:09:38.360 --> 00:09:40.720 is hidden side effects within assertions. 204 00:09:40.879 --> 00:09:43.879 AH assertions, those are the statements we use to check 205 00:09:43.919 --> 00:09:45.840 conditions that should be true, and if they're not, it 206 00:09:45.840 --> 00:09:46.559 throws an error. 207 00:09:46.799 --> 00:09:50.600 Exactly, But here's the catch. Assertions in Java can be 208 00:09:50.639 --> 00:09:53.000 turned on or off at runtime, So if you put 209 00:09:53.080 --> 00:09:56.200 code with side effects inside an assertion, it might not 210 00:09:56.240 --> 00:09:58.120 always get executed when you expect it to. 211 00:09:58.320 --> 00:10:00.559 Oh so it's like setting a trap, but it might 212 00:10:00.600 --> 00:10:02.919 not actually spring when an intruder steps on it. 213 00:10:03.000 --> 00:10:04.360 That's a great way to put it, and that can 214 00:10:04.440 --> 00:10:08.279 lead to some really unexpected and potentially dangerous behavior. 215 00:10:08.440 --> 00:10:12.679 Okay, so far we've talked about concurrency chaos, the importance 216 00:10:12.679 --> 00:10:18.799 of input validation, sneaky character encodings, ignoring return values, boxed 217 00:10:18.879 --> 00:10:23.879 primitive comparison, weirdness, and hidden side effects and assertions. I'm 218 00:10:23.919 --> 00:10:26.840 starting to see why this standard is considered like the 219 00:10:26.919 --> 00:10:30.159 gold standard for secure Java coding. What other landmines are 220 00:10:30.200 --> 00:10:31.759 we going to encounter in this deep dive? 221 00:10:32.320 --> 00:10:36.200 Well, locking, for one, it's crucial for thread safety, but 222 00:10:36.320 --> 00:10:39.000 even the most experienced developers can make mistakes that lead 223 00:10:39.000 --> 00:10:39.679 to deadlocks. 224 00:10:39.840 --> 00:10:42.879 Deadlocks those sound scary. What are they and how do 225 00:10:42.919 --> 00:10:43.360 they happen? 226 00:10:43.679 --> 00:10:47.240 Imagine a classic traffic jam. Everyone's stuck because they're all 227 00:10:47.279 --> 00:10:50.320 waiting for each other to move. That's essentially a deadlock. 228 00:10:50.399 --> 00:10:53.320 In the world of multi threaded programming, it happens when 229 00:10:53.320 --> 00:10:56.320 you have two or more threads that are blocked indefinitely, 230 00:10:56.799 --> 00:10:59.399 waiting for each other to release the resources they need. 231 00:10:59.559 --> 00:11:01.840 So it's like a very polite dinner party gone horribly 232 00:11:01.879 --> 00:11:05.720 wrong because everyone's too busy being polite to actually eat exactly. 233 00:11:06.480 --> 00:11:10.360 The standard recommends a specific pattern called the private Final 234 00:11:10.480 --> 00:11:15.159 lock Object IDIOM to prevent these kinds of deadlocks. Basically, 235 00:11:15.240 --> 00:11:19.360 you create a dedicated lock object that's only accessible within 236 00:11:19.399 --> 00:11:22.039 the class that needs to protect its data. It keeps 237 00:11:22.080 --> 00:11:23.519 external code from interfering. 238 00:11:23.720 --> 00:11:26.159 Ah, So it's like having a separate lock and key 239 00:11:26.200 --> 00:11:28.200 for each room in your house instead of one master 240 00:11:28.279 --> 00:11:30.120 key that anyone could copy exactly. 241 00:11:30.679 --> 00:11:34.159 And to further avoid deadlocks, the standard says, hey, release 242 00:11:34.200 --> 00:11:37.039 those locks in the same order you acquired them. It 243 00:11:37.080 --> 00:11:41.080 even uses that classic philosopher's dining analogy to illustrate the point. 244 00:11:41.159 --> 00:11:42.799 Philosopher's dining Okay, I'm listening. 245 00:11:43.240 --> 00:11:45.879 Imagine a bunch of philosophers sitting around a table, and 246 00:11:45.919 --> 00:11:48.559 they each need two forks to eat. If they all 247 00:11:48.600 --> 00:11:50.639 grab their right fork first and then wait for the 248 00:11:50.720 --> 00:11:53.240 left fork, nobody eats. They're all stuck. 249 00:11:53.480 --> 00:11:56.799 So it's like a philosophical discussion that descends into chaos 250 00:11:57.120 --> 00:12:00.000 because everyone is too busy holding onto their own idea 251 00:12:00.279 --> 00:12:02.720 is to actually listen to anyone else precisely. 252 00:12:03.200 --> 00:12:07.039 And this brings us to serialization, a powerful tool, no doubt. 253 00:12:07.279 --> 00:12:09.919 It lets you convert objects into a stream of bites 254 00:12:10.240 --> 00:12:12.120 so you can easily send them over a network or 255 00:12:12.159 --> 00:12:13.039 store them in a file. 256 00:12:13.200 --> 00:12:17.399 Right. Serialization making those objects travel ready. But I have 257 00:12:17.399 --> 00:12:19.320 a feeling there's a butt coming there is. 258 00:12:19.960 --> 00:12:24.200 Serialization is great, but it has its security risks. Attackers 259 00:12:24.240 --> 00:12:27.440 can potentially mess with the state of an object during reconstitution. 260 00:12:27.799 --> 00:12:30.159 You know when those bites are being converted back into 261 00:12:30.159 --> 00:12:30.720 an object. 262 00:12:30.799 --> 00:12:33.080 So it's like sending a package through the mail and 263 00:12:33.120 --> 00:12:37.000 someone tampers with the contents en rout, replacing those delicious 264 00:12:37.000 --> 00:12:39.679 cookies with something less hepatizing. 265 00:12:39.759 --> 00:12:42.320 That's a great analogy to prevent that kind of tampering. 266 00:12:42.360 --> 00:12:44.960 The Standard recommends what they call the sign then seal 267 00:12:45.080 --> 00:12:48.840 approach for sensitive data. It combines digital signatures. 268 00:12:48.240 --> 00:12:51.039 And encryption sign then seal tell me more. 269 00:12:51.279 --> 00:12:54.960 First, you digitally sign the object, which is like adding 270 00:12:55.000 --> 00:12:58.159 a tamperproof seal. Think of it like a wax seal 271 00:12:58.279 --> 00:13:00.720 on an old fashioned letter. And then you encrypt the 272 00:13:00.840 --> 00:13:02.919 whole thing to protect the data. 273 00:13:02.639 --> 00:13:04.840 Double, the protection, double the peace of mind. 274 00:13:04.759 --> 00:13:08.159 Exactly, and the standard goes even further. It says, always 275 00:13:08.279 --> 00:13:12.600 validate an object state after de serialization, especially if you're 276 00:13:12.639 --> 00:13:15.559 dealing with sensitive stuff like credit card numbers. 277 00:13:15.679 --> 00:13:20.480 Smart move. Never take anything for granted, especially when dealing 278 00:13:20.519 --> 00:13:23.799 with sensitive data. Okay, we've covered a ton of ground 279 00:13:23.840 --> 00:13:29.279 here already, concurrency and synchronization, input validation, character encoding, those 280 00:13:29.279 --> 00:13:33.360 sneaky subtleties with strings and primitives, locking in deadlocks, and 281 00:13:33.399 --> 00:13:37.080 even the security considerations of serialization. I'm starting to feel 282 00:13:37.080 --> 00:13:38.559 like a secure coding ninja. 283 00:13:38.600 --> 00:13:40.879 That's great, But remember this is just the beginning. 284 00:13:40.960 --> 00:13:41.519 Oh there's more. 285 00:13:41.600 --> 00:13:43.840 There is a lot more to explore in the world 286 00:13:43.840 --> 00:13:45.120 of secure Java coding. 287 00:13:45.200 --> 00:13:47.320 I'm ready for more. Bring on the next round of 288 00:13:47.360 --> 00:13:48.840 security wisdom, you got it. 289 00:13:49.440 --> 00:13:50.879 In the next part of our deep dive, we're going 290 00:13:50.960 --> 00:13:54.440 to tackle exception handling, how to deal with those unexpected 291 00:13:54.480 --> 00:13:56.799 events in a way that doesn't compromise security. 292 00:13:57.080 --> 00:13:59.639 Exception handling. Though it sounds like we're about to venture 293 00:13:59.639 --> 00:14:02.279 into the dark underbelly of Java code. I can't wait. 294 00:14:02.440 --> 00:14:05.159 It's going to be good. Okay, are you ready to 295 00:14:05.240 --> 00:14:07.799 jump back into the world of secure Java coding. 296 00:14:08.279 --> 00:14:12.720 Absolutely, I'm still buzzing from our last conversation. Where are 297 00:14:12.759 --> 00:14:15.440 we headed next on this secure coding journey. 298 00:14:15.639 --> 00:14:17.759 Well, there's a section in the search standard that I 299 00:14:17.759 --> 00:14:22.639 think you'll find particularly interesting. It's all about exceptional behavior. 300 00:14:23.720 --> 00:14:27.799 Exceptional behavior hmmm, sounds intriguing. Are we talking about, like 301 00:14:28.559 --> 00:14:31.279 how to handle exceptions in a way that doesn't compromise 302 00:14:31.279 --> 00:14:32.480 security exactly? 303 00:14:32.559 --> 00:14:35.919 Handling exceptions is crucial, but it's often overlooked from a 304 00:14:35.919 --> 00:14:36.799 security standpoint. 305 00:14:36.879 --> 00:14:39.799 Okay, I'm all ears. What kind of security risks can 306 00:14:40.000 --> 00:14:41.919 exceptions actually pose? Fill me in? 307 00:14:42.240 --> 00:14:45.720 Well, think about it. Exceptions they often carry sensitive information, 308 00:14:46.120 --> 00:14:48.840 oh right, Like a file not found exception that might 309 00:14:48.960 --> 00:14:52.879 accidentally reveal the structure of your file system to an attacker, okay, 310 00:14:53.080 --> 00:14:56.000 or SQL exception it could hint at the details of 311 00:14:56.039 --> 00:14:58.399 your database schema, stuff you don't want getting out. 312 00:14:58.600 --> 00:15:01.120 So it's like those detective shows where they find a 313 00:15:01.200 --> 00:15:05.120 seemingly insignificant clue, like a stray fiber, and it leads 314 00:15:05.159 --> 00:15:07.679 them to the whole crime scene. You're saying, those little 315 00:15:07.720 --> 00:15:11.080 exception details can be like breadcrumbs for attackers. 316 00:15:11.159 --> 00:15:15.559 Precisely, attackers can piece together these seemingly minor leaks to 317 00:15:15.600 --> 00:15:19.159 get a much bigger picture of your system's weaknesses. It's 318 00:15:19.200 --> 00:15:23.120 like a puzzle, and exceptions can give them those missing pieces. 319 00:15:23.320 --> 00:15:26.679 Okay, so how do we prevent those leaks? Do we 320 00:15:26.759 --> 00:15:29.519 just swallow all exceptions and pretend nothing went wrong. 321 00:15:29.639 --> 00:15:32.559 That's not the best approach. The key is to handle 322 00:15:32.559 --> 00:15:37.200 those exceptions gracefully without giving away more information than absolutely necessary. 323 00:15:37.919 --> 00:15:41.279 One important rule to standard highlights is to avoid exposing 324 00:15:41.320 --> 00:15:45.000 the original exception when you're rethrowing it. They actually give 325 00:15:45.000 --> 00:15:48.039 a non compliant example where a file not found exception 326 00:15:48.120 --> 00:15:50.559 gets wrapped in a more general io exception. 327 00:15:50.759 --> 00:15:54.360 But isn't wrapping exceptions considered good practice. It makes the 328 00:15:54.399 --> 00:15:57.039 code cleaner and it allows you to handle errors at 329 00:15:57.080 --> 00:15:57.759 a higher level. 330 00:15:58.039 --> 00:16:00.000 It is good practice, but you have to be very 331 00:16:00.159 --> 00:16:03.559 careful about what information you're propagating up the chain. Even 332 00:16:03.639 --> 00:16:06.759 if that wrapped exception isn't directly visible to the user, 333 00:16:07.159 --> 00:16:11.039 it might get logged somewhere, and those logs, they could 334 00:16:11.159 --> 00:16:13.080 be accessible to someone with bad intentions. 335 00:16:13.399 --> 00:16:15.960 Ah So even those hidden exceptions can come back to 336 00:16:16.000 --> 00:16:18.639 haunt you. It's like sweeping dirt under the rug. It 337 00:16:18.720 --> 00:16:21.480 might look clean on the surface, but it's still there. 338 00:16:21.559 --> 00:16:23.080 Lurking beneath exactly. 339 00:16:23.440 --> 00:16:26.320 And speaking of logging, the standard actually has a whole 340 00:16:26.440 --> 00:16:29.799 rule dedicated to making sure logging itself doesn't break because 341 00:16:29.840 --> 00:16:30.519 of exceptions. 342 00:16:30.799 --> 00:16:33.759 Wait, how can logging break? It seems like such a 343 00:16:33.840 --> 00:16:36.919 simple operation, just writing some text to a file or something. 344 00:16:37.039 --> 00:16:39.039 You'd think so, But imagine you're trying to log a 345 00:16:39.080 --> 00:16:43.320 critical security exception to the standard error stream. Now, what 346 00:16:43.440 --> 00:16:46.080 happens if that stream is closed or filled up? Oh, 347 00:16:46.120 --> 00:16:49.159 you lose that crucial information. Poof, it's gone. 348 00:16:49.320 --> 00:16:51.799 Yikes. So it's like having a security alarm that goes 349 00:16:51.840 --> 00:16:53.600 silent at the worst possible moment. 350 00:16:53.799 --> 00:16:56.679 Not very helpful, Not helpful at all. That's why the 351 00:16:56.799 --> 00:17:01.600 standard strongly recommends using a robust logging framework like Java, 352 00:17:01.679 --> 00:17:06.519 dot util, dot Logging, Logger, or log forge. They're designed 353 00:17:06.519 --> 00:17:09.279 to handle these errors gracefully, making sure your logs are 354 00:17:09.279 --> 00:17:10.759 always available when you need them. 355 00:17:10.960 --> 00:17:14.079 Right, So, even for something as seemingly basic as logging, 356 00:17:14.440 --> 00:17:18.359 use the right tools for the job. Solid advice. Now 357 00:17:18.440 --> 00:17:21.000 there was another rule that caught my eye. Do not 358 00:17:21.200 --> 00:17:25.680 throw undeclared checked exceptions. Why is that such a big no? No? 359 00:17:25.920 --> 00:17:28.960 Okay? So, in Java, checked exceptions are those that you're 360 00:17:29.000 --> 00:17:32.079 supposed to declare in a method signature. You use that 361 00:17:32.119 --> 00:17:34.920 throw as keyword, right, And that's so you're giving callers 362 00:17:34.960 --> 00:17:37.160 a heads up about what exceptions they might need to handle. 363 00:17:37.279 --> 00:17:39.559 It's like a warning label on a package. Handle with 364 00:17:39.640 --> 00:17:40.599 care may throw. 365 00:17:40.400 --> 00:17:44.000 Exceptions exactly, but there are sneaky ways to bypass this 366 00:17:44.039 --> 00:17:47.000 whole mechanism, like using reflection or the class dot new 367 00:17:47.000 --> 00:17:49.920 instance method. They can throw undeclared exceptions at runtime. 368 00:17:50.519 --> 00:17:53.200 Ah. So it's like sneaking a dangerous item into a 369 00:17:53.240 --> 00:17:56.279 package without putting that warning label on it. Someone's going 370 00:17:56.319 --> 00:17:57.519 to get a nasty surprise. 371 00:17:57.799 --> 00:17:59.680 That's a great way to put it, and it can 372 00:17:59.759 --> 00:18:02.599 cause all sorts of chaos because the caller isn't prepared 373 00:18:02.640 --> 00:18:06.480 to handle those unexpected exceptions. The standard is super clear 374 00:18:06.559 --> 00:18:10.160 on this, don't break the contract of checked exceptions. It's 375 00:18:10.200 --> 00:18:11.839 like a fundamental rule of the game. 376 00:18:11.920 --> 00:18:16.160 All right, no surprise exceptions, got it? What other surprises 377 00:18:16.160 --> 00:18:18.640 await us in the world of exceptional behavior? 378 00:18:18.799 --> 00:18:21.680 Well, another important rule is to always handle exceptions and 379 00:18:21.759 --> 00:18:23.160 finally blocks right. 380 00:18:23.279 --> 00:18:26.559 Finally blocks, those are the code blocks that always execute 381 00:18:26.559 --> 00:18:29.680 no matter what, even if an exception pops up. They're 382 00:18:29.759 --> 00:18:33.000 essential for cleanup tasks like closing those resources. 383 00:18:32.519 --> 00:18:36.119 We talked about exactly. But here's the catch. The standard 384 00:18:36.160 --> 00:18:38.759 warns against putting any code in a finally block that 385 00:18:38.839 --> 00:18:40.480 could itself throw an exception. 386 00:18:40.640 --> 00:18:43.039 Wait, why is that a problem? Wouldn't the finally block 387 00:18:43.119 --> 00:18:45.480 still execute even if it throws its own exception? 388 00:18:45.799 --> 00:18:48.759 It would, But here's the thing. If a finally block 389 00:18:48.839 --> 00:18:51.960 throws an exception, it masks any exceptions that were thrown 390 00:18:51.960 --> 00:18:53.279 in the triblock I'm masking. 391 00:18:54.079 --> 00:18:57.119 So it's like one loud sound drowning out another quieter, 392 00:18:57.240 --> 00:18:58.440 but more important sound. 393 00:18:58.759 --> 00:19:03.000 Precisely, you lose valuable information about the original exception that 394 00:19:03.039 --> 00:19:06.079 caused the problem in the first place. The standard even 395 00:19:06.119 --> 00:19:10.200 gives an example. Imagine a filestream that fails to close properly, 396 00:19:10.680 --> 00:19:14.440 and that resulting io exception masks a more serious security 397 00:19:14.440 --> 00:19:15.640 exception that happened earlier. 398 00:19:15.759 --> 00:19:18.799 So it's like trying to diagnose a patient's illness, but 399 00:19:18.960 --> 00:19:22.440 a minor symptom is hiding a much more serious underlying condition. 400 00:19:22.640 --> 00:19:26.680 Exactly. The takeaway here, Handle those exceptions and finally blocks 401 00:19:26.680 --> 00:19:29.960