Coding Blocks - PagerDuty’s Security Training for Engineers, The Dramatic Conclusion

Episode Date: January 31, 2022

We wrap up our discussion of PagerDuty's Security Training, while Joe declares this year is already a loss, Michael can't even, and Allen says doody, err, duty.

you're listening to coding box episode 177 subscribe to us on itunes spotify stitcher and more using your favorite podcast app uh leave us a review there or you know press the the like or the plus or the thumbs up or like whatever it offers we would greatly appreciate it if you would yep and visit us at codingblocks.net where you can find all our show notes which are extensive and glorious discussions examples and much more and send your feed oh geez it's still my turn way to go my initials are right there you're listening to coding blocks episode one that's right send, questions, and rants to comments at codingblocks.net. And I was just so excited to

tell you about all our fiery hot takes over on Twitter at Coding Blocks. And I'll say this website thing, you can go to codingblocks.net and find other social links at the top of the page. R-Dilly's. W-W-Dub, man. W-W-Dub. Nobody does that. Yeah, they

do. I always type in www. You still type in the HTTPS colon forward slash forward slash? Do you really? Don't hate. I type real fast. All right. Well, with that, I'm Joe Zach. I'm Michael Outlaw.

And I am the typer, Alan Underwood. This episode is sponsored by Datadog, the monitoring and security platform for end-to-end visibility into your Java applications. And Linode, simplify your infrastructure and cut your cloud bills in half with Linode's Linux virtual machines. And Shortcut, formerly known as Clubhouse, you shouldn't have to project manage your project management. All right. And today we are continuing on for the last segment on PagerDuty security training for engineers talking about session management. Are you sure? But first, I think so.

Is that not right? Can we address what Alan is the typer of? Ooh. All things. I overly type everything. Well, I mean, if we're already off track, I might as well tell you all a joke. Please, please.

You want to hear a joke right here in the beginning? I apologize if this is your first episode. It's always like this. All right. How many programmers does it take to change a light bulb? None. That's a hardware problem. All right.

Excellent job. And I told you there was one joke, but it's actually two because, you know, off by one errors. So how many programmers does it take to change a light bulb? Wait, say it again. It's the same joke. How many programmers does it take to change a light bulb? None it again uh it's the same joke how how many programmers does it take to change a light bulb none it's a hardware problem uh zero because they like dark mode oh same joke two different answers uh i thought i thought you were like tricking me like i like i didn't hear it the first time like i'm like, I already answered that question, Joe. Move on to the next joke. Yeah, we are getting old.

We might have forgotten. Speak for yourself. These were studios by Chris Rathod. Hopefully I pronounced that right. Sorry about that. But yeah, those were some excellent jokes to start off the show. Super awkward. Let's go. Alright, so with that, we'd like to thank those who took the time to leave us a review. We're not very thankful this time, apparently.

Yeah, I don't know if we forgot to look it up or maybe we didn't get it either way. No, we did, but we're going to introduce and make this section super awkward. Yeah, so like... Peer pressure time. Listen, all the listeners were busy on game jam they didn't have time to go leave in a review and some newfangled review somewhere before they

couldn't understand the country dj voice it was one of the two oh yeah oh yeah we did do that we should have run them is that too you know be like well in front of iTunes, I'd like to give a big shout out, big thank you, and a big yeehaw to you can say this nickname. And also thank you, Tammy Sue, for that latest review. Greatly appreciate it. That's actually pretty good. Don't forget to stop by Curtis's Chicken Pit. Still a sponsor.

Excellent, excellent. Hey know we'll do better next year i'm sorry this year let's just let's just call it and just try to get through it next year is that that can't be true we're two episodes deep well I guess so. You know, honestly, so Jam, you Barry, is over now. The event has concluded. We're still going through voting, so I'm not going to talk about the games yet, but

that's all I cared about this year. Next year, I'm already planning what I'm going to do, but we'll talk about that later, and we'll talk about some of the games after the submission period, or the voting period is ended ended rather so uh yeah it was amazing though you got it we'll have a link in the show notes you can go check out and play uh 46 new games in the world made up of made up made from uh 46 teams and individuals uh all are amazing especially

there's one that is a surprise too if you uh play a game called eat my dust uh there's some uh we'll call coding blocks audio um that you should check out it's interesting that's excellent you know i was going to say like for the next game jam because this has been the you know we've we've done two game jammers and this has been the second one in a row now where one of us has gotten pulled away, uh, you know, due to like other, uh,

you know, uh, work life balance things get in the way. Right. Next year. I still, I absolutely want to keep doing game jam. It's awesome.

But we need to figure out a way to where like the three of us could just be a single like submission, you know, working together. So that way, like if one of us could just be a single like submission, you know, working together. So that way, like if one of us is like, Oh man, I gotta get,

you know, I gotta go check out this thing for work or whatever, you know, uh, then, you know, I gotta go pick up the kid from school or something, you know,

like it's not, it's not like a big pressure, like, Oh my gosh, I'm missing like all the time in the world to like, you know, I can't, I am,

they're never going to get this amazing game done. Hey know what we need to do so thinking about that i was actually thinking about that this year because you know there's all kinds of things that pull us in all kinds of directions right we need to rent a hotel room somewhere and bring some laptops you know in person live twitch in person live twitch game jam and and assuming covid zeta zeta alpha beta omega isn't a thing at the time like let's just lock ourselves in a hotel room for for a solid you know three days and we'll drink beer and eat pizza and code. Hotel management is going to look at us funny. Oh, it's going to be bad, right? But that's what we need to do, right?

That would be totally, I think it would be fun. It might be fun. Yeah, oh no, that's amazing. Although today, three days of eating pizza, my back is already hurting just thinking about it. I don't know why. There'll be some cheeseburgers too, and maybe some Dots pretzels.

We can mix all that in. I know how we can talk Joe into this. Joe, I will bring you your very own bag of cheese dust. Oh, yeah. Of course. I'm in too. All right. So next year, that's what we need to plan on.

Or maybe this summer, if we're tired of being stuck in our houses again, maybe we'll do like a i don't know we said we were going to do another a second game jam during last year and we never did so yeah i'm not convinced that we'll do it again this i'm not convinced either but we can say the next time that we do a game jam we're going to try and get together and and just make it something fun to where we lock ourselves down completely yeah but really what got me thinking about it though too is that like last year and again

this year, I noticed that there were several submissions that were by teams of people. And I was like, oh, that's a neat idea. We should have done that. Yeah, I like it. I was tempted to make a longer window and say, you know what, just take a month, but don't spend a month on it. Spend some

amount of time that you're comfortable with, but you have a bigger window. But then people are doing it different time and so you don't get that kind of energy and stuff so there's i don't know some things to figure out also i'm really interested in doing a different kind of jam like maybe a web jam or um they have a coding for charity events and stuff and so i'd like to do something it'd be cool to be able to just like spread it out so if you you don't want to make games but you do like make in websites or something then maybe there's something we could figure out to do that. All right.

Now we're talking my business. Line of business apps. Here we come. Yeah, there you go. Right. Is that a jam? Line of business app jam. Wait, there's a name for that.

They're not jams. They're hackathons. Hackathons. Yes. Thank you. I knew there was a term. Yeah. So we can figure something out.

Like who? I wouldn't want to line a business app, Jim. That sounds awful. Yes, you would. Don't lie. It's true. I like SaaS Jam. SaaS Jam will make some money. Cool.

All right, so we've planned it out. We're good to go now. All right, so we're going to talk about some security things. Yep, so we are picking back up on the pager duty thing. Um, this is episode 23 of the 10 page thing of pager duty. So, uh, yeah, we're, we're actually going to wrap it up this time. So where we're going to jump back in now is session management. Um, and this one's interesting because if, if you are either new to web programming or if you've never really thought about it,

session on the web is kind of like a bolted-on thing because the web on its own is stateless, right? Like HTTP pages don't have any state. Like they don't know that you're a user or anything. That's a nice way of saying it's a pain in the butt. Right. I mean, and,

and they ended up bolting things on over time, right? Cause HTML is hypertext markup language. It was for display purposes. Right. And after they did that, they were like, oh man,

well we could, we could make this thing to where people could use apps online and that kind of stuff. And so they had to come up with ways to make that workable. And really all we're talking about when we're talking about state or session management is being able to identify a user over multiple requests, right? Like you load page one, then you go to page two. Am I the same person that was on page one?

That's all we're talking about. And so the way that they got around this, and this goes back many, many years, right, is they have these things called cookies, which are more or less just text files that are stored on your computer. But it stores pieces of information that when you make another request back to the server, it passes information from that cookie along. And then that server looks at it and says, Oh, okay, this is the same person that was on the previous page. Right. And that's generally how it's done. And it all happens behind the scenes. And most people don't ever think about it, look at it,

concern themselves with it. So, um, I'll let one of you guys pick up from there. Not it. Uh, you know, I was just was just thinking um you ever think about how hard it is to even determine what a session is you know so if you got data coming in you've got to kind of decide if i see a new request from the user how do i know this is another session or not like well you know is there a time window and it you know if so like is there a database somewhere that's kind of you know keeping track of this stuff? And it's really tough. It's nice that web frameworks kind of handle this.

