Alice and Bob Learn Secure Coding: Chapter 2

Hi everyone. Hi. Hi Ray. Hi. Okay, so while people find their way in, how are you doing today? Pretty good. I could have got more sleep last night, but you know, it's going well. Okay, so now the video is going to start recording. I'm Tanya Janca, and this is my friend Ray LeBlanc, and this is Chapter 2 of Alice and Bob Learn Secure Coding. So when I wrote my first book, thank you, Alice and Bob Learn Application Security, I did streams like this to do free lectures, and I had a really great time hanging out with friends, talking about each chapter, answering questions for anyone that wanted to show up. And so for this book, I decided I would do the same thing. Another reason I decided to do these is because I don't have a PhD, I don't even have a university degree. I just have a college diploma from my local college. And so when I talk to universities about them teaching this or me teaching this, they offered me so little money that I realized that I could actually work as a Walmart greeter and get paid better. It was less than minimum wage, Ray. Yeah. I know. And so what I decided to do is that I would just teach it for free on my own terms. And so that is what you are attending today. So thank you for coming. So, Ray, can you introduce yourself a little bit? Yeah. So I'm Ray LeBlanc. I've been in AppSec since like 2011, and before that I was a developer. So yeah, I currently work in healthcare, but you can look me up on LinkedIn. I've worked at Zynga, Zappos—apparently I like companies that start with the letter Z. But I've worked at Cambia Health Solutions, which is also in the healthcare space in the past. But all of it is in AppSec and ProdSec, and that's what I love doing. Excellent. And so for those of you that don't know me, I'm Tanya Janca. Sometimes I call myself SheHacksPurple. I'm from Canada, that's the accent you're going to hear. Je parle français aussi, so I speak French also. And I write books about software security, or that's what I've been doing. I also give secure coding training, do AppSec consulting, and I have a whole bunch of things up my sleeve that I'm planning to start doing in the next year or so. But we'll do those as we continue. I keep seeing people connect and disconnect, and I'm not sure what's going on today. Today is Mother's Day, maybe a lot of people are realizing they're supposed to be somewhere with their mom. I took my mom out last weekend. But for everyone that did make it on, thank you. So, Ray, usually what we do is we kind of just go through parts of the chapter that my guest feels interested in talking about. What part are you thinking that you might want to talk about today? Or if you want me to take the lead, that's allowed too. Let's just start going down the sections and let's see how we feel. If we have light sections, then we'll just move on to the next, you know? I like it. So the first section—so for those of you that don't know, the book is about secure coding. And section two I call 'Beginning', which is the beginning of the agnostic advice. So this applies to every single language. And my first piece of advice, Ray, is we should follow a secure system development lifecycle. What the heck am I talking about there? I'm assuming you're talking about like an SSDLC, like Microsoft has one that you can reference. But basically it's—how would I put this? You have a software development lifecycle or a system development lifecycle, and then you have the security steps that go with each of those phases, I would say. I think they're all pretty standardized now. I think they kind of all look the same, don't they? I've used the Microsoft one for such a long time, that's kind of the one I've stuck with. Okay, I'm going to disagree. To me, okay, so I totally agree with your definition. So however we're building software, whatever system development lifecycle or methodology we're following—Agile, Waterfall, DevOps, or some mishmash of two or three of those, which is usually what actually happens—and then adding some sort of security activity, at least one, to each phase that we're doing. That's the way I see it. But that's not what I'm seeing in industry. Like, I'm seeing a lot of places where—so when I go in and give training, Ray, it's all over the place. Some of them have tons of security steps, some of them have almost none. Some of them will tell me, 'Oh, we don't have a secure system development lifecycle,' but then they're like, 'Oh, but we threat model, then we do design reviews, then we do this, then we do that.' And I was like, 'Oh, it really sounds like you do have one, you just don't have a name for it. But yeah, it sounds like you're doing it, right?' Yeah. Yeah, I mean that's exactly what you would do in an SSDLC, right? You do threat modeling, you do reviews—code reviews, design reviews, things like that. So yeah, you're right. They probably just don't call it that secure system development lifecycle. They probably just say these are the actions that we do. So how would someone—so let's say someone's a software developer and they work somewhere, and they do, let's say they're doing Agile, and they're trying to move to DevOps. So they're doing Scrum meetings in the morning, but they're starting to use a CI sometimes, and they're trying to move towards DevOps, they're not really sure. And right now they run SAST sometimes, and they're allowed to ask the security team questions, and sometimes there's a pen test. What could they do maybe to try to have a bit more of a secure SDLC? If you're able to run SAST sometimes, you're probably able to run SAST a lot more. So I'd probably start there. But I think that's a good start. It's better than nothing, what you just described. But what I'm hearing is—what I would look at is how mature is their development lifecycle just on its own, right? Because from what you just explained, I would guess it's probably just as immature, or maybe a little bit more mature than what they currently have going on on the security side. Especially like, 'Oh, they're just starting to use continuous integration stuff,' right? I think that's just a maturity problem in their development org that security wasn't able to bolt on those little extra phases possibly. But I don't know if you have to do it more. More is better, like scanning more often is better for visibility. But if you're scanning once a month, I probably wouldn't recommend that, but it's better than not scanning at all, right? I think what you're wanting to do is slowly mature over time. Adding too many security activities at once may cause an undue burden on your developers. So rolling it out piecemeal and then getting feedback from your developers, right? And really customize your SSDLC to how you work. You don't want to use anything out of the box because no one works like—no one's taking these steps and just saying this is how we do development also. No one's doing that. Everyone has their own preferences, teams, and the technologies you use sometimes dictate how you have to do stuff. I agree with that too. I want to let the audience know that you can put a question in the chat, and assuming it has anything to do with the book, we will answer it. Or even if it's just about application security in general, or industry, et cetera. Last time we ended up getting onto quite the conversation about careers and getting promoted and stuff like that. I would add, Ray, so if you have a mess of a system development lifecycle where everyone's kind of doing their own thing, and everyone's kind of all over the place and following different processes, everyone should take what each of us say with a small grain of salt because both of us have confirmation bias and both of us have certain experiences, so that's what has worked for us. It doesn't mean it will necessarily work for you. But I would try to add security requirements to every new project. So if you have my book, just go to chapter 5, and I've actually written out all the requirements for different technologies—so serverless, WebSockets, APIs, et cetera—so that you can just take the parts you like, and then just apply that to every new project if you can. So you're making an API, it's like, well, if it's public-facing, I want it to be behind an API gateway. I have a bunch of things that I would like to see. And so if you give developers guidance from the beginning, I think you'll get way, way, way better results. And then the other thing—and this is where the grain of salt comes in—is if they've never had any secure coding or security or secure AI training at all, you have a whole bunch of developers that feel really uncertain what they're supposed to be doing, what they should be doing, or what they could be doing. So whether it be you buy some sort of online computer-based training course, or you send them to a conference, or the pre-conference training, or you hire a nerd like me in—there's a lot of options. Or you can buy them a book! Buy them my book, yeah, right? And then send them to these free streams, right? That is a really cheap option. And a bunch of you could share the same copy of the book if you really want. So do something like that so they know what you actually want from them, because they are not learning that in university, college, and boot camps. And so then from there, try to just be available to answer questions, which obviously is really hard because security people are usually quite overworked. But if you can make it clear that you're available and you want to help, that goes a long way, I find. Yeah. And some other tips: at my current job, our developers have office hours, so I'm starting to go to those, so I'm just available during their office hours. And that way also, I'm able to hear the discussions that are happening. So if I need to weigh in from a security perspective, I can kind of see what different teams are working on or having trouble working on, right? Because usually the office hours, they're talking about issues that they're having. So... I love that. Lunch and learns are great. OWASP has a lot of great resources that you can easily convert into lunch and learns. When I was at Cambia, my first year there, basically every month from February through November, I gave a lunch and learn on one of the OWASP Top 10s. It was just like a 20-minute thing, and I left 10 minutes for questions. Yeah, to share knowledge, that's awesome. Also, if you're using AI, build out those skills for your developers to use. That's one of the things I'm currently working on at my current job, and it's interesting, it's fun. And it can be always there for developers, even if you're offline. So that's nice. Okay, I have a new topic. So the next one is 'Use a modern framework and all available security features within it.' What do you think? I like the use of a modern framework. I would say use all available security features that make sense for your org. Because a lot of people will use—in the Java world, let's just talk about Java frameworks, for example, like Spring Boot, Struts 2, things like that, right? Sometimes people don't use the auth and the session management in those because they don't like how it does the auth-n, for example, and they want to use Cognito instead, or something like that, right? So you have to make sense of how you want your flows to work and kind of use the security features that will help those controls and not force you into a pattern you don't want. Okay. For those of you listening, you can ask questions by posting a comment. So sorry that there's a lack of clarity there; there's not like a box that says 'ask questions', you just put a comment on the video, and then we'll see it, and then we're able to answer it. And we're live on LinkedIn, YouTube, and Twitch, but there tends to be the least number of people on Twitch because I never use Twitch. Not that there's anything wrong with it, I just am more active on other platforms, and that's okay. Ray, the next one's 'Input validation'. Do you think we should do some of that? Yeah, I think so. Don't bother checking! Now let's get into coding advice. Yeah. That was the first sentence of that section. Yes, input validation is definitely a useful control. I mean, you have the client-side validation, which you want to primarily use for improving user experience. You want to allow them to—that client side is just to give your users feedback. Don't rely on that for security, right? Agreed. Everything needs to be on the server side, and anything on the client side should also be parodied on the server side. The server side doesn't always have to be parodied on the client side, but for usability that's good. When we say input validation, what I think—I'd love to know if your definition is different, and it's okay if it is. So to me, input validation is every time data gets sent to our system, we should check that it's what we're expecting before we do anything with it. And if it's not what we're expecting, we just say, 'No thanks, try again. These are our requirements, but no thank you, you've made a boo-boo, I don't want that.' That's what I'm thinking. Yeah, no, I would agree with that. You're checking to make sure, like if you're expecting a number, that you're getting an integer, right? Some data forms are much harder to— Like a date. Ideally, your front end would send the correct format. But yeah, you should still check your date formats to make sure that it's what you're expecting. But it's harder to validate comments, for example, right? It's harder to validate—I've seen some weird last names, right? There's weird addresses that aren't necessarily standard, especially if you're moving outside of US, North America, how other countries have things structured may be different from ours. There's this meme I really like of Excel and incels, and there's a small overlap, and it's like 'thinking everything's a date'. We want to make sure—so in the book, I use a date of birth, right? So a date of birth, it not only needs to be a date and it needs to be the right format, whether it be MM/DD/YYYY or DD/MM/YYYY or whatever the format is that you want, but then also it should probably be in the past, right? You can't really have a date of birth that's in the future. Yeah. It probably shouldn't be more than 150 years ago. Yeah, so that's a good segue into the different input validation strategies. You have syntactic validation, which is like, is the syntax, is the structure field, like dates, is the currency symbols used correct, is your Social Security number in the US three-two-four characters, right? And then you also have semantic validation, which is kind of like what you just talked about: is the start date before the end date, is the price within the expected range, right? Are values within ranges? So that's kind of the two ways to think of the different strategies of input validation. There's a question in the chat that I want to put after, but for now, I just wanted to add a comment that someone had: 'What irritates me is having to put in a state on my address for countries that have no states, or where the postal system doesn't use the state as part of the address.' Oh yeah, I'm so with you on that one. I would say, so I see some problems with input validation, Ray, when I review code, and often it's that the developer doesn't think that it's input, so they're not validating it. So they're like, 'Oh, I got it from the database.' I'm like, 'Yeah, but the database is full of user input, and it was put there by some other API that you didn't write. How do you know they did good validation?' Or you're getting it from another third-party API, like Google Maps or something, and then you're not validating what you're getting, and I'm like, 'What if Google's having a really bad day?' Right? I've never seen validation on those use cases either, at least often. I probably have run across it, but not enough where it sticks into my memory. So I would agree. I also generally haven't in the past recommended input validation from databases. I don't think that's terrible advice, but it is something you should probably consider depending on your threat model. Yeah. How serious it is, the threat actors that you might be facing. When I work with different companies, some of the companies, the threats that they're facing are huge and terrifying and scary, and some of them, I'm like, 'Well, you sell custom t-shirts online, and I just don't think a nation-state is really targeting you right now.' So maybe we could calm down a bit. It really depends. There's a question in the chat from Evan: 'On Frameworks, when speaking to new engineers, there is a gap in awareness of frameworks and what frameworks exist for ecosystems. Given there is a lot out there, do you have guidelines to help developers discover and assess what frameworks' capabilities they should have before they get attached to something?' Do you have any advice on that, Ray? Read the docs. I mean, unless they have here's all the security features—and they usually do, right? Frameworks usually talk about their security features. There's usually a best practices security page. That's probably a good place to start. But really, if you're using a framework, you should kind of know how the framework does its things, I would hope. I mean, maybe I'm just an old-school developer, and that's an old-school way of thinking, but I still feel that way. Get to know your tools, get to understand your tools, get to understand the libraries that you're using and the frameworks that you're using. There's a lot of benefits for that: performance benefits that you can gain out of knowing alternate ways of using your libraries or frameworks, better ways of doing security, things like that. I think he meant choosing which framework to use. So for instance, if you're using Java, there's a bunch of options, but Struts and Spring Boot are the most common, and I would suggest Spring Boot because it has more security features and it's more modern, and because Struts made my life complete hell in 2016 and 2017 because of all the remote code execution vulnerabilities that were in it. And so I have feelings about Struts. As a ProdSec engineer, I'm not in the position to dictate to devs what libraries and frameworks they should be using. But I can recommend or write guidelines on what capabilities their frameworks should have, right? And then I can audit those frameworks and be like, 'Hey, they don't have these capabilities. What libraries are you going to use to enhance these things, right?' And then also go do the research for them. I feel like if you're a company and devs are just picking new frameworks, you're probably not the most organized in a lot of the cases, if they're able to just run around and choose whatever they want. But I think that's kind of how it goes now. Yeah, talking about maturity. So I think it's kind of on you to make sure that the frameworks are secure as a security person. We have SCA that scans the libraries, they scan the framework libraries. You should have those SBOMs and figure out what the devs are using, and develop guidance for them rather than telling them how they should work, like 'use these tools'. I would personally like to try to influence as best I can that they will choose a more secure option or ecosystem. I don't always get my way, but if I could attend the option analysis meetings or have my input be part of it, I would really like that. Start befriending your senior, staff, and principal engineers, because those are the ones that have a lot of those influences. Figure out in your org who's making the decisions, the technical decisions, who has influences on the dev side, like you just said, right? And have coffee, or tea, or beers, or water, or whatever it is you drink with that person and become their friend. A comment: 'Many developers don't understand the code generated by AI models.' Yeah, I definitely think that there are a lot of people generating code right now and aren't able to understand all of it, and I feel like if you don't understand it, you should not check it in. I don't agree that they aren't able to understand it, because I do believe that most devs out there are able to understand the code, but whether or not they really do a code review to understand the code—maybe that's what you're getting at, but I agree with that. When I have AI generate some scripts, sometimes depending on what the use case of the script, I just run it. I'll do a quick security review just to make sure it's not doing anything crazy. But I think AI causes some bad practices that we may not want, that it's enabling bad habits. Yes, it does allow you to be a little bit lazier than you normally could be before everyone had access to AI. So I get that, and it's something that I fight with myself about. I want to say one more thing about input validation before we go on, and it's that— Sometimes you have to accept dangerous characters. And it is my opinion that we should include that in whatever we're validating for. So we make an allowlist of what is allowed in, and we include those special characters. And then after, you can escape them, or you can sanitize them out. Everyone always says sanitize, which means removing or replacing a special character with something that's not dangerous, but I think escaping is way better, which is just putting a backslash in front, and it takes the power away from that special character. For me, if you remove the character or replace it with something else, that can lead to potential confusion later, and I don't like it personally. So that was my thought. What was your thought? I have both of those in there and I have one more. There's allowlists and denylists. We want to prefer allowlists, but that's not always doable. Denylists are just a little bit easier to implement and manage, they're less time-consuming. But we want to try to default to the most secure if we are able to. The sanitizing, escaping, encoding—I agree, escaping changes the context so it eliminates that special power that those characters have. I prefer escaping over just removing the elements, because also if you're removing an element, maybe the person intended to have that element in there. Maybe they didn't intend it as malicious, like a script tag, maybe they want to put a comment in and say, 'I want to show someone this comment, like script prompt script, for example.' And I want it to show up rendered as script prompt script, and if you remove that script tag, you're just going to see prompt, and it may not be useful to the intended audience. And that's where you're getting into output encoding and things like that on top of the escaping. And then the last thing I want to talk about with input validation is the timing of validation. So when you validate matters. If you validate too late, you want to validate right before you're using that data, right? You don't want to validate when things are still happening, if the data is able to change. As soon as you get it, you assign it to a variable and you validate it. Validate as you assign it. I'm just talking about timing of validation in general. You want to validate when it makes the most sense to validate. No, just validate right when you get the thing, before you do anything else. No? Why would it not make sense to do it then? Because then you can't accidentally do something else with it. I mean, yes, I guess we're saying the same thing. I'm saying we're validating before we're using the data. Yep, sounds good. We're just saying it differently. That's okay. There's a comment in the chat I wanted to talk about briefly: 'I know it's cliché, but I feel lost about my talent and skills. Everyone says I like computers and should do engineering, but I'm still unsure and want to figure out what my real passion and interest is in.' I think a lot of our jobs are really, really changing right now. I give training and I give talks, and my training is completely different every time I deliver it now. I have to rewrite it every time, because something has changed so much from last month to this month, and it is exciting to be learning new stuff, but it's also exhausting and it makes every contract like three times as much work. And what people want is changing. I'll actually go to give training, and sometimes they're like, 'Oh, by the way, we laid half the team off last week.' Or sometimes my contract didn't get signed, and they're like, 'Oh, we just laid everyone off, so we're not going to do it now.' That's happened twice now. And they're like, 'Oh, we're just going to have AI write everything.' And I'm like, 'Well, see you in a year when you have a giant mess you need to clean up.' But in the meantime, a lot of things are changing, and a lot of people are really nervous. Everything we do is changing, and I've had people say, 'Why train my devs? Why do they need to write secure code when they don't write code now?' And I'm like, 'Because they need to review it and know it's not—because what's coming out of there is below average, and average coding is insecure.' What do you think, Ray? If you train on garbage, garbage in, garbage out, right? I think it's getting better, but I think a lot's going to change in the next two years, is what I'm going to say. I don't know how it's going to change, and there's a lot I do not know about it. We were talking before the stream, and both of us were like, 'I wish I could skip ahead a year and see what it's going to be like so we could get ready.' Yes. Or just so we could just know. I don't like ambiguity. I enjoy certainty. Most people fall into that boat. I think most people like certainty, especially around jobs and things like that. Absolutely. So are we done input validation and maybe we're going to do output encoding? Yeah, let's go output encoding. So if we're going to do webby stuff, and things are going to go into a web browser, a web browser has an interpreter, and we want it to only interpret our code, right, Ray? That's the goal. We don't want it to interpret someone else's code on our sites. That is not the goal. Sometimes that is the goal, but not if it's malicious code. Only with consent! Consensual interpretation. We don't want cross-site scripting. Cross-site scripting is basically when someone tricks your web app into thinking the data that they entered is actually code, and that it's part of your app and it should definitely interpret that too. It's not a good deal. And so what is one of the main defenses we could do against that, Ray? Output encoding. Yes! What the heck's output encoding? It's basically encoding the data you're sending out into a form that is not going to cause—encoding is basically just when you transform between logical representations of text into a well-defined sequence, I would say. So that it can't be interpreted anymore. Yes, yeah. When we're talking about output encoding, we're not always talking about XSS, we're not always talking about HTML or JavaScript, because we have URL encoding, we have HTML attribute encoding, JSON encoding, JavaScript encoding, CSS, right? All these different contexts have different ways that we need to encode, and they all carry slightly different risks. And we do it so that if we are going to present something in the browser to the user, that we just present exactly the text that was entered, and we don't accidentally have a cross-site scripting vulnerability where a malicious actor would be able to try to steal our session cookie, they could try to run external scripts, they could try to have a pop-up box, which is the least dangerous thing that there could be. We don't want them to embarrass us. There's the browser exploitation framework, BeEF, where it hooks into your browser, flips on your webcam, starts recording you, basically terrifying. Yeah, we don't want any of those things. Ideally, we're doing input validation, ideally we're doing output encoding, ideally we're also using Content Security Policy header, but output encoding works. Absolutely. That is a 100% control you need to do, it's a requirement. That should just be in your security policies: you need to do output encoding. Oh yeah, this is why it's the second thing that I teach, unless I'm teaching a non-webby thing, like C or something. For those of you that are just joining us, you can ask questions by posting a comment on the stream. I can also field questions on beginning piano, or gardening. Or we're talking about Chapter 2 of Alice and Bob Learn Secure Coding. And the next thing that was in the chapter was parameterized queries. What the heck are those? Why would we do those? What's wrong? Why would we want to do that? Because we generally don't like SQL injection as a rule. Injection is bad, I agree. Using parameterized queries are a safe way to get untrusted input into a database, right? Whether that is a query, or you're creating an entry, updating, or doing whatever. We don't like that untrusted input. Basically anything coming from outside of your application is considered untrusted, even if it's coming from another service you own, it is untrusted to that one particular service. Injection is where essentially our app is confused by a malicious actor. A malicious actor has put something into a data field or data input of some sort, our app accesses it, it thinks, 'Oh, that's code, I should execute it,' and it might be compiling it or interpreting it, but either way it gets executed. And then we run the bad code by accident. And so when we're doing cross-site scripting, like in the last section, we're talking about output encoding so that we can avoid cross-site scripting. Basically, it's a subtype of injection, and the most well-known type of injection is SQL injection. Databases have a lot more functionality than a lot of people think. Yeah, and they're behind your firewall. They're a server behind your firewall on your network, in a very important part of your network if you do zoning, so it's in the data zone. And so then if you have a poorly patched database server, they could potentially take over that server, potentially pivot, which means go from computer to computer. That's a worst-case scenario. But a best-case scenario is they're seeing a bunch of data they shouldn't see, they may be updating or deleting data. This is confidentiality, integrity, availability—bad, bad, bad. With parameterized queries, sometimes you'll hear people use parameterized queries and prepared statements interchangeably. They're different, but a good way to think about it is a prepared statement is like a reference to a pre-interpreted query that is ready to accept parameters, whereas the parameterized query is an operation that generates the prepared statement and then passes the parameters to it and executes it, right? We call them the same, and different frameworks and libraries may interchange it. Essentially, those two are the same, and then we have ORMs. What are they called in MS SQL? Stored procedures. I just called it stored procedures forever, and eventually people pointed out that stored procedures are absolutely not universal. Stored procedures are like—prepared statements and parameterized queries usually live in the codebase, where stored procedures are stored on the database that get used, but it is basically a prepared statement as a stored procedure. When I was a developer, one of the big patterns was writing your business logic in the stored procedure because you could change the business logic easier without changing the code. I think that's a terrible idea now, but that was a big pattern back around 2005, 2010 maybe. Oh, I did that! I did every bad thing. It's crazy when you have different databases calling each other within stored procedures, because then you get really— No, oh wow, okay. Oh my. So we do parameterized queries or stored procedures specifically just so we can say these parameters, these are data, never execute what's in here, only treat it as data. And then injection—it's just faster. Oh, and someone else is pointing out stored procedures are faster and compiled. Yeah! And if your devs aren't using it, just be like, 'Do you not care about performance?' Yep. But what about ORMs? I actually don't know how much more performant it is, but I'm sure there's probably a performance impact there. ORM: Object-Relational Mapping frameworks. So it's a framework for a database that makes things more secure. I've only ever used one at work, and it was the Entity Framework for .NET. And it was such a pleasure. It wrote all the basic calls for me, it saved me a ton of time of writing really boring stuff. I didn't know at the time that it added an additional layer of security and it helped make sure I used stored procedures and just follow best practices. At the time I was like, 'Oh, this is saving me time,' with no idea there were positive security implications. Yeah, ORMs can be vulnerable to SQL injection if you use them inappropriately. You could still put raw queries in it, you can still format things wrong if it lets you, which can lead to SQL injection. So just because you have an ORM doesn't necessarily mean that you're secure. You still have to follow their best practices and use things the way that they were intended to be used. Twice I have reviewed code where the stored procedure or the prepared statement, what it does is it has one parameter, and it takes that parameter and then directly executes it against the database. And one of the times the dev was long gone, but the other time the dev was still working there, and I'm like, 'Dude.' And he's like, 'Well, the policy...' I'm like, 'Dude.' And he's like, 'Yes, ma'am.' 'You go fix that now.' 'Yes, ma'am.' I do not promote underage drinking. But mostly because we both haven't been under age in a very long time. Yes. There's a comment in the chat: 'What would be the one single most valuable tech skill to learn in today's era that would be never replaced?' Tech skill? I wouldn't call it necessarily a tech skill, but I would say critical thinking. If you are better at critical thinking than your co-workers, you are going to do better in the age of AI, I think. Okay, I like that. I would say two skills. One is a tech skill, and that would be becoming very, very good at prompting the AI. I think that if you don't know how to drive it, you're going to get terrible results, and I think that every single job going forward pretty much is going to require use of AI, every single tech job. And so if you don't know how to work with the AI at a basic level, you're going to have problems. So just how to get it—because the first year that I used it, I'm like, 'It's so stupid.' And then I learned how to give it enough context, and how to explain, and then all of a sudden it's gotten better, but I've gotten better. And then the other one would be, so if you want to get promoted, you want to get a lot of work done quickly, you want to be treated better: communication skills. Maybe we could call it soft skills, but understanding how to communicate what you want or need clearly, and the hardest part for me, understanding what the heck everyone else is saying. I used to have a lot of trouble getting things across in a super professional manner. I don't mean that I was rude, but I mean personally I had problems with being too forward and too blunt and too direct, and it made people uncomfortable when I was younger. Ray's like, 'You still do that.' No, so much better. That is exactly how people would describe me at work. I try now to give some more background, to lead someone up to tee off the thing before I ask for the thing, instead of just walking up and being like, 'Delete this database table.' You have to learn how to be a team player. If you rub the devs the wrong way, you're not going to do well. You have to get them on your side, they have to want to work with you. There's another question: 'What Python and Java books for challenges and exercises do you recommend, and database books?' I don't have any, but I do suggest 'Talk Python To Me', which is a podcast with this guy named Michael Kennedy, and he really dives deep in all of his episodes, so for Python, 'Talk Python To Me' is really good. Another good one about Python is 'Automate the Boring Stuff with Python'. For Java, I suggested in the book reading the secure coding guidelines provided by Oracle, but they're 80 pages. It's a tough read. And then also there's the CERT Oracle Secure Coding Standard for Java by Fred Long. As for database books, unless you're trying to be a DBA, I don't know how much actual database knowledge you need as a developer in 2024. Yeah. Let's move on to authentication and identity, if that's okay. Yep, let's do it. When I say authentication, to me that means the computer verifying that you, the user, are the real you, or that the computer it's talking to is the computer it thinks that it is. It's identifying that person, it's the act of recognizing them. And then identity is your user on the network. Do you agree, disagree? I think that's a good, solid definition. I'm not going to disagree with it, for sure. And then authorization, which is going to come next, is basically deciding you are or are not allowed to access this or that, and that could be a page on a webpage, it could be being allowed to use a feature, it could be being allowed to return this record or which parts of the record. And then the access control is controlling whether you can do it or not; it's the actual security control of allowing and disallowing. When I was reading about authorization and access control and identity and all of that, one of the things was that there's different models that you can follow. And honestly, Ray, I was switching between them based on context, and I had never really named a lot of them or thought of it as, 'Oh, I'm using a different—' I was just like, 'Oh, it's just access control,' and not realizing that there's different models. Is it okay if I go over the models? Yeah, let's go over the models. The first one's Mandatory Access Control, or MAC. I used this in the government all the time. Things would be Protected A, B, or C when I worked in the Canadian federal government, or they'd be Public, Secret, Top Secret, and then above Top Secret there's a tree, signals intelligence was one that I dealt with. Recently I found out that Top Secret in French is 'très secret', which means 'very secret'. And I find it the most adorable, cute thing ever, and I want to get a t-shirt that just says 'très secret'. I like it, I like it. Basically, there's levels, and if you are that level, you can have everything that's that level and below. And it's often in military or government, and it's not that often in private industry that I've seen stuff like that personally. In private industry, you usually see RBAC or attribute-based. Yeah. So let's talk about RBAC: Role-Based Access Control. That's the thing that I kind of just always associated. When I build software, I just always assume RBAC, which is if someone's a database administrator, that's the role they play at work, those are the things they get to have access to. I'm a developer, so I get all the developer types of access. Someone's an executive, so ideally we give them nothing. Sysadmin, they have the superpowers, right? And based on your role—so if you're the administrator of the app, you get all the superpowers, let's say. But if you're a guest user, you don't get to do very much at all. Role-based access control is probably one of the more standard ones to implement. I think it's easier to think about, because it's like, 'I have this role, this role gives you access to these things.' And sometimes you can give people multiple roles that have access to multiple things. A lot of the access control models are how you think about giving access and then implementing that pattern versus attribute-based access control, where users or resources have attributes, and then it's just like, 'Okay, you have this attribute, this resource has this attribute, you're good.' Yeah, exactly. For me, it seems just so super logical. But then the next one that is in the book is DAC: Discretionary Access Control. And that's where whoever makes the thing gets to decide who's allowed to access it and how. And this can be good and bad. So let's say I'm at work and I make a document, and quite frankly, at first when I'm working on something, I don't want my team to see, because usually it's stupid, right? I just put random thoughts on the page, they're sort of all over the place, and then slowly I form ideas and it gets better and better. And then I'm like, 'Okay, another human being can see this, it doesn't look stupid anymore.' And then it's like—so I'll work locally maybe, and then I'll put it in a shared place and I'll ask for feedback or something, right? But like when we use something like Google Docs, we give access or we don't give access, and we'll say, 'Oh, this person can just view it, or they can edit it,' et cetera. Yeah. I think the use case makes sense in certain scenarios, but at a past job, I did some Google Workspace admin work, and I would say that I absolutely hate that method as an admin. Seeing who has access to everything and locking down resources, it can be tricky sometimes. I also found people would play little games. So when I worked in the government—and the story's in the book—I was talking to another team lead, and the security team had—so I was lead of the developers, surprise! For a long time I was the senior dev for almost a decade before I switched to security. And here I am, the leader of all the devs, and the security team's like, 'Oh, you have to fill out these long forms from now on for every single project.' And I was like, 'Oh my gosh, kill me.' And so I was complaining to the guy that was in charge of all of the COTS products, so the customizable or configurable off-the-shelf products, like SharePoint, PeopleSoft, stuff like that. And I was like, 'Literally, it's like my full-time job to fill out these effing forms now. I have work to do, and they seem to be offering like zero value, the questions they ask are so stupid.' And he's like, 'Oh, just don't fill them out.' I'm like, 'I have to.' And so what he would do is he would copy the form, change the name to whatever his project was, and tell them it's finished and send them a link. And he's like, 'And I would just not give them access on purpose.' And then of all the times in the past year, of my 28 projects, twice they said, 'Hey, I don't have access.' And then you know what I did? I just worked late, filled out the whole thing, and pretended I didn't see the email till the next day, and then sent it to them as soon as it was done and said, 'Oh, sorry, I just screwed up my permissions.' And he's like, 'So I didn't have to write like 26 of them.' And I was just like, 'What the—they're not reading them?' I was furious. Have you ever dealt with compliance? Like, I'm pretty sure most answers don't get read. I'm pretty sure most SOC 2 reports never get read! I feel like I deserve an award for not setting the building on fire, I was so pissed off. So then I say to the security team, 'You're not reading them, so I'm not going to write them. Tell me if you're going to read it and I'll write it.' And then of course, they're like, 'That's not okay,' because I just say my stupid thoughts out loud sometimes. I don't think it is a security problem, I just think this is a human problem of path of least resistance. You look over it and it's like, 'Oh, I don't have access, I'm just going to move on to the next thing,' you know? Or maybe they were reading mine and not reading his because they didn't have access to his and they did have access to mine. Maybe. I think it's disrespectful to ask people to do work that you're not even going to ever use. But I have a lot of thoughts. I would agree with that. I think it's a waste of time. Okay, so we have a question in the chat: 'Do Java developers think they can't do much in AI without Python? Is that a myth or a reality?' I've never heard of this. I don't think you need to know Python to use AI. So I think it's maybe a myth then. The last access control model—so there's lots of them, but the last one that I put in the book was rule-based access control, which has the same acronym essentially, RBAC, but online some people put like RB-RBAC, and I was like, 'Wow, that's not super confusing at all.' But basically that one is rule-based. So let's say most of us work between 7:00 AM and 6:00 PM, so things are only accessible during that time, right? Or maybe your door pass only works until a certain hour at night because people shouldn't be in the building past midnight or whatever. Or maybe if you exit the building past 6:00, you can't get back in. Stuff like that, like rule-based access, or you can only access these things when you're on the VPN, but from outside the VPN you can't, or whatever. Logic-based rules. Yeah, I don't have much more to add to that one, unfortunately. You don't see them a whole bunch in that way of like, 'This web app is only open from 6:00 to 8:00 at night,' or something like that, but you do see that actually. I have seen apps that are only usable in certain hours of the day. And I guess that may allow them to not need after-hours support and things like that, or whatever their business use case of doing that is. It's weird to see them now. That was more common years and years ago when we were getting started, but I'm sure that still exists, right? I don't know, I think that COVID changed everything. In Canada, you couldn't see a doctor before on the phone. So even if you were renewing a prescription that you've been taking for all of your entire life and you've had the exact same dose for a decade, you'd still have to go into the doctor, sit in the waiting room, go in, physically see the doctor so that they could just be like, 'Yep,' and then leave, right? And then with COVID, now I can talk to my doctor over the phone. You should have just had them bundle in a bunch of extra tests so it was worth your time to do that! Just test me for random things that don't matter! Let's spend money! The next one's session management, but I'm kind of more interested in talking about secret management. And I was wondering if you wanted to kind of take it away for a second and explain what we mean by secret management? By secret management? What are secrets, and why do we care? Why should they not be in our code, or should they be in our code, Ray? Oh yeah, they shouldn't be in our code. So with secret management, ultimately, we hate hardcoded secrets, 100%. Like if you're in AWS, we want to use KMS, right, to generate our secrets. We want to use external or internal tools. I forgot what she wrote on secret management, so I am going to look it up really quick. I think... You don't have to say it the way I say it, but basically secrets are what computers use to authenticate to each other, to say, 'Hey, I'm this API, what's up, can we chat?' And it's like, 'Hey, I know that face. Okay, that's cool.' Right? Secrets are for computers, where passwords, passwordless, et cetera are for humans. And so secrets are how they recognize each other. And then secret management is what the heck do we do with those, and how do we make sure we keep them safe? Why secret management's important is that it should help with the entire lifecycle of the secret, right? One of the hardest things is rotating your secrets. And secret management systems should be doing that for you so you do not have to worry about it. Yes. Well, and ideally, so when I went to college in the '90s, they taught me put all your secrets in your code so you don't lose them. And you should have, for instance, your connection string to your database, which had passwords in it, put prod, staging, QA, dev, all the different environments in your comments so that you don't lose any of them. You'd have them all in your config file too, and you'd pump that config file out to all the different—you'd have a prod.config and a dev.config and it'd have your database connection string with your username and password. Man, we were so bad at security back in the day, weren't we? But that was the best practice at the time. There was no real other solutions that we had access to. Ray, there's still so, so many companies where I'll come in to consult, and I would say maybe a third of them, I'll talk about and then you store it in your secret management tool, and then the devs all look over at the security team with these death stares, and they're like, 'We don't have one.' And they've been asking for it often for years, and the security team's like, 'Oh, it's still in evaluation.' I'm like, 'Are you kidding?' And so then the security team's doing pen tests and reporting to them, 'Oh, we found your secrets,' and the devs are like, 'Yeah, we know!' And there's like this friction that you can cut with a knife. If you don't give them the easy path, they're going to carve out that easy path, right? You don't give them the tools to be safe, they're not going to be safe, unfortunately. Yeah. And I'm sorry, but what are you evaluating? Like, 'Oh, we're doing a proof of value or a proof of concept.' Yeah, but that shouldn't take a year or two, right? Also, all the major cloud providers have an offering for this. I mean, evaluating that doesn't make as much sense as evaluating lambda. It's just a service. A year is a bit overkill. Like I don't know how in-depth their evaluation was. Maybe they were doing an internal code review of AWS's code or something, maybe they're doing pen tests on it, I don't know. No. So before we got on, you and I talked about how I advise that people should ideally, if they can, buy a solution that does complex security things like identity or secret management, et cetera, rather than writing your own. And then I am a hypocrite, and I put how to store user passwords. How did you feel about that, Ray? I haven't given advice for somewhere between five to ten years on how to store a password, because there's Auth0 and Cognito, all the different cloud service providers have their own stuff, frameworks are baked in with it if you decide to use that part of your framework. I haven't seen a lot of recent applications that my teams have been building where they're wanting to accept people's usernames and passwords. I think that's a risk that if devs can just not deal with that, they should absolutely not want to deal with that. Yes. So for the record, I would rather we use passwordless systems whenever we can, because users suck at managing passwords, they don't enjoy it, it makes it less usable, and also generally it's more secure if we use a passwordless system. And by that, I don't mean we just let anyone use anything. I mean that we authenticate them and authorize them in a different way. But a ton of legacy things exist all over the planet, and lots of people are still designing new systems that use a username and password to authenticate. And so as a result, I wanted the advice to be in the book so that people, if they're going to do it, they do it better. If you're not an identity company, you don't want your devs probably writing the identity framework that your company's using. Ray, when I teach, at least 50% of companies are like, 'We need that module, because we're doing it.' Yeah, I've helped roll out a custom implementation of service-to-service auth at a previous job. It took a very long time. We had some very custom use cases that OAuth did not—we didn't like the OAuth flow for it, so it made our development weird, so we kind of designed our own, and it was based off OAuth. But the resources that was put into it—it was a whole team for like six months working on this damn thing. I was doing constant reviews of it, all the other security people basically had eyes on it, and then we hired an external third party to do a full code review and audit and pen test. And each year, we had a pen test on that one particular piece, and it was a lot of resources for—I don't know exactly how much we really gained from it as opposed to just using a service mesh, right? Yeah. Whenever developers are like, 'I could just make my own authentication, authorization, session management, identity, or whatever,' this is how I word it: Microsoft makes Active Directory. They're one of the oldest software companies in the world, they have half a million employees and another half million in contractors approximately, and they measure their profit per quarter in trillions. And they still have bugs. But you think you can do better off the side of your desk, eh? That's some sweet arrogance. The amount of money it's going to take to develop it is one, but to maintain it, to make sure you have proper testing of it, it's ridiculous. Why on earth would you—how could it possibly ever be cheaper to do it that way, unless you do a terrible job? Versus also, that's time where you could be building super cool new features for the actual product that your company sells that could delight your customers and differentiate you from your competitors and all of the other things, and get you promoted. Yeah. That's really what I want, because if I have equity in that company, I also want that company to—I want it to be secure, but I want it to have also really cool features that hopefully make me more money in the future. But that said, it's just not a good use of resources to do some of this stuff. And if you're not making money off of that thing, or you don't have a very specific use case that you can't really get around it, the maintenance cost—the time spent on maintenance versus adding new features is disproportionately feature-based versus maintenance-based. And that's something that you have to consider when you're authorizing your devs to do things like this: will they have time to actually maintain and fix it? Oh yeah, it's a real cost. Yeah. So for those of you just joining us, you can ask questions by putting a comment on the event page where you're watching it, whether that be YouTube, LinkedIn, or Twitch. And Ray and I are talking about Chapter 2 of Alice and Bob Learn Secure Coding, which are agnostic secure coding advice. Ray, did you want to talk about protecting sensitive data or security headers? Which one would you prefer to talk about? In protecting sensitive data, what do we want to talk about in that? Because I deal a lot with PHI, so I know a lot about it, but where do we want to take that discussion, is what I'm going to say. Because there's a lot of ways you can think about it. One of the things that I usually start with is that if you don't collect something or touch something, you don't have to protect it. Yes. That is the best advice: if you don't need it, don't save it. Yeah. Don't log it. If you could just drop it right away, that is the best, because if you don't have to protect the data, you're not liable for it. Really when we're talking about data protection, we're talking about liability for your company. In the US, we have HIPAA, but we also have a lot of other—we have the California privacy law, if you do any business in Europe, you have the GDPR. Businesses want all the data because they— No, marketing teams want all the data. They want all the data, but I feel like security teams want less data, because... Yeah. Yeah, so... I think one of the other things, too, is that not only do we want to do data minimization, so you know, if the marketing team's like, 'Let's collect 37,000 pieces of information about every user and track them across the internet,' you might want to push back on that if you're the security team. But on top of that, I would say design your systems—so if you only need to keep the data for a certain amount of time, so in the Canadian government, you have to keep everything seven years. And so I would design auto-deletion to start at seven years. Because we would get something called an ATIP request, which is an Access to Information and Privacy request, and any person in Canada can request it, even if it's 25 years old. If we have it, we've got to produce it. Right? And so if we don't have it, we don't have to produce it. And just from a time-saving standpoint, not having that data is good. And I remember lots of devs being like, 'Well, that's seven years from now, I'm not even going to work here.' 'Yeah, so you want to do a crappy job for the next dev? Is that your plan here, is to do a bad job on purpose?' So designing to only take the data and keep that you need, and auto-delete as soon as you can. Another thing that I think is pretty important is classifying and labeling the data. I was actually going to mention that, too. So what do we mean, like what is that? Every piece of data, I don't like to be too granular with it, but I like to label databases or even tables if it has PHI or PII, what type of data everything has in it. In AWS, you could use labels and tags and things like that. So for things, if it has PHI in it, you should have a PHI tag on that. That way you also know where your data is and what's where. Because one of the hardest parts of protecting data is knowing where the data lives. And you might have a database, and security people may not know what's in that database unless there's documentation telling you that, right? It's crazy. AWS has Macie because people have so much problem with this exercise, like doing this. What does Macie do? I believe—so I haven't used Macie in a very long time, I've actually been in the GCP world for a while, but I believe it analyzes the data in buckets and different places in AWS and it determines what type of data it is, like if it's PHI or something like that. It helps you—we used it at a previous job to help us figure out what was in where. Cool. So for clarity, classifying data means deciding if it's sensitive or not, and then what sensitivity level it is. It's just making that decision. And then labeling is literally putting a label on it, like Ray was explaining. And that could be putting it on the database, putting it at the field level, it could mean putting it in the design doc. There's all sorts of different ways you could decide. You could name your variables in a way. Like whatever way you do it, it's just important that everyone else is doing it that way, too, so you all know where to look for the labels. If you don't know if something's sensitive or not, ask your security team. I have had lots of security teams say, 'Oh yeah, they all know,' and then I've had lots of devs be like, 'What are they talking about? They've never taught us that.' Like over and over and over again. Well, if you work in the US and you deal with PHI, all the developers should know because they have to take the yearly test every year, or the yearly training every year. But how personal health information—that training is questionable sometimes. Personal health information, for those of you wondering. No, no, it's okay, it's okay, but not everyone knows. Okay, so we have a great question in the chat: 'Best approaches for secure coding while mainly using AI to generate code or entire apps?' Do you want to take a crack at this, or do you want me to take? At my job, me and some co-workers are working on some skills and plugins for Claude to help developers do a preemptive secure code review. But there's also prompts that you can use that will maybe enhance the security of the app building out. I believe you have built some of those prompts out, Tanya? Yeah. So I think there's a whole bunch of things we can do, and I have several talks and trainings and all of this on this. So there's more in-depth things you can do, but just to start, you could go to securemyvibe.ca. So what I did is I took my most recent book, the Alice and Bob Learn Secure Coding book that we are literally talking about right now, I distilled it down into 84 items of advice that I made a secure coding guideline out of, which you can get at securecodingguideline.com. And then I went and I took that, and I made a prompt library out of it with different levels of prompts, and that's at securemyvibe.ca. And both of those are free, but you have to join my newsletter, but that seems extremely reasonable, and you can just unsubscribe if you need to. But also, if you like those things, you're going to love my newsletter, plus there's memes. It's true! It's true, if you like my work, you're going to like my newsletter, because all it is is me giving you my work for free, so it's a pretty good deal, and things like recordings of this, my podcast, et cetera. So go check that out. The ideas is it tells it, your AI assistant, every single time you generate code, to follow this rule set. And then after that, if you're going to design or build certain things, there's a second tier of several prompts that help you build specific types of features, and you fill in the blank, and it helps basically drive the AI better for you. And then the third level of prompts, or the third tier, is when you want to build specific security controls. So if you have to build a security control from scratch, it helps the AI do just much, much, much better. In my brief testing, it really, really improved the quality of the code, so please feel free to go and grab a copy of that. There's more that you can do on top of that, like having a secure system development lifecycle, creating a RAG server with examples of the way that your organization does certain security things. So let's say, you know, you have a secret management tool and this is how you access it, and you've tested that code, you could put that in your RAG server and say like, 'Always do it this way,' right? There's more that you could do on that, but just starting with the prompts I think would be a thing that could really help. Yeah, I'd agree with that. Start with the prompts, and then level up slowly as you figure out what prompts you're wanting to do and which patterns you're wanting to enforce, I guess, right? So, Ray, we only have 30 minutes left, so I selfishly want to cover error handling and then the questions at the end of the chapter. Let's do it. So the new OWASP Top 10 risks to web apps, which I helped write because I'm one of the project leaders, and I'll put a link to that in the chat in a second—two of the top 10 are error handling, basically. So one of them is mishandling of exceptional conditions, which means we're basically just not handling errors at all, or we're handling them really poorly. And then the other one is security logging and monitoring failures, which is sort of the other half of error handling, right? Because you should do monitoring and alerting after there is a failure. And so it's two of the OWASP Top 10. We really think it's a problem. Do you want to comment on error handling while I look up the OWASP Top 10 for everyone? Yeah. We really don't want to give—I mean, we definitely don't want to dump stack traces out to the end user. The end user, most people aren't technical, they're going to get confused, it's just going to look bad for the company, right? It just is not a good look. But also, if that person is technical and potentially malicious, you could be possibly giving more information about how your application works internally. For the most part, we want to keep that to ourselves. We don't want to share that with people. We just want them to have the end-user experience that we prefer them to have, right? I'd say error handling is one of those things that seem really simple, but is super nuanced, and there's sometimes some gotchas, and you have to kind of understand how your programming language sometimes handles errors and how it bubbles errors up and where to catch errors. Catching errors in the wrong place, if you're bubbling it up all the way, that might not be the best place to do it. But we should not try, and then we catch, and then we do nothing. I've seen that so many times. You need to do something about it! At least throw a log message, right? At the very least, you should be throwing something in a log. Because ultimately, we don't want errors in our application at all. Errors are bad. Try-catches are expensive, right? Those are expensive operations to do as opposed to just doing that operation. So yeah, we don't want that stuff in our—I mean, we want try-catches in our code when it makes sense, but we... We need to do something about it. We need to handle the situation, because if we don't, if our app doesn't know what to do next, it will fall into an unknown state, and then guess what? We don't know what's going to happen. And that is literally where a lot of vulnerabilities lie, or crashes. Either way, it just sucks. On the flip side, so you don't want to give away system data, but you want to be more detailed than 'Sorry, something went wrong.' Yeah, that's very frustrating for the user. Yeah, that's where error handling comes in, and you have your different error codes and you can write different error codes for everything and have different end-user messages. So yeah, you do want to be more detailed. But unfortunately, being more detailed sometimes means you have to do a little bit more work. And you have to understand the errors that will be coming up, and you need to think about how to handle those gracefully. I completely agree. Everything's work. Security is always going to be more work than not doing security. But for all you security people out there, and if your company is using AI, start pushing back on the developers a little. If they're not writing the code, they can't be complaining about it, you know? Remember that. Okay, I want to answer some of the questions that are at the end of the chapter. And you're allowed to disagree with me, Ray. The answers are what I feel the answers are, right? And I'm opinionated. That's why I write books and write a blog and talk, because I have opinions and I want people to know them! So the first question is—and for those of you that have the book, it's page 52: Number one: Input to an API that comes directly from your web app—your web app that's on the internet—does not need to be validated. True or false? Am I answering? Yeah, you can answer, or the audience. Everyone answer in the comments. I'll say true. I mean... I have a funny answer, but that's just for funniness, not necessarily for information, so I'm going to skip that. But yes, you should be validating the input where it makes sense to validate that input. I would say that generally if there's input coming from the front end, if someone could proxy that and change it, I would want to validate that input I'm receiving. If I have an API gateway, and it's making sure that the data only comes from the front end and it can't be proxied somehow, and you have 400 other things—but I would say that it does need to be validated. So in the chat, someone says 'false' because the way I ask it, the answer is false, because I say it in a negative, which isn't great. So yes, yay! Nice work, awesome! I mixed that up. No, it's okay, I know what you mean, though. So number two: How many times does someone need to sign in for SSO? It depends on which SSO provider you're using. How many times should you have to log in for SSO, which stands for Single Sign-On? It should be once! Once plus step-up auth for any sensitive actions. Okay, yeah, that's fair. Because if you're changing a GitHub org setting or something like that, you probably want that person to re-authenticate. With Okta, I have to look at my phone and press a button. It takes me three seconds, my context is not really changing, right? But yeah, you should only have to once. But I've had some interesting implementations of SSO where it just seems like every 30 minutes you got logged out or something, right? Yes, I worked somewhere that will remain unnamed where I had to log in up to six times per day, and it made me super crazy. Just be good to people. Don't make your end users hate you. That's my 100% advice: have reasonable controls that make sense. Oh my gosh, yeah. And if they're malfunctioning, do work, redeploy, fix it. Don't just be like, 'Oh well.' Someone's like, 'MFA, hahaha.' Okay, so number three: In what order do you do authorization and authentication, and why is the order important? And I want the audience to answer. So authorization and authentication, which order do they go in? Auth-N first or Auth-Z first? And why? And we'll give them just a couple seconds before inevitably, they know, we're going to give them the answer, Ray, because that is how this works. And because we don't have 500 people on, where it would go faster then. But, Ray, does the order matter? Yeah, we have to know who they are before we can know what they can do. And that means— That's basically it. So that means we need to do authentication before authorization. That's correct. Yeah, because otherwise, how can you even figure out what access to give them if you don't even know if they're actually the person they say they are? If they're not authenticated, then we should just treat them as a stranger, right? An untrusted user. All your users should be treated as untrusted users, but you know what I'm saying. So number four: remember when we were talking about secret management? So I want everyone to put into the chat—so it says 'Name three types of secrets that you would store in a secret management tool', but I want everyone to put anything that they can think of that is a secret in the chat. Anything that you think of as a secret. And then while people are doing that, as a reminder, secrets are what computers use to authenticate to each other so that they know who each other are. Technically, passwords are considered memorized secrets for NIST, I think. I think that's what they call them: memorized secrets. Oh, I've never heard of that. Okay, so some examples of secrets are hashes, certificates, API keys, yeah, tokens, yeah, any sort of key, passwords, AKV—ooh, what's AKV? I don't know that one. Interesting. Kubernetes secrets, connection strings, yep, good job, good job, everyone. All of you are doing great. All of those things are secrets. Anything a computer uses to talk to another computer and say, 'Hey, I'm this guy, let me in.' In my own personal secret manager, I also put the name of my first pet, and—no, I'm just joking. Making a joke about the bad security questions back in the day. Azure Key Vault is a secret management tool, good job! Yes. I like when people use the tools in their cloud providers, for sure. The security tools are nice. SSH keys, I missed that one, good job, yes! So question five: Is Same-Origin Policy, which is a thing we didn't talk about—it's a security browser feature, it's in the security header section—is enabled in web browsers by default in modern web browsers, true or false? I'm just going to give you the answer. The answer is true, because it's a great feature, and it makes it so that people can't read your stuff unless they're from the same origin, or you grant them permission to do so. I believe the default setting is lax, though. Oh, really? Which is still good, right? It's still better than nothing. So we can set it to strict. Somebody would have to check that. I actually don't know if that's still true, but I remember—I think that is correct. Cool. Because the book was published in February 2024, it's been over a year, and then also by the time you publish it, you finished writing it months and months earlier, it may have changed. But the next one, six: Cross-Origin Opener Policy is enabled in the web browser by default in modern web browsers, true or false? I think it's true. I'm like 80% sure it's true. Actually, your book was the first time I looked at some of those headers. It's false, it's not on by default. You have to turn it on. So it's where you label things that other origins are allowed to open and read from. So the new browser security headers, all the CO ones, like Cross-Origin blah, except for CORS, which is really, really old, all those came about because of Spectre and Meltdown in 2017, where basically a bunch of PhDs got together, worked for a year to ruin my life, to make me work lots of overtime, and basically figured out that they could read memory in other browser windows and attack them. And so as a result, we had to figure out ways to make that not happen. And it's still it was a very complex and painstaking type of exploit. It's not like just anyone could do it all the time really easily, but still, we had to fix that. So that's what all of those are about. You know what? Actually, now that you mentioned the Spectre thing, I do remember all these popping up. I just haven't thought about these in a while. They came out in 2021, and less than 1.5% of the internet's websites have them turned on. I don't think I've seen it in the wild, truthfully. Yeah, they're pretty rare. Number seven: Give some reasons why you would not print system error messages directly to the screen. What is a reason? And the audience can answer this, or Ray. Why would we not just print the system error message, like if our database errors, why would we not put that to the screen for the user? It is completely unhelpful for the user. And it might make us look stupid! And most importantly, from a security perspective, that's a lot of sensitive info that might help them attack us better. We don't want that. Could you imagine you're just a regular user and you get this database error, you're like, 'What? What?' Yeah, as a non-technical user and you see that, what are you supposed to do with that information, other than try to reload the page, right? Or just close it out and be like, 'I'm going to go deal with another company.' Yes! Yeah, it makes us look unprofessional. Okay, so number eight, the last question at the end of Chapter 2: Give one or more reasons why we need to catch our errors and handle them in our applications. Because it's fun! Because otherwise our app might crash. Because otherwise there might be a vulnerability. Because otherwise we don't know what it's going to do next. Because otherwise we look dumb. It's best practice for a reason. There are a lot of reasons. Just handle your errors. Yeah, handle your errors! TheCyberVine asks: 'I'm curious in hearing your thoughts on dealing with the ever-changing cyberspace with continuous AI threats like Claude Mythos.' Claude Mythos is another model from Anthropic that specifically finds vulnerabilities. In order to use it, you have to set up a test harness, which is quite involved from what I understand, so it's not like someone can just point it at a website and it's just going to find a million vulnerabilities. From what I understand, though, it's able to find multiple vulnerabilities very quickly, chain them together, and turn them into active exploits very quickly and extremely effectively. And so what are we going to do about it? I think we need to start writing way better code. Right? I think that we need to actually take security seriously for real. I think that if we're going to be generating code with AI, I think we need to generate more secure code to begin with. I don't think that what we can do anymore is we write code or it generates code, which is not good to start, and then we run something like static analysis and it tells us there's 12 trillion things wrong, and then we're supposed to fix a million bugs before we're given no time to do so. Then we're going to run, you know, automated AI pen testing or something more intense like Mythos and find a trillion more things wrong, and then all developers are ever going to do is fix bugs in AI-generated code. That seems like a miserable existence. I think that we need to reimagine the way that we are doing AppSec. I think our current tool set is not mature. I think that it was barely working at all for the way we used to do it, and it's completely not suitable for what we're doing now. Super hot take there, I like it. Thank you. Do you want to add anything? Yeah, I'm going to say it's definitely a brave new world out there, and AI is changing a lot of things. In the next two years, we're going to find out for sure. Would you say that we're effing around right now and we're going to find out? I'm just saying we're going to find out. I don't know if we're effing around, I don't know what people are doing with it, but... We are. We have random people all over every organization—people in marketing, CEOs, random people—generating code and pushing to production. We are definitely effing around. In the org I work for, this is a concern that we are actively trying to get ahead of. I would recommend all you out there, your org should probably—you should probably suggest that they actively get ahead of this stuff too, and start at least thinking about this. But this is going to be a threat, and it is going to change how we do security. It's going to change how we think about open source, it's going to change a lot of things, and we're going to have to adapt, because you don't really have any other choice. Our job as security people is to make sure these things are secure. Whatever the business is doing, we have to secure it. We can't just be like, 'Don't do that.' Because guess what they're going to do? They're going to do it and not tell us. Exactly. Yep. Ray LeBlanc, thank you for joining me on yet another stream. I appreciate you so much. You're welcome, Tanya. Thank you for your hot takes, and your information, and your ideas, and for sharing your time with me. Thank you to everyone who came to this stream. I look forward to seeing you next month for Chapter 3. I'm going to be with Scott Helme. And I have months and months of people that I'm planning. I'm really excited to do the rest of these streams with you. He's the header guy, right? Yep, he's securityheaders.com guy. Oh yeah. I meant to get him for this chapter, but we just couldn't make it and have you for Chapter 3, but scheduling, it's a whole thing. We didn't cover security headers, have him cover it in the next one. Yeah, just do it. Yep, guess what? He's the guy that you want covering security headers anyways. Him and I did a talk at RSA about security headers, and I thought it was great, but I'm a nerd. Anyway. With that, I want to thank everyone so much for coming, and I will see you next month. And until then, I hope that this has been helpful, and that you handle your errors! Bye everyone! Bye.