So I haven't had to think about how to do that in a long time. But if you are ever getting down to, like, streaming events or anything, like, this becomes kind of a thing where you have to kind of decide on, like, windowing, basically, and what exactly constitutes a session. So it's a really tough and interesting problem, I think, especially once, you know, we talk about trying to keep performance good and keep things in memory and trying to decide how to do that. I'm glad I don't have to do that very often. Well, it's interesting that you said that with the rolling windows because anybody that's not familiar with that term, they probably don't even really know what that means. But to put it in perspective, let's say that you log into a site and you're supposed to be alive for 30 minutes, right? Well, if you go hit another page on that site after you're logged in, then it kind of resets it, right? And that's what he's talking about with

the rolling window. So, you know, I stayed on page one for five minutes. So technically I have 25 more minutes before I get logged out. But if I click on another link and I go to another page, then that kind of resets the window and I'm alive again for 30 minutes. And what's really interesting is behind the scenes and all three of us have dealt with this over time is depending on how your session state is handled on the backend, it can be really complicated to do this kind of stuff, right? Like if you have a server web farm, like I know we used to deal with this back in the past, you have a web farm. And if you have, I don't know, let's say five servers that are serving things. A lot of times what you do is you'll cheat and you'll have these things called sticky sessions, right? Meaning that if

you log in somewhere, then you're always going to be on that first web server, right? Meaning that if, uh, if you log in somewhere, then you're always going to be on that first web server, right? Let's say that that's what you logged into. Every request that you hit is going to hit that first web server. But if for some reason that first web server goes down, you're going to get switched over to web server two, and you just lost your session. If it wasn't implemented in a way to, to push that stuff across. You can actually go in and set it up to where the state is shared amongst all the servers, but then that's another thing you have to manage. So there's actually a whole lot that goes into keeping a session alive and running.

Well, I can give you a couple of examples to illustrate both of those, like real world examples that you've definitely seen regarding the rolling window. Think of any kind of financial application that you've ever logged into. Right. And like you go, you log into your bank and if you don't touch anything, eventually you get a screen like, Hey, we're going to automatically log you out. Are you still there? And they'll like pop up a pop up and, you know, eventually log you out if you don't respond to anything. Right. So that would be like an example of the rolling window,

because if you're, if you keep the activity up, then it doesn't ever prompt you with that, right? It's only after it, after an inactivity period has passed, uh, that it would eventually log you out. The, the session, the shared session versus sticky session thing, if you've ever been to, um, well, I guess this isn't exactly an idea of, of sticky session necessarily, but if you've ever been to, well, I guess this isn't exactly an idea of sticky session necessarily, but if you've ever seen sites where, I'm thinking of e-commerce sites specifically, where maybe you go on multiple devices and on one device you add one thing to the shopping cart, and on another device, you don't see that shopping cart because there isn't a shared session for your user ID. But, for example, an Amazon.com doesn't have that problem, right? Whatever you add to your cart on your phone, if you're then like, oh, let me go to my tablet, you still see the same shopping cart. You then go to your laptop, still see the same shopping cart you then go to your your laptop you see the same cart right that may not be a shared session though that might just be persisted information based off your user id right like yeah i was just trying to like use

it as an example of like you know where you might but yeah technically you're right yeah but i mean really in the end it's just it's way more complicated than what you think. And like Joe said, it's really nice that a lot of these frameworks and languages out there now kind of just do it all for you. Like you don't have to think about it that much. You know, a really common way to do that for web is to basically store a session token. So the person comes in, if they don't already have one, you create one, and then it's some random string and you can kind of set a timeout.

And so if they don't come back and do something else, then that timeout, that session will expire. And then later, if they come back with an expired session, then you let it go. And it's nice because you have control over that.

And some of the streaming stuff, for example, as we were talking about, a lot of times that'll happen after the fact, so you don't have the ability to kind of inject this token. That's kind of something that makes this problem a lot easier on the web but that's kind of like the most common technique for it we have to be really careful not to store any sensitive

information though in that cookie that's something my first job on the web uh we used to have like user permission so like an admin could log in and do this stuff for customer service whatever so all the developers uh we could just go in and edit the cookies to make ourselves an admin or make ourselves customer service or whatever just because you know it was an easy way to test and uh you know i was like being a new program never was like oh okay well that's pretty cool not really thinking about the security or anything luckily uh no one no one was thinking about security back then so this is a long time ago but uh yeah that was that was pretty cool so i always think kind of think about that and uh how important it is to not allow that okay so am i

being silly and naive though because like you're saying like you know modern web frameworks like you don't have to worry about this thing and i'm like wait no no no no this is like a problem that has to be solved before you even get to the to the, right? Because at like a load balancer level, right? If you have, go back to Alan's example of five web servers, right? The way the sticky session works is it's at the load balancer level that it knows, Oh, this IP auto always goes to, I'm always going to route him to web server three. Right. And so, uh, if you were going to do any kind of session shared you know or or like session management that would be uh that would be among all of them it would either be you know maybe not in front of the you know maybe not a load balancer kind of issue but it would

have to be something else to where like all of those uh web servers are like reading writing so like maybe a key value store, right? A shared key value network that is on a different, that might be its own cluster that all of those are using. Right? Yeah. So I like in the.net when,

when we were doing.net stuff before, like in.net framework, they actually had a session state server that you could stand up. Right. And then each one of the web servers could use that and its backing store could be SQL server. It could be something else. Right. So, um, that was one way to handle it, but you're right. You have to think about that. But I think with a lot of frameworks out there, I'm not sure about like Django and things like that, but I'd be surprised if there's not configuration built into where

they're like, Hey, um, make your session state store a Redis instance or, like you said, some sort of key value store like AWS DynamoDB or something like that. With.NET, you could set it up as DynamoDB. We did that once before. Right. So really nowadays it's more configuration than actually having to set up the things. Back in the early days, you would actually have to be like, okay, well, we're going to write this stuff to a database, and then we're going to write an application layer that will check to see if you have your stuff and then go load it.

All that's dumb for you nowadays. You don't have to worry about it that much. Okay, so I was just being dumb and naive then because I thought you were saying like, oh, hey, if you're using like Angular 12, then guess what you get? And I'm like, what? No. How could it even know? Like, that can't be.

No. Okay. Nothing like that. That makes a lot more sense. See, so the listeners that didn't know some of these terminology either, I'm like right there with them. I'm like, yeah. Go get them. Yeah, it's like you don't have to come up with something new here.

Right. There's something buttons framework it's probably configuration driven but it is going to be your server tier that you're going to have that stuff but it's been configuration driven for like over a decade though yeah yeah i mean it's been a while oh but when joe was saying that you know you'll have this session token and whatever again this is something that happens behind the scenes that you probably don't see. If you don't go digging in and look at your cookies and that kind of stuff, you don't even know this thing exists, right? Because if it's being done right, you're not seeing it in the

web request. You're not seeing it anywhere except in the headers that are getting passed back and forth typically, right? So you're not seeing it. And when he was talking about modifying things in the cookie, like he was actually going onto the file system, wherever the browser puts its cookies and modifying the text. Go ahead. Well, I mean like, cause,

cause you said as part of like the headers, but not the web, you wouldn't see it as part of the web request, but technically those headers are part of the web request. You wouldn't see it in the URL, I guess is what I was meaning, right? Like,

yeah, you wouldn't see it as a query string parameter. Right. Well, except maybe in like the old, old, old, old, right? Yeah, you wouldn't see it as a query string parameter. Right. Well, except maybe in like the old, old, old, old, old, old, old days maybe. Which is bad, yes. But you could, like, you don't necessarily have to modify the cookie. You could, like, go in and modify that request and replay that. And, you know, all of a sudden, hey, guess what? I can be Joe.

Yep. So what he was saying about don't put sensitive information in there, that's, that's big for a couple of reasons. One, um, you don't want people getting access to like PII personally identifiable information or anything like that. But also they said, when you do things like that, it makes it much harder to revoke those cookies. So, you know, try and keep them lean. Really, the session token, and that's about it. And then store everything else on the server that it can retrieve whenever you go to make those requests.

All right, so the next thing that we have, and this one's kind of interesting. This is fun. This has been going on for a long time is session hijacking. Um, and so basically this is when somebody guesses or steals the session identifiers and they basically put that session token on their system and then they can act like they're logged into somebody else. Right? So if outlaw logs in on some website and he's got session ID one, two, three, and I'm like, Ooh, I bet it's session ID one, two, three. I go recreate that cookie locally for me. If I go hit a page, the server's going to think it's him. Right. And then I can do everything that he has rights to do in the system from mine. And that's more or less what it is in a nutshell. I don't know what else we can say about that.

Yeah, I don't know. I feel very much like Forrest Gump when I say that. That's all I got to say about that. So this is something that used to come up a lot too back in in the day i haven't really heard a whole lot about it but uh sexist session fixation which i've never heard it called that but the idea is that a bad actor will create a session and then i essentially get a user to kind of take it over after they've created the session and then that person will go and log in and hey the person who originally originally had the session is now also logged in because they're kind of the same person. And I don't know.

I guess we'll find out here in a minute. But I remember we used to hear a lot about that at like schools and stuff. So like if you went to like the college campus computer lab and the browser was always up or was already up and maybe it was already at the the login page for your email or something well someone could have sat down copied down like the uh the session token for you know the email page got up and left and then you go log in with that session token and your username and password authenticate and now that session token has been authenticated and so basically back in the day they used to tell you just always generate a new authentication token for every time the person logs in. That's how you would get around it. So I haven't read ahead here.

Actually, I didn't do the reading. Sorry. Today, I had time. I just didn't do it. I forgot. Honestly, I don't know that I've ever heard of this one. No. Yeah, this one's weird, right?

Like it's a reverse takeover it's you know you set something up and then somebody actually goes and authenticates and now you've got control of of what they did um and they said that this was predominantly a problem when the session tokens were passed around in urls and it brought to mind immediately um jay-z and I used to do a lot of cold fusion. And I remember back in the books that you buy, like Advanced CFML or whatever it was, they would actually tell you, hey, pass CFID and CF token around. And the problem is somebody would email their page, right? They'd copy the link to their page and email it to somebody else. And then that other person will get their session automatically.

Right. Um, yeah. Yeah. So, um, at any rate, it's probably not as big nowadays.

Yeah. I can't even remember the last time I heard of it, but yeah, even banks and stuff. I remember our computer lab and this was like in the nineties, late nineties, uh, the computer lab would have like signs like about shutting the browser down,

not, not, not using the browser, cleaning cookies before you log into banks and stuff i don't remember all the details anymore but that was the whole idea behind it uh and yeah just the idea that the cookies are client side so uh you can't implicitly trust it you see a lot of apps too that will kind of when you log in they'll say like hey do you remember your stuff is this a private computer or a public computer and they'll kind of do that

sort of thing or like if you're ever at like a hotel, you know, if those still exist. Business center. Yeah. Business center. And you, um, you go log in. It's good practice to kind of do the whole incognito window. Uh, just. I don't care.

I, if we're talking specifically about a business center, I don't care. There's no reason. There's no way you will convince me to log in on one of those public computers if it's at a business center or a bank or like i'm not a bank i'm in a library uh like remember like the days of like you know when internet cafes were a thing and i'm like yeah i would never use somebody else's computer to log into anything. I don't care like how, you know, uh,

team, like, you know, it doesn't have to be anything sensitive, like bank account information. Like I, I'm not logging in. Right.

I don't want you watching my Netflix, the 25 key loggers. They've got, it's not on there. It's not you, them watching your Netflix. It's them getting into your account and then seeing like, oh,

now, uh, here now uh here's here's more information about like how he paid for it or his billing address or whatever i i don't there's i can't for the life of me see why that's a thing yeah not with cell phones anymore but you know right long time ago way back machine used to pretty common. Yeah, so how do you secure and verify sessions? So one thing you do is basically add extra pieces of information to the session that you can verify when the request is actually made. Have you ever heard of HMAX?

I have. Yeah, it's a way of like, yeah, anyway, doing this sort of thing. There's also nonces. I should have done the reading. I was probably going to talk about all this stuff. No, it doesn't this sort of thing. And there's also nonsense. Uh, we'll probably, I should have done the reading. It's probably gonna talk about all this stuff. It's basically, it doesn't, it doesn't go that deep.

No, no, but, but that is what you're talking about, right? Like the knots, like you should probably at least describe it so that people have an idea because they were very light on this.

Nance literally stands for it. Like spell, spell in you once number used once. Yeah. And, and, and that's really when the when the session's created that knots is added to the thing so if somebody comes back then they can verify that you know this is where it came from yep it stops like replay attacks where you imagine where someone like logs in and you manage to catch their web request and now you log in you replay that and now you're logging them from a different computer. Well, it can also get confusing here, too, though, when you start talking about nonces.

Because when you start talking about nonces, it's easy to start drifting into an encryption or a security transport layer type conversation. because in the underlying TLS connection, part of that exchange can and will likely include a nonce exchange back and forth between client and server. Yep. Yeah, so they kind of agree on some information. They send it back and forth, and that way they know if somebody else tries to either replay or tries to intercept and interject and kind of throws things off.

I guess where I'm going with that though, is I wanted to be clear that like the session management that we're talking about now is like in your application, we're talking about like application layer session management. And if you were going to use a knots, you know, for any thing going on, but then we're still in that layer.

We're not at the lower level of the transport layer where it might also be doing some of these same concepts. Yep. And so the main gist of this is to use these tools to make sure that your session hasn't expired and ensure that your expirations are set properly for a session. So you imagine you create a session that never expires. That's a bit of a problem.

So you don't want the client to control that stuff you want to have protection in there against that sort of thing and all this stuff catches kind of easy stuff like i you know i mentioned the replay attacks uh another one story from back in the day uh there was a uh firefox extension called fire sheep you remember this when this came out i do not remember that one uh it would basically monitor Wi-Fi traffic. Just you can go to a Starbucks or something, pop up in FireSheep and see what people are doing around you. And this was back before HTTPS was really common. And so lots of people logged into sites with just HTTP.

They would send their username and password and you could see all that stuff just being played across the network. You just sit there and watch it. And this extension, FireSheep, just made it really easy. I just sit there and watch it and this uh this extension fire sheep just made it really easy i'm sure they're much better ones that was the first one where i like i saw it and i was like oh no we can never do this again because the person just like had this video of them showing you people doing stuff all around them in the coffee shop it was like oh no and you're not talking about wire shark no no this is just a fire firefox extension like literally in a browser you like click a little button, it's like

okay, here's all the interesting traffic going on near you that's not generated by you. That's crazy. You could use it to even figure out passwords and stuff for Wi-Fi. This is chipped on memory lane, but there used to be less secure ways of authenticating to

Wi-Fi that are much easier to watch a few messages go by and get in there. Computers were way more... I'm sorry if you're just getting into this stuff now, things were way cooler like 20 years ago because you could just do all sorts of stuff you weren't supposed to do.

We didn't care. You wanted to play the game and you wanted to make the bad guy easier to kill, just recompile it, change a couple settings. Game Genie. Yep. Change a few hex keys. Oh, Game Genie. Wow. That's a trip down memory lane. Yep. And developers back then, they didn't really have good ways of

the tools and builds. So someone reminded me of this. There were a bunch of hacks. Not hacks. There were a bunch of things you could do on old Nathaniel's. If you held the button down on this controller when you started it, then it would put you in debug mode mode you could do this stuff you could test because they didn't have you know good ways of like doing debug builds and tests and just all those sorts of little things like even cheat codes and games a lot of those were because developers wanted to uh be able

to test the game and they didn't want to have to you know be play the game perfectly get the last boss so they like turn on invulnerability with some cheat code or something and then later it would leak and yeah so and you get more fun you could edit those binaries because signing uh signed executables wasn't a thing or signed yeah no nonsense yes that's right no sign yeah definitely no signed executables yeah so additional ways to to make sure that you keep your session safe or make sure that session id is unique and random the random is a very key part of this um so sure when you're yeah yeah unique doesn't matter just random well if it's random between one through ten that's you know you checked one of the boxes right you did you did you didn't check them both

though also this is interesting if you're not doing this you should check this when you're sending client cookies from the from the browser up to the server or whatever there's two flags that you need to make sure that you have set one is secure flag and the other is HTTP only. These will help prevent, and I forget exactly what they were. I think the secure says that, I can't remember how it's transferred. At any rate. It has to be a secure connection. Was it a secure connection?

Yeah, it can only ever be sent over a secure connection. So you can have secure and non-secure cookies. Okay. And if you made your connection to the website back in the day when we used to use HTTP, if you made the connection to the site first as HTTP, then those secure cookies wouldn't go over until you flipped, which was usually because you authenticated to the site. Yeah.

And a HTTP only is a, can be used only by like HTML. Basically the, the instruction to tell the browser not to allow like JavaScript to access the value. Okay, cool. The other thing that's really important that a lot of people,

this is probably where a lot of folks mess up, is you need to make sure that you have the domain set on the cookie properly. If you don't, then just about any domain could hit it, depending on how it's set up. And if you really want to make sure that you've got it locked down, let's say that you have a domain that has many subdomains, you need to make sure that you lock it down to the particular subdomains you want. So it's really important that you set those things properly as well. And I'd say a lot of people don't even realize this when they're messing with their

cookies. So, oh, this next one was interesting. Somebody highlighted it. They can take it. The domain? That was an accident. Oh, this next one was interesting. Somebody highlighted it. They can take it. The domain name? That was an accident. But basically, go ahead. You got it. I was reading about Fireshape. You can go ahead.

All right. So the session fixation thing, when we were talking about that earlier, where somebody would basically create a session, then you'd log in and all of a sudden that person who initially set that thing up would have access to it. It's similar to what Jay-Z said earlier in that just make sure anytime that you're doing an authentication or whatever, you create a new session token.

That way somebody can't hijack it based off just creating the token ID previously. Right. Because if you were to, because otherwise, because the alternative is if every time Alan logged in, then he would get the same token, the same session ID, then that allows the session fixation hack to occur, right? But that also means that you didn't adhere to it being random and unique all the time. So if you, every time they log in, they get a new random and unique session identifier,

then they, then you prevent the session fixation that I'd never heard of until pager duty. Awesome. I really hadn't. That's interesting. I mean, it's not something that you hear about much anymore at all.

But so another thing is, and we already mentioned this, don't put the information in the cookie, like anything that you're trying to do. First name, last name, all that. Don't put it in the cookie. Keep it on the server side. And and that way it's available whenever you hit it. Nowadays, there's so many cookies that get flown around with like every request you know you go you go to any web page and there's like 18 facebook uh cookies for you know all of its different properties and uh google ones for all of their different properties and then that way they can track you across the world and you know everywhere you go they can know like oh i see that you're looking at uh guitars or comics

or whatever you know and then it pops up everywhere you go from that point on yeah i saw that you were reading spider-man earlier how about all of these showings for the spider-man movie it's insane man um another thing they say is make sure that you have the expiration on the session also set on the server right you'll probably want it in your client as well but make sure it's on the server so that you know somebody does come back tomorrow and they should have been logged out but but if you didn't have anything set up for that, then they're just going to pick back up where they left off. Asterisk. Because this is going to depend greatly on the type of application. You might very well want them to pick back up where they left off. Take like a Google Drive, for example, or anything, Google, a Facebook, you know, you want them to pick back up.

Banking and financial? No. You don't want your credit card company, you, you want them to pick back up banking and financial. No, right. You don't want your credit card company. You don't want that, you know, that session to be alive, you know, for, for much longer after you've been inactive. That's a good point. So some of these, some of these security recommendations, you have to like weigh with, well, what is the end goal of your application? What's the expected user experience? And maybe some of these are more applicable than others. Yep, totally. Yeah, we're so spoiled now.

Pretty much every framework now has a logout method, and it'll interact with whatever Django has one, ASP.NET has one. If you go off the rails and decide to implement your own kind of like login, password, kind of reset session, all that one. If you go off the rails and decide to implement your own kind of like login password, kind of reset session, all that stuff,

then that's when the stuff really becomes applicable. So, you know, wherever you can, uh, definitely frameworks are so, so nice these days. Yeah.

Yeah. I definitely liked some logging frameworks. This is a good time for us to mention our new sponsor, uh, Apache log for J. Oh God. Uh, and then last but not least never ever ever trust user input right so if you even if you do have things coming up from a cookie check them and make sure that the values are what they are like like jay-z was saying earlier

you know back in the in the golden days he would just swap his user type from user to admin, right? And then all of a sudden he had something. Well, on the server side, you can go and look and say, Hey, uh, Jay-Z is not supposed to be an admin. So he doesn't get these rights. So, you know, make sure that you're, you're validating the inputs that you're getting. If it can be touched by a user. This episode is sponsored by Datadog, the monitoring and security platform for end-to-end visibility into your Java applications.

Datadog provides out-of-the-box customizable dashboards, actionable alerts, distributed tracing, and always-on low- low overhead Java code profiler for your production environment all in one place. Can you believe it? All in one place. With support for over 450 technologies and automatic instrumentation for popular frameworks, you can start monitoring your Java applications alongside the rest of your stack in minutes. 450 is a lot. I didn't mean to go little john there but what

we're very excited about the dog tonight and yeah it's uh with all those integrations it makes it really easy to set up you can google for instructions everything's documented really well you can see what you're going to get and uh as we mentioned the blog is really fantastic for seeing what kinds of things you can do with it and just kind of for inspiration. But really, you don't have to go off the rails. There's so many great integrations and dashboards that you get just out of the box if you have, for example, Java, where you can go click a few buttons, drop in the agent, and start getting that benefit and that value immediately. It's awesome. Joe's not kidding when he talks about their documentation being incredible.

Maybe they're like a technical writer company and we didn't know all this time. That's their core bread and butter there. Because their blog is amazing. Of course, we're talking about Java. They have a whole article on Java monitoring and everything that you can do with Datadog, deep insights into your JVM performance, how you can code level monitoring for any environment. They have perfect documentation out there for it. Find what you need. You easily go to Datadog HQ. You'll find everything you ever wanted to know about Datadog, all the documentations, like how you can monitor

anything that you ever wanted to monitor. I trust you. 450 plus integrations. I guarantee you, if you're using a tool that they aren't already monitoring, it's probably on their road. I wouldn't be surprised if it was on their roadmap. I mean, if they, they're just so good at it.

So start your free data dog trial today to stop that. Start your free trial. Start your free. I said, I said, I said, listen up, listen up, kid. Start your free Datadog trial today to start monitoring in real time. Listeners of this podcast will receive a free T-shirt once you install the agent and create one dashboard. So go ahead and visit Datadoghq.com slash coding blocks. Again, that's datadoghq.com slash coding blocks to get started today.

Okay. Well, I guess our new version of this is howdy y'all. And please leave us a review if you haven't already. We would greatly appreciate it you can find some helpful links there from your good buddy alan at www.codingblocks.net slash review and you have a good texas country sound there this is my texas country is that what this one is i think so i i don't even know anymore uh so, yeah, don't forget about that new darn Spotify. They got them a newfangled podcast rating system, too.

I can't even. You've made it so far, don't give up. Yeah, that's right. You know, it's like you do these voices for fun and then they come back to haunt you so alright so

yeah so now we head into my favorite portion of the show it's time for a joke I saw you you were trying to mock me. I saw you. What? Alright. Why did

the A go to the bathroom and come out as an E? I don't know. Because he had a vowel movement oh yep that's right the dad jokes will not get any better than that all right so good uh now we head into my favorite portion of the show survey says all right so a few episodes back we asked have you ever had to partition your data and your choices were ever more like always or on occasion it's just another tool in my toolbox or once i don't want to talk about it or nope.

Does that mean my data set is small or nope, not my job. All right. So according to detect co's, uh, trademark rules of engagement, uh, it is,

what is this episode 77? So Alan, you are up first. I honestly don't know where people are going to go with this one. Um, I, I think the overwhelming is going to be, nope, not my job. And let's go with 33%. Okay. Okay.

No way. Nope. I'm going to go with on occasion with 33%. Okay. Okay. No way. Nope. I'm going to go with on occasion with 33%. Okay. So this is, this is interesting. Alan says, Nope,

not my job. 33%. Math. I'm a chicken set. Math. I'm a chicken says on occasion, 33%. You both wrong.

Wow. Nope. Does that mean my data set is small? Is the top answer. Okay. All right. With what percentage? That was 32%.

Oh, so we overshot it anyways. This was pretty well distributed then. Here's where I thought it was interesting. Joe had the number two answer. Joe had the number two answer. Alan had the number three answer. Okay. All right. Yeah.

All right. So I kind of won. I mean, you know, I thought you might find the silver lining there. Yeah. Yeah. I just want to focus on the important part. Right. That makes sense. I kind of won. you know happy thoughts happy path i get it um except now let's talk about game

jam some more right i mean especially happy paths because i know while uh joe was working on his he completely forgot about the happy path. He was so focused on the negative path. So, so, uh, how about this for today's survey for this episode, or are I learned so much or I forgot how much time I need to play other people's games or I thought my game was good but oh my some of these are pro-fesh or I now know I that I want to be a game developer or I now know that I do not want to be a game developer.

And people could actually still go up and play these games, right? Will they be able to, by the time this is out or no, you can still go play last year's games. Yep. Oh, right.

Yeah. They're always available. Once they're up on, you vote on them still like, no, this is really, you can't vote on like last year's. No, this year's.

This year's. When this is released. No, that would have been a good idea, but the voting will have... Actually, it closes the day this episode drops. All right. So you might be able to hurry up. So after you hear this, go play the games. Yep.

Or more importantly, just vote on the games. Vote on the games. If you can vote, definitely play them no matter what. Vote if you can. Yes. There we go. This episode is sponsored by Linode. Simplify your infrastructure and cut your cloud bills in half with Linode's Linux virtual machines.

Develop, deploy, and scale your modern applications faster and easier. Whether you're developing a personal project or managing larger workloads, you deserve simple, affordable, and accessible cloud computing solutions. Yeah, you can get started on Linode today with $100 in free credit for listeners of this podcast. You can find all the details at linode.com slash codingblocks. That's L-I-N-O-D-E dot com slash codingblocks. Linode has data centers around the world with the same simple and consistent pricing,

regardless of the location. You know, Linode has been running since 2003 with a mission to make cloud computing simple, affordable, and accessible to every developer around the world. And they've been, they've been successful.

They've been doing it for that long. I, I can't remember when I first heard him, but it's been at least like 10, 10 years ago when a buddy of mine was running a site and doing really well on it. And it's still just as quick to set it up as it was back then. You just a couple of clicks, you can get virtual machines set up. And just a couple of clicks, you can also get Kubernetes set up, which I've done now a few times. And that's a huge accomplishment that they're able to just provide you what you want as a developer. Yeah. And if that's not easy enough for you,

you can go to their marketplace and say, oh, you know what? I want my own VPN. I don't want to pay for anybody else's VPN. I want my own VPN. I can easily set that up on Linode. It's in the marketplace, open VPN. But you know what I really am interested in these days? I want Grafana dashboards for my Factorio game. So, oh, but guess what? I can also set up Grafana easily from the marketplace. One click, install done with Linode. So choose the data center nearest to you. You also receive 24 by 7 by 365 human support with no tiers or handoffs, regardless of your plan size. And you can choose shared and dedicated compute instances, or you can use your $100 in credit on S3 compatible object storage, managed Kubernetes, and more. Hey, if it runs on Linux, it runs on Linode.

Visit linode.com slash coding blocks. Again, that's L I N O D E.com slash coding blocks and click on the create free account button and get started today. All right. So here we are back. We're in the final stretch and this part, just 25 more pages to go. That's right. Now we're going to talk about permissions so this is pretty interesting these are these are some good things that come in here so like when we're talking about permissions they're talking about making sure that you're limiting permissions on on the kinds of things that you have out there so like one of the things that they said is try to avoid using sudo in any shell scripts if you can.

And if I put avoid in there twice, that's confusing. But yeah, so is it sudo or sudo? I would say sudo. Yeah, sudo. I always said sudo too, right? But some people say sudo, so I just went with one of them.

Alright. Yeah, well those people are wrong. I mean there are people went with one of them all right yeah well those people are wrong i mean there are people that are wrong in the world and those are those people oh speaking of wait wait before we go back so this this reminded me sudo sudo um the whole gif gif thing and some of those other things right the sock sock shoo shoo thing came back up on slack recently and matt carlson actually posted a thing have you guys seen this yes to where it's like the internet has voted on all these things so amazing man yeah and i believe that the answer that he went with was sock sock shoe shoe yes and it was overwhelmingly sock sock shoe shoe well it wasn't even close it was like sock, sock, shoo, shoo. It wasn't even close. It was like 80 to 20 or something. I don't know.

I mean, I question those, the people that voted there. Yeah. I need to find that link. I got to find that link. They must have asked like Roblox or something. Roblox community. I think they asked like the same person like to answer it a hundred times. A hundred times a hundred times

and oh man you know the show uh family feud yeah yeah and they get like a hundred people and they ask them you know like hey what are you doing dad leaves the house and they'll get answers and people to guess i'm like who are those hundred people they ask because i was at the dentist the other day watching and like the things that those hundred people were saying, I was like, no. I know. I know. What? I don't know the answer, but I know if I was a producer of that show how I would do it.

Yeah. Do you want to hear? How would you do it? Yeah. Well, you have a captured audience. Yeah. So I would ask people survey questions that I would use in a future episode. Yeah.

Yeah, that's a good way to do it. I would like to do it for that episode. So when you see the freaky stuff that people say, allegedly. You call them out. You can look around you and know what those people really do when the lights are off or whatever it is. Yeah, I guess. Okay. Yeah, because I was thinking Price is Right where they would come up to be a contest to be a contestant but yeah you're right in uh family feud they wouldn't it's mommy

oh my god now i gotta put a link to that we need a link mommy steve somebody's gonna somebody's wanting to i'm telling you if you okay listen dear listener i know we're on a tangent all right and you're like this isn't even the first one of this episode and you're not wrong and it won't be the last but if you haven't taken some time to just watch some of the best moments of Family Feud over the decades. You can go to YouTube and you can easily find Family Feud funniest moments or whatever. Oh, man, there are some gems out there. And what's best, I don't know if you've ever seen any of the ones

where it's not the stuff that was put to air. There's definitely the best of clips where it's like what you that was put to air. Because they'll show, there's definitely the best of clips where it's like what you saw aired on TV. But there's also other ones where it's like the full scene where they cut it down. Because there's one, and it might be the Mommy one specifically,

where Steve Harvey was the host at the time. And he absolutely just loses his stuff. He's like, I mean, it goes on for a while. He's like, you gotta be kidding me. And the audience is just losing it.

Right. Because it's hilarious. I will definitely find the mommy when to, to put in the show notes, but yeah, there, there's some, just do yourself a favor,

go, go find them. And you're welcome for this one. This one, this one, if it doesn't make you laugh, you have no humor in your soul. Grab a bag of dots pretzels and sit in front of YouTube and you'll probably choke laughing on the dots pretzels. And, you know, maybe you shouldn't do that case because we want you to keep listening.

So don't choke on it on that. But yeah, it's amazing stuff. So what I was going to say, though, about going back to the to keep listening. So don't choke on, on that. But yeah, it's amazing stuff. So what I was going to say though, about, uh, going back to the, to the show now. Okay.

So tangent over, um, uh, this, this kind of falls in line with the, uh, uh, least,

uh, the principle of least, uh, permission, right? Where like you try to do all of your, you try to do all the execution of whatever has to happen, like scripts or other executables or whatever.

You try to have those run under the least permissive permissions that is allowed to get the job done. And then that way, worst case, should an attacker be able to gain access to the system and through that process possibly, then they are severely limited. So this is why you don't want to use a pseudo to, to do it because then you're like elevating it up to like maximum, you know, privilege on the system.

And, you know, if the script that you were running in the, as you know, under pseudo had the ability to, you know, or, or maybe had a bug to where somebody was able to take advantage of it,

then guess what they're running as. Right. Yeah. And that's a good way to escalate privileges for attacks too. Like we mentioned sessions earlier. I don't know how you can configure it, but if you ever notice you run like two sudo commands or sudo commands in a row, like you typically don't get prompted again for the second one because it's got some sort of window on it where it's like you know we just asked you for your password you're obviously doing it again uh let's go ahead and so you can imagine uh if somebody can inject something into your script uh or you get you to run some kind of code arbitrarily that it's easy to kind of take that and then maintain that and they can just keep that permission which is bad so even after the command that you ran it for uh is finished and so yeah bad news uh

and really you have to kind of ask yourself what you need to be root for when you're doing these kind of scripts so i tend to think of like when i think of scripts writing scripts just for like little stuff around my computer automating things and so that's you know one thing but it's a whole other thing to have scripts running in like some sort of automation or build servers that are that are sudoing which is like a whole other kind of level scripts running in like some sort of automation or build servers that are, that are sudoing, which is like a whole other kind of level of scary. Yep. It doesn't even need to be like, I mean that definitely that's an example,

but like even with you know, in the case of like you mentioned build servers, like, you know, shared credentials or whatever, you know, it would also be bad to like I guess you just, yeah, whatever. I mean, you want to be wise about how, how credentials and how elevation of privileges are used and use it sparingly and wisely. Yep. And, and the other thing you want to do too is revoke any permissions you don't need, right? So I, I'd venture to say as developers, a lot of times, you'll set up permissions on something that you're doing to give you like as wide open access as you can get

just so that you're not running into walls constantly. But when these things ship, you want to make sure that it's only got the privileges it needs to do exactly what it's supposed to do, right? So an I, an example, like if you're in, in Google and you're dealing with pub sub, right? Like there's, there's a pub sub editor role. There's a pub sub viewer role. There's a pub sub subscriber role, like know what you need that thing for and, and set just that permission. So editor gives you a

bunch of them and that makes things easy, but it also means that people can modify these subscriptions. It means they can do all kinds of things with them when maybe all you want is somebody to subscribe. So, you know, lock it down only in, in, if you run into something else that you need, then add that one permission. And this is, I I'm curious what you guys think about this. This is where, where things get hairy. Um, so a lot of times in, in systems with permissions specifically,

you'll see people want to err on the side of roles because roles kind of give, give you a bundled set of granular permissions, right? But that kind of goes against the whole notion of just give it exactly what it needs. So I'm curious what you guys think about the granular permissions versus the roles, right? Like, do you go to role slash editor or do you do pub sub dot subscriber pub sub dot viewer? You know, what do you do? It it's such a it can be a real pain like the problem is is like there's this pendulum the swinging right and on the one hand hand you're just like just pseudo forget it just just pseudo right and then on the other hand you're like oh we need to have like granular controls and you're like okay well now we have 18 billion of them oh

man we swung too far the other direction right yeah and then you're like, okay, well now we have 18 billion of them. Oh man, we swung too far the other direction. Right. And then you're like, okay, well then we'll just bucket a whole bunch of them together and call it like editor. And then you're like, okay, well maybe that's a little, we swung back a little too far. But the, but the problem is like, you know, you were spent mentioning specifically like GKE, uh, you know, um, or no, not specific to GKE, but GCP. Yeah, thank you. But like Azure and AWS, like any of the cloud environments, you know, just there's so many of these controls.

Thousands. That it can really be a nightmare. Like, you know, I was thinking of the GKE environment because of all the very many, many, many, many, many, many, many different roles that you can have in your Kubernetes, you know, your Google Kubernetes environment that it's frustrating, man. Like it's, I mean, I get it. Definitely having the granular specific ones and only using those is definitely going to be the most secure way to do it. And if you're doing something super secure, like financial related, or maybe because of like government restrictions or health restrictions, you know,

but otherwise, man, it's just like, I just want to like get my stupid game jam game working. Right. Oh, it hampers you. There's no question, right? want to get my stupid game jam game working. Right. Oh, it hampers you. There's no question, right? Like when you're trying to figure out, okay, I need this thing to work.

Which one of these 20 permissions that are under this one role do I need to make this happen? And it wears you down sometimes. You're just like, I don't care anymore. But you can't be that way. And it's, it's hard. And either way, you need a whole process around approvals and kind of keeping track of that.

Cause there's nothing worse than like seeing a user, not sure what it's used for. If you still need it, uh, who requested it? Like, does it actually need all this stuff? Like all,

all that just, you, that process is so painful, but it's important. Yeah, totally. And so here's the next part of this that stinks. And I'd say that a lot of times we as developers, we as people who do this stuff, we don't do this, is create separate users for separate needs.

And the one that jumps out in my mind is database access, right? Like I'd venture to say, if we had done our poll on, you know, how many people have a single user that accesses their database for their application, right? Like there's one thing that has DBO access to everything. That's how a lot of things are done in a lot of places.

In reality, you probably need things that are read-only access users. You need things that can execute certain prop access users. You need things that can execute certain access. You need some things that can write. You need some things that can drop, create. Like, that's the reality of what should be done. But in practice, it's just not done because it's so inconvenient to set it up and to manage all that stuff in a way that's not going to be a nightmare to try and get your application to work that it's just not done. I like it so much.

But it's so nice to see like, hey, this was this was files created by this user or this bucket was created by this user, not this role. Right. Not some generic user. Right. Yeah, it's that kind of stuff's frustrating, but if you can, and if you have the wherewithal to make it happen, create separate users for those,

for those needs. And this is, so this is one thing that was interesting is they were like, Hey, you know, like if you need something that needs to be able to delete files from a bucket, right?

Like an S3 bucket or GCS bucket set up a service account with just that permission. Well, this is where things get nasty, right? Like you're going to have 500 service accounts for each type of thing that you need to do. Maybe that's the right way to do. And to outlaw's point, if you're doing something in the medical industry, you better do it anyways, because it's your duty to protect that information, right? Um, if you're doing the duty, that's right. Beavis, um, but, but yeah, I mean, so it kind of depends on what industry you're in and what the needs are, but you know, in some cases you got to do it. Um, they said the same thing. Like if you're managing computations, all that kind of stuff, whatever,

at least, least permissive, like I'll all said, this episode is sponsored by shortcut. Have you ever been really happy with your project management tool? Most are either too simple for a growing engineering team to manage everything or too complex for anyone to want to use them without constant prodding. Shortcut is different though, because it's better.

Shortcut is project management built specifically for software teams, and they're fast, intuitive, flexible, and powerful. Let's look at some of the highlights. Team-based workflows. Individual teams can use Shortcut's default workflows or customize them to match the way they work. Organization-wide goals and roadmaps. The work in these workflows is automatically tied into larger company goals.

It takes one click to move from a roadmap to a team's work to individual updates and vice versa. And tight version control integration, whether you use GitHub, GitLab, Bitbucket, shortcut ties directly to them so you can update progress from the command line. They have a keyboard-friendly interface. The rest of Shortcut is just as keyboard-friendly with their power bar, allowing you to do virtually anything without even touching your mouse. Iterations planning. Set weekly priorities and then let Shortcut run the schedule for you with accompanying burndown charts and other reporting. Give it a try at shortcut.com slash coding blocks. Again, that's shortcut.com slash coding blocks shortcut,

because you shouldn't have to project manage your project management. All right. And now we're down to the final section. And this is where they get into and they start talking about other classic vulnerabilities. And honestly, this section was really interesting. I know, Jay-Z, you didn't do your homework. So you're going to miss out on some of this. I mean, we're not going to call you out on it, Jay-Z.

But I mean, it wasn't that much reading. He called himself out. So we could do that. But there was some interesting stuff. We'll go through it. And then I'll tell you the one when we could do that um but there was some interesting stuff we'll go through it and then i'll tell you the one when we get there that i thought was so cool um so there's the buffer overflow um i we've all heard about this if you've never heard about how it's used in practice it's kind of crazy um basically data is being stored in a place that it shouldn't even be able to access, right?

Like more or less, that's what happens in a buffer overflow is, is you overflow the buffer space and then data got stuck somewhere. It shouldn't be. Um, and these are usually used to execute malicious code because what happens is the malicious code puts that malicious code in a spot in memory that's going to get executed. It's almost like a callback after, after the failure. And then it just runs that code. And that is how a lot of this stuff happens, which is really crazy to think about. Yeah. It, anytime you can like crash an application if it's your application you need to be worried

because that's that insane where it this could probably happen yeah that that's that's the crazy part it's usually on an application failure when these things are executable. Um, so this, they start talking about like, they, they went into a little bit of detail on this, like how this is done. And I'd never even heard of these things. So typically with a buffer overflow attack, there's this no op sled that they, it's a nop sled is what they call it um but they basically fill up the stack or the buffer with a bunch of no ops which are basically non-operations right it's it's more or less null um blocks that they put in here and then after that they put their malicious code at the end of it and when the thing crashes it more or less executes that last piece of code.

So you had this huge empty set of buffer with the bag code at the end, and then it picks up, runs that thing at the end. And apparently this is the part that was so cool to me is it's really easy to get a root shell doing this. Like they link to an article. I have a link down in the resources, but it's, it's nuts. Like they show exactly how you can do this to get a root shell on, on a Linux box by doing this exact thing. I'll be right back. Yeah. You ever seen a, you ever seen a demo of Metasploit? yes yes like i don't even know describe just the application that makes it uh it's got a bunch of well-known exploits and tools for like shelling into things and uh just all kind of ready for you so you can kind of like browse around and try different kinds of attacks on systems and then try to get access and when you have access they have the tools

they're ready for you to also uh take advantage of that access so it's not just enough to just get uh just find a buffer overflow but also once you find a buffer flow in order to actually exploit it and then give you a shell and you know be able to actually make do useful things with it and so it's really cool stuff you should watch it and be terrified it's basically like an application that has a library of all known vulnerabilities and exploits. And you're like, Hey,

go over here and let's, let's run it through. And it'll be like, okay, I found that it's vulnerable to these three, which here's like the, here's five options for each of these three that you can use. Yeah.

Please don't be a jerk. We're telling you about Metasploit. No. So, so actually disclaimer here, we're not responsible about metasploit um no so so actually disclaimer here we're not responsible for anything you do with this like in all seriousness um if you if you go get that tool no it's exactly what outlaw said not only is it just have a bunch of libraries of these exploits it makes it so easy to do the exploits because it's almost like an automated push button fashion of doing it.

But know that if you do this and you get caught doing this on some server that's not yours, you could potentially go to jail or face major prison time fines, whatever. Right. So in all seriousness, Metasploit is scary if you ever see it in operation. It's not hard to use, but don't go out there playing with it on other people's stuff because it could be really bad. It's basically like this we talked earlier in this series about the fact that um there are databases of rainbow tables and whatnot that exist right and and that was like a collection of like here's known hashes and what the password what that equals in terms of the password and you know so like there's these databases of these things and we've also talked about like you know, so like there's these databases of these things. And we've also talked about like, you know, pwn2own where there's databases of like the hash passwords and the users that go along with them, right?

Well, you know, in the hackers or attackers arsenal, they also have tools that can say, hey, here's all the exploits that I know that exist for this operating system. Here's all the ones that I know that exist for this other operating system. Here's for this web server. Here's one for this web server. And, you know, if they can get any kind of information about you, then they can like kind of, you know, start to tailor that tool to that specific thing. So like one of the things that we talked about, and I think maybe in the last episode or not, but we had talked about like this like kind of phishing exercise that you go through because like one a part of that, like there's the

new version of phishing where they refer to it as like email phishing scams. But you know, in that episode, we had talked about, you know, an older definition of phishing, where it was just referring to like not leaking out any kind of information. Like, and in that particular episode, we talked about it in the, um, in regards to yes, that user exists, but you entered the wrong password, but there's also other forms of information leakage that could be like, what version of, you know, Apache or engine X isginx is this web server running? What operating system is the web server running? There's all these simple things, several things that are out there like that,

that all of those are like little bitty clues that are like, oh, I know, all joking aside, that that specific thing is vulnerable to this version of Apache log for JBug. I wonder, can I take advantage of it and so yeah and the tools help you do it yeah the tools are just there to automate it yeah so again we recommend being aware of them maybe even taking them and if you want to play with them on your own server do that do not go hitting other people's website servers whatever because like jay-z said you can get arrested you can go to jail it's not a joke um it's nasty it's also expensive you know so metasploit does have like a community version

but you know how much the pro version costs it ain't cheap no yeah all right 15k a year wow yeah i was gonna say 1500 i was way off yeah i didn't i had no clue it was so expensive yeah i thought it was a one-time fee but i didn't realize it was a yearly fee yeah yeah yeah and i do know that a lot of companies actually have employees, you know, that they pay to actually do this, right? Well, there's red team, blue team kind of thing. Yeah. Yes. Yes.

So you'll pay your employees to say, hey, I'm going to set up an entire environment that's just like our production environment. See what you can hack, right? See how you can get into that. And that's, you know, that's the thing. So, so two thoughts on that. First is, you know, if you, if you are hearing this and weren't already aware, or, and you're like, oh my, how do I, how can I help protect my company? Like there are legitimate companies and services and tools out there that can scan your, uh, you know,

site, for example, your website, uh, on a regular basis, looking for, uh, you know,

these, these, uh, vulnerabilities right in, in alert you. Um, I'm sure that there's similar things for, uh,

internal networks of two, but I, you know, I'm more familiar with the website ones, but, um, it's interesting that you bring up the, the red team conversation though, Alan, because, uh, I was just going through, uh, some, uh, I was catching up on some of the security now episodes and they were talking

about all the log for J, um, bugs that, you know, and, and we're not all of the bugs, but just, you know, that whole debacle. Right. And the question came up of like, how could you, like, is there a way that you could ever possibly write a bug-free secure code from the beginning? Right. And of course the answer was like, well, I mean, that, that, that's a tall order. Right. So, you know, let's just say, no, it's not possible. But one of the, one of the, uh, things to like, well, if you were to try to do everything that you could towards that regard, then you would play red team versus blue team. So, you know, your blue team is doing development, but you have a red team that's constantly attacking

what you're, what you're developing to, you know, they're looking for stuff. So they would have this tool, like a Metasploit tool or like other tools available to them. And they're constantly trying to find the pinholes in your application. And they're like, open up 15 new tickets for you.

You know, I mean, you'll hate them, but right. No, we didn't mention that path reversal too but that's always a good one where uh if you have some sort of script or something i guess we talked about this a little bit with uh with injection attacks uh you can make it so uh other people can either pass arbitrary files and get you to execute them or basically change the past and do a couple dot dot dots and get you to execute some other program on the

server. And hey, guess what? Servers a lot of times often have commands that can do really bad things. Even curl can be really bad. You can post a file out to some arbitrary address. People can do really bad stuff with that. And yeah, so basically just talking about when you're breaking out of that web server's

directory and able to access and do anything else from somewhere else in the server. Uh, just kind of scary stuff. Yep. They also called out, you know,

remember your dependencies that you use also have vulnerabilities, right? That node modules folder, right? Yeah. I mean, yeah, there's so many things and you don't necessarily think about it,

but the best way to mitigate and handle this is just like Outlaw said, you need to have some tools that run scans on your stuff, right? Like that's that's about the only way you can mitigate this because you can't stay on top of it and check these things. Like, I mean, it's impossible to do it in a manual way. You bring up the node module. Did we did didn't we just recently talk about the the hacks that happened i think it was like to faker js and uh there was another they weren't attacks though yeah they weren't author they weren't but they could have been so much worse yeah but he he the author bricked like two of the modules that he was the author of

but but you could see where like where it could have been easy. And there are attacks that happen to Node specifically to JS packages. So one of the clever things that GitHub and other places do is they can see all the repos that are using, that have dependencies on certain Node node modules and and uh warn you of like hey that one's got this particular issue we've gotten emails on those

yeah i mean if the the fact is if you're doing any kind of js development and you're using one of these main libraries you've probably got a notification at some point in time. Yeah, for sure. Um, so go ahead. I was just going to go on. All right, hit it. Oh,

I was going to say, uh, some of the other things wanted to mention. So side channel attacks, uh, such as something, um, much less common, but still happens.

It's really interesting too. If you remember things that when, when people were talking about like row hammer and stuff, um, well, I don't know, maybe that's even a different kind, but,

it's basically using information that's not necessarily part of the process to get information about that process so we've kind of talked about this a little bit where um you know either that information is leaking somehow like for example um if you try to log in or something and the thing the message comes back and says hey that's not your password remember you changed last month or you know as opposed to if you're a user um you know that might be an example of something some information that you can kind of leak and that's also related to timing attacks which are um basically understanding how long processes can take and using that to figure out for example if the string matches or how close

you're getting and then um yeah i, I mean, I mentioned Rowhammer, which is, I can't even describe it accurately. So I don't even want to attempt it, but just an attack that's kind of reminiscent of some of these categories we're talking about. Yeah, so the time, go ahead. Well, I was going to say, because one of them on here

is like the acoustic cryptanalysis. And there've been some very interesting ones. I think the first one that i remember hearing about was that someone from georgia tech had created an application for the iphone to where the iphone could listen to you type and they could figure out what you were typing your passwords based on based on the you know the sound that the mic, that the, that the iPhone was recording. And that type of, that type of side channel attack is what, you know, it's completely disconnected from the computer. Right. And that's what that is. Like

there, there've been movies too, like this, like, um, do you remember Eagle Eye? Do you remember that movie? I haven't seen it. It had, um man, I'll look it up, see who it is. I'll put a link to it in IMDb. But at any rate, one part of the movie is where the super AI computer, it was looking at the vibrations that were coming off of a bag of chips to figure out what was being said. That's a Hollywood example, but,

uh, you know, that's what the, the acoustic crypt analysis is talking about is like where you're using sound. And there've been like all kinds of crazy examples of like that going through, uh, walls. Um,

people like, uh, you know, figuring out from the, the sound of the fans, what you're doing. It's crazy examples. That's insane.

Yeah, I've actually heard of them listening to the sound of the electricity going through this stuff, right? Like they can actually really deeply identify information. Yeah, PagerData has an example of power analysis, which is kind of similar, basically using the power draw to figure out what might be going on at a very uh very detailed level which is really crazy i will say with all this stuff like we're definitely getting into exotic stuff uh for the most part if you look at uh wasp pod 10 they say every year like people like the most common exploits are the most common like basic stuff it's like yeah phishing attacks is like number one every single

year so while yeah maybe maybe someone can listen to your bag of chips on your desk that's not going to be the thing that gets you probably it's probably going to be the password on the sticky note you know yeah let's be real if it were going to be the thing that got you like the bag of chips that's the stuff that they're trying to attack governments with right they're not trying to attack consumers with that i was going to say like that would that type of thing specifically would probably be like a nation state actor that's going to do it. And it's a very targeted effect or a attack.

And even then those types of side channel attacks, whether it be through the power or through the sound or whatever, they're, they're usually the fidelity is not nearly as good, right? Like they're, they're, you know,

if I press my key, if I press the G key on my keyboard, my computer has a, you know, incredible fidelity that it knows, like you press the G key, but you know, if it's an iPhone listening to it, then it's like, I have, uh, you know, uh, a 67 or a, you know, 47% confidence that the G key was pressed. And so, you know, they get, they get, you know, pretty good results, you know, you know, they get some impressive results, but it's not to the same level, you know? Yeah. It's way more complicated for trying to get data on systems that are way harder to get access to, right. Which is the only reason they're doing it. And the last one that we had here

for the side channel attacks was data remnants. So basically getting data from things that you thought were deleted. And this was a really big thing with hard drives, right? Like people would throw away their computer or turn it in or whatever, sell it. And they thought that they had erased it. And there was a thing called secure wiping of drives that, you know, when you got into data forensics and

whatnot, that was a really big thing. I actually remember when I was in college. So there's been, you know, a year or two ago, um, there was a guy that came in that was talking about that. And he said, you know, when they were, when they would go in and do cyber, um, forensics or whatever, and go into a place and get data when they were done with those drives, they would wipe them like 20 times, right? Like doing the secure wipe so that there was no trace of things. And that was the first time I'd ever heard about it. So if you don't know about this, when you're writing, reading and writing on hard drives, you know, you're saving ones and zeros. Well, if you just wipe it a lot of times, you know, you're only zeroing out sectors here

and there. You're not doing the whole thing. Oh, you're not even doing that. That was the thing. Originally, you weren't even deleting the data. You were deleting, there was a file allocation table, which is what the FAT file system was originally named after. You were just deleting that, which had the pointers to users.txt starts on this address. So the data was still there, so you could still go and try to manipulate it, figure it out, and piece it together yourself if you had the right tools. Yep. Whereas a forensic wipe would actually go through every single bit on the drive and write it, rewrite it, rewrite it, rewrite it so that it get rid of any magnetic trace of whether or not it was a one or a zero, right? It would try and get it close to neutral as possible. In in, on current drives. This is less of a need because,

uh, you know, if you're, if you're using an encryption to, you know, as part of your bit, like a bit locker or file vault, depending on your operating system,

or, you know, you're using something else like, you know, rumor of the days of true crypt, um, like whatever it is, it's kind of lesson.

It's less of a need now, but like on windows, for example, there's the cipher executable's less of a knee now, but like on windows, for example, there's the cipher executable spelled with an I C I, uh, that you can use to wipe the drive, a drive, or you can use it to wipe the free space of an existing drive.

And in Mac OS, I haven't checked in like recent versions, but I know on older versions where, you know, before they were using solid state, um, they had the, uh, in the disc utilities, you could format the drive or, or erase the free space. Well, I mean, either way they Mac OS referred to it as a race, but, um, you could specify the security options.

And one of the options was like a 35 pass. I think it was. And in both, in both cases for Mac OS and the windows operating system, the way those two work is it does one quick, right? Where it runs through every sector of the disc writing zeros. Then it doesn't second a quick run through it where every sector of the disc, zeros. Then it does a second quick run through it where every sector of

the disc, it writes a one. And then it does another pass where it'll write something random. And the random steps are where you spend all your time because writing the ones and zeros, even on large drives, it's like, you know, I mean, it takes some time, but it's pretty quick. But, you know, because it's not deterministic in how it's coming up with the random part that it's writing, that's where it spends all of its time, you know, doing it. So it can take a while depending on the size of the drive. But it is really interesting that, or if you didn't know this, that, you know, people can recover data off drives and whatnot if you never knew that. You'd want to have a really good reason for doing it on an SSD. If you didn't use encryption on it already,

because if it was an SSD that you cared about and you wanted to reuse over and over and over, you know, after that, you'd really want to think through using either of these kind of utilities. And I'm, I'm positive that Linux has something similar, but I just don't know it off top of my head. It's probably like a DD command or something. But, um, uh, you know, you could, because with SSDs, you know, you don, because with SSDs, you know, you don't want to, you don't want to wear out the chemical as you,

as you write to it, you know, cause they have a limited read, write shelf life. Right. So I think we have reached the end of pager duty. Yeah. We have reached a Neil Patrick Harris and a wait, isn't that right? All right. Yeah, we have reached Neil Patrick Harris.

Wait, did I say that right? All right, well, if we zip to this next part, we can be done in less than three hours. Let's do it. Yeah, actually, this one's pretty good. So we've got a bunch of resources we like. Yeah. We'll have a bunch of resources that we like, including links to the things that we mentioned, like Fire Sheep, Metasploit, it's a me it's a mommy i which i've never seen that so i'll be watching that later are you serious oh yeah i don't know what that is you can thank us yes uh yes very

excited oh man i uh almost had us uh anyway so we're on to uh tip of the week oh but i'll let out i'll say oh man i'm jeez full in shiny shop. I just got excited by Alan's tip because I almost used one from him, too. But anyway, outlaw, take it away. All right. So before we do this, I want to make sure we blow the three-hour mark. So before we do that, I want to take a quick tangent, if I may, if I might, if you don't mind. I'm just kidding. With that, we head into my favorite portion of the show.

I'm sorry. It's Alan's favorite portion of the show. Joe threw me off. I blame Joe. It's the tip of the week. Yeah'm sorry. It's Alan's favorite portion of the show. Joe threw me off. I blame Joe. It's the tip of the week. Yeah, baby. All right. So I was totally unprepared this evening, which is why our Slack channel

is so amazing. So if you haven't been there, first off, you should go there. Codingblocks.net slash Slack. If you can sign up there, I believe, right? Jay-Z, I think you fixed that. Yep, got a link. Killer. So go check it out.

But there is a Tips and Tricks channel in our Slack community, and it's amazing. And Simon Barker, who is also awesome and is always leaving good stuff in there, he had one that I thought is useful, especially in this world that we live in where we're still a lot of us doing remote work and zooms and um you know whatever meetings you're in team zoom webex whatever uh there is a tool a software tool that you can get and it's from re-incubate.com slash camo. And you can use your phone as like a pro level type webcam. So if you don't have the money to go drop on a DSLR with a nice lens and all that kind of garbage, you don't want all that sitting on your desk. Anyways, this is a good way to get really good video way better than any webcam that

you're going to get with a device that you already have by installing some software. And I went and looked at it and it does look pretty nice. So, um, now just a pro tip here. Yep. Yep. If you do this right. And you're on the meeting and you think you're being all sly and you're like, I'm going to mute it. I'm going to go to the bathroom real quick, and I'm going to take my phone with me to read some stuff while I'm in there. Just saying. Yeah, leave your phone or have another device. Take your iPad.

But, yeah, I mean, this looks pretty good. Like, in all honesty, they've got some color correction. They've got, like, this whole, you know, bokeh type effect for the background and all that. Like, it looks like it's really good. So, you know, use what you already got. And if you've got a Samsung Galaxy S21 Ultra, you can even use that 100 megapixel camera on there. Put it to use, right? Zoom in on the zit on your face like at you know 30x and

you'll be good why why why wouldn't you why would you go there why wouldn't you i mean you need to show it off that's right oh boy well speaking of simon barker uh i almost had a tip from him uh did you know that he has a podcast? I did. I just found out about this. I don't know. Simon is fantastic. You should follow him on Twitter. I'll look that up in a second and have a link in the show notes. He's got a podcast. He's in the middle of rebranding it though.

That's why I didn't bring it tonight. Next week, that'll be my tip. I told you naming is hard. Yeah, for real. So yeah, check real. For real. So, yeah, check out Simon Barker. And also, this tip of the week, I had struggled. So, I went to the, you know, we've got that link where you can submit tips.

If you go to cb.show slash tips, you can submit tips, which is great for me. And so, I'm stealing one here from 2020 from micro G who we talk about all the time. I never heard of that name. How do you spell that? Right? Yeah. Mike RG phenomenal Lego photographer also.

So he sent this tip. There's a great site for learning VS code, like all the ins and outs, shortcuts in depth, a bunch of courses on key combiner.com. And they've got a bunch of courses there. Some are free. I think it's maybe one in one new section.

I just did a couple of them and they'll just walk you through, get you really familiar with the shortcuts, teach you how to like navigate, navigate around files. And it's just, it's amazing how many life improvement tips there are in there in Visual Studio Code that you may have never heard of. They also have ones for IntelliJ. I haven't

checked those out yet. Also, things like Gmail is another kind of software that you're probably using, which I thought was really interesting. You're going to be spending a good portion of your life with this stuff. You might as well figure out how to use it. I'll have a link to that. Is it just me, or are you able to get to the site, Alan? Hold on. Let me click it i can't i

wanted to see this and i can't i am being redirected yeah maybe it's down i hit it too hard i think you did maybe i need to like it's not working maybe i have a plug-in that i didn't like oh okay so it's not just me okay all right it'll be back up by the time this episode is live. We can guarantee it. I was there earlier today. Either one of two things. It'll either be up by the time this episode is live or by the time we're done talking. We're not sure which is going to come first. Right.

But it's going to be one of them. I'm pretty sure it'll be one of them. Dude, that reminds me of Spaceballs where they put in the tape and they catch up in real time they're like who jerk what happened that's right well then is now all right we passed it when just now yeah what is this this is now now i can't believe you remember all that almost verbatim that's insane how do you know that movie was so great it It really is good. Alright, so for my tip of the week, I come

prepared with a joke. How does a scientist freshen their breath? I don't know. No, I got nothing. With experiments. no nothing i got nothing with experiments oh that's awful i love it

okay so i like that a lot actually so you're welcome uh no brighten your day so uh speaking of visual studio code joe's tip dovetails nicely into mine with all the amazing things that you can do with it. So, uh, you can also use visual studio code as your merge tool for get. So I'm going to give you a link to a Stack Overflow answer that easily shows you like, here's what you need to do. If you want to do it by command line, here's the, you know, four commands. You just copy paste it. Boom, done.

If you want to do it manually, here's what you need to edit in your get config and, you know, done. But either way, super simple. So I ran into this because, uh, normally, or at least historically I've used K diff for my, um, if I, if, you know, for the visual merge tool and I was on a new environment and I just, I wanted to install as little as possible. So kind of thinking in that same, like, you know, uh, uh, least privilege thing, I wanted to also like install the least amount of stuff, not because I was necessarily worried about like, you know, um, like surface attack platform or anything like that, but, you know, uh,

or surface, uh, you know, attack area surface or anything like that. But I just didn't want to install anything if I didn't need it, if I, if I could get away without it. So, uh, yeah, so that's how I came across this and it's pretty cool. It takes some getting used to, but I do like it personally as well. Uh, and then there was another article that was floating around on, um, hacker news about a week or so ago, the five easy to miss Postgres query performance bottlenecks. So I thought this was a pretty cool article. I had some interesting little tips in here. There were some, some of the things I was like, yeah, okay, that makes sense. But some of them I was like, Whoa, I didn't know about that one. Um, so yeah, I'll, I'll include that link in there as well. And, uh, yeah, with that, I guess we still got some time to go before we bust that three-hour mark.

We got any more tangents anybody wants to cover? Otherwise, yeah, we hope you enjoyed the show. Really huge thanks to companies like PagerDuty that put out interesting engineering blog articles and whatnot. I mean, I know we've talked about Uber and Netflix and Twitter and PagerDuty, companies like them that put these out. It's super awesome that companies are willing to share things that they have found that worked for them and whatnot. And we're happy to spread that around

when we come across it. So if you haven't already subscribed to us, because a friend pointed to this random link and you're like, listen to what this guy sounds like. Listen to his Texas accent. If you want to listen for more of my Texas accent, you can find us on iTunes or Spotify or Stitcher and more using your favorite podcast app.

And, you know, like I said before, if you wouldn't mind, we would greatly appreciate it. If you would leave us a review, you can find some helpful links there at www.codingblocks.net slash review. Hey, and while you're up at codingblocks.net, be sure to check out our show notes, our examples, discussions, and more. And send your feedbacks, questions, and rants to the Slack channel at CodingBlocks.net slash Slack. And be sure to follow us on Twitter at CodingBlocks or head over to CodingBlocks.net. Find all of our social links there at the top of the page.

And with that, I'm Echoes from 90.7. That's CodingBlocks.net. Did you say you're Echoes? Yeah, you ever listen to Echoes? That guy's got the best radio voice. Oh my gosh. That's amazing. I love that.

I thought you were just making that up. No, you never listen to Echoes? No, I've never heard of Echoes. Weird world and ambient music that they play late at night on public broadcasting stations. That was amazing. the echoes weird like world and ambient music that they play late at night on uh on uh public broadcasting stations that was amazing this is echoes yep that's exactly a repeat of it alan it was bad enough the first time it was good i think i think i'm gonna it was literally like

like that was the one that made me cringe as I was listening to it. I mean, that was the guy. That was perfect. That was an impression, not a joke. Nailed it. I will have that as like a future survey. Like, did Joe nail it? I'm going to find out.

We'll have a link in the show notes. That's right.