The Modern .NET Show

Episode 77 - Application Security with Tanya Janca

Embedded Player

Episode 77 - Application Security with Tanya Janca
The .NET Core Podcast

Episode 77 - Application Security with Tanya Janca

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Transcription

Hello everyone and welcome to THE .NET Core Podcast. A podcast where we reach into the core of the .NET technology stack and, with the help of the .NET community, present you with the information that you need in order to grok the many moving parts of one of the biggest cross-platform, multi-application frameworks on the planet.

I am your host, Jamie “GaProgMan” Taylor, and in this episode I talked with Tanya Janca about building application security into your projects and when to do it, regardless of the tech stack involved. Tanya and I also chat about some of the common attack vectors, like SQL Injection, CSRF (sometimes called Sea-Surf), and SSRF and mitigations like Content Security Policy. We also talk about some of Tanya’s bug bears regarding some of the permissions that apps request, even though they don’t need them.

So let’s sit back, open up a terminal, type in dotnet new podcast and let the show begin.

The following is a machine transcription, as such there may be subtle errors. If you would like to help to fix this transcription, please see this GitHub repository

Jamie

So thank you very much. Thank you ever so much for being on the Tanya for being on the show. It is a great pleasure to talk to you. I’ve read your book, which we’ll talk about in a moment. And I’ve missed I think, at this point, there’s been a few streams, we’ve talked through some of the chapters, I’ve missed them completely, because unfortunately, life gets in the way. But we’ll talk about those in a minute. But thank you ever so much for being on the show.

Tanya

Oh, thank you so much for having me, Jamie. This is great.

Jamie

Thank you. So I was wondering, can you tell the listeners a little bit about yourself? They may know already from the episode title that you’re into Dev, Dev sec, Ops, and app. sec. So I was just wondering, could you give us a brief introduction?

Tanya

Yeah, absolutely. So I used to be a dev. So I wrote code and made apps for a really long time. And then I met an ethical hacker or penetration tester. And he said, “You should work in security.” And I said, “No way, being a dev is the best ever.” But after a year and a half of him, slowly convincing me it was fun and interesting, I switched over to security. And very quickly, I figured out that Although pentesting is pretty cool. And it is fun to find bugs and smash things that the part that I was really good at was being kind of that bridge between the security team and the dev team, and like helping the devs make secure software, and just spending lots of time with devs.

And so yeah, I also found out training’s really expensive. So I started speaking at conferences, just so I could get in for free. I still do it. Because having your free ticket to a conference, like it’s awesome. And anyway, so I kept speaking and speaking and writing blogs, and one day, someone said, “Why don’t you write a book?” And I said, “Me? What? No.” But eventually, it made sense. And so yeah, so now I run a training company full time where I teach people about how to create secure software, whether they’re doing DevOps, or Agile, or Waterfall. And turns out, that’s really fun, because I still get to do lots of techie stuff. And I still get to hang out with lots of devs. But I also get to share knowledge for a living. It’s pretty cool.

Jamie

Awesome, awesome. I have to say, the first project that I had, where we had to get someone in to do some penetration testing on it and test all the code for security issues. I was like, “Okay, you got to teach me how you did that. Because I want to know, all of these things, you know.” And that’s where I first heard about OWASP, which I guess we can we can mention later. Which is a great a great little, “little,” sorry, a great community of people who putting all these research into place. Because that’s one of the Yeah, I don’t know, I’ll talk I’ll talk about that in a moment. But let’s talk quickly about WeHackPurple and the book, I guess, because those are great, important.

Tanya

Okay. Um, so the book I wrote is called Alice and Bob Learn Application Security. And it’s basically, if you don’t know anything about how to create secure software, by the end, you should know how; that’s my hope. And I also wanted to make it kind of an easy and fun to read book because I personally, I want all the knowledge from a textbook to be in my brain. But the actual act of reading a textbook, I find to be sort of like a very slow, painful, frustrating, long experience. And so my book is a little bit different than the average textbook, where there’s stories of things that happened to Alice and Bob, so you can see what it’s like, for a real person, if that makes sense, perhaps and when you know, when you make these security decisions. And then I tell stories from my career, and then I have like little tips and tidbits all throughout it, with the hopes to break it up. So it’s not just this giant wall of text. So that was that was my goal and making the book and the feedbacks been pretty good so far. So that’s awesome.

And then WeHackPurple is the company that I started. And so the company we have on demand training. So at our academy, which is online and self paced with like videos, and exercises and articles and everything, but we also have an online community where you can go and basically meet lots of other people that are just like you that want to learn. And some of the people in there are very advanced. So we have more advanced talks, or discussions, if that makes sense. And then we have people that are less advanced and we have like content that will drip to your inbox. So if you’re a beginner, you’re like, “send me beginner stuff only, “or, you know, “send me only cloud security,” or “only dev sec ops,” and we have, like events where we do stuff together. And yeah, it’s just it’s kind of like my favourite place on the internet.

And we have a podcast. So we have the WeHackPurple podcast, and the first season is me interviewing just all sorts of different people with different jobs in information security. So not just my niche. Personally, because like, I’m just really curious. And I really like to know about all the different types of jobs, like I find forensics absolutely fascinating. And so being able to ask, you know, someone that’s worked in that for a really long time, everything about it, how they got that job? I’m not exactly sure what next season’s gonna be about yet. I’m pretty probably gonna be upset. I mean, let’s face it. But yeah, so it’s pretty exciting. We just started actually giving live virtual training as well. And that is, it’s interesting, because it costs a lot more money, but people buy it way more. Or companies buy that, if that makes sense. And individuals buy the online training. It’s so it’s, it’s interesting companies are like, “why would we buy online training when we can buy you?” And I was surprised by that and was, “like, okay, I can show up places.” Virtually, I can virtually safely show up places. Yeah. So starting your own company is hard.

Jamie

No, I agree completely. I agree completely. So one of the things that I wanted to say is that we haven’t really done application security on this podcast. And I know that, like the, I don’t want to say fundamentals, because I’m worried that that means that people will take that to mean, all the basic stuff. But I mean, like, the actual, everything about application security, it fits regardless of the technology you’re using, right? If you’re a JavaScript dotnet if you’re going if you’re c++, assembler, whatever. So I feel like, even though this show is specifically about dotnet, although it’s called dotnet core, because they recently rebranded. You know, I feel like, hopefully what we’re going to talk about is relevant. And that yeah, this, this really is the first time that we’re covering app security. We did talk about keeping, like your build server safe because of you know, if you’re pulling in libraries and stuff, you don’t know what’s in that code. And in fact, there have been a few times node packages that have Bitcoin miners that just sit in mind was this building? So you know, that’s a separate issue. I think. We’ve talked about that with Neil, Neil Stannis episodes. And so if you’re listening to this, and you’re still interested, check that one out. But I’m not I’m not trying to drive people away from this conversation, we need to talk about this. Right. So I feel like this is going to be a leading question, right? We’re going to start off with a relatively easy one, right? We all know about the sdlc software development lifecycle. Where in that, does security come into it? Right? Where should I if I’m, I’m starting a new project, where in that loop, should I be involving decisions about app security?

Tanya

So I realise it’s a loaded question, because everyone doesn’t agree with me yet. But with the book, Alice and Bob, I’m hoping eventually everyone does. And so I believe that there should be at least one security activity in every phase of the system development lifecycle, so that that phase is secure. So let’s say you know, you’re going to build a web app. Well, I have some web app security requirements that I would like to add to your project, where if you’re doing design, I’d really love to, you know, meet with the team and threat models to like talk about, you know, if you’re gonna hack your app, how would you do it or a business person, like what keeps you up at night, and then I want to go and make sure those things can’t happen. Or even just standing with the tech team and whiteboarding out what their architecture looks like, and then saying, oh, here to here, is that encrypted, cool? When it gets there? Do you authenticate? And then authorise? Like, do you figure out like, oh, and they’re like, Oh, no, it’s our API. Like, are you sure? And so adding in those little things to just make sure everything goes well, right. And I see you’re doing this and this for security? You know, there’s three other options I can think of. You haven’t built it yet. Like, do you want to look at all three, and then figure out which one you like the best for sometimes when it’s cheaper, or it’s gonna take a lot less time or there’s less compromise, etc. And so then, during coding, there’s a lot of security you can do so yeah, basically, I feel that security should be there at the kickoff meeting. Ideally, for each project. Be like, Hi, I’m your security person. If you have questions, just come ask me. In each phase, I’m going to show up, be like, Hey, what’s up? I see you’re doing testing cool. I’ve already scheduled some stuff for you.

Jamie

I mean, that makes sense. That’s right. Because we have. Yeah, I mean, you said yourself, you started out, just doing development. I don’t want to just be loaded there. But yeah, started out doing development that you’ve transitioned over to. As there’s the whole security, like security, for application, cyber security info security is a huge thing, right? No one’s gonna know it all. In the same way that no one’s gonna know everything about development. Right. But I think I agree with you, you know, we have this thing, we’ll have this thing about the further away from a developer’s keyboard a bug is found, the more expensive it is to fix. Is that the same with security? I get up? Again, I feel like it’s a loaded question. Let’s just get these ones other way. Right?

Tanya

Yeah, so the earlier you find any type of bug, including security bugs, the cheaper it is. But the one thing about security bugs, that’s extra special compared to a regular bug is that so I mean, if your team finds it, after you’ve deployed the code, it’s going to be expensive to fix. But if the malicious actor signs the vulnerability before your team, it’s just off the charts. How much that can potentially cause sometimes when people say, Oh, you know, but adding that security layer, Tanya is gonna be really expensive. We’ll talk about Okay, so if there was a breach, what would that cost and is the risk of you know, spending $8,000 on adding like a laugh or whatever the thing is that I’m recommending, versus so if, if this is taken down for a day, I don’t know if you saw, but yesterday, a ship got stuck in a canal. Right. And I guess it was trying to turn around or something. I don’t know exactly what happened. But now it’s stuck. It’s a no ships can go back and forth. And that is a lack of availability. So when we talk about a security, we’re always like, confidentiality, integrity, and availability. And so like your app, Amazon, so that ship is down, every other ship is down. And sometimes when you take an app down, that means a lot more is down than you realise. Right? Like, first of all, all those devs are freaking out, I’m working on that. So they’re not working on their other projects, there’s a security incident where the security team can kiss goodbye, their next two weeks, all their projects are delayed. Now, all these other things are not getting done. Because we’re all worried about this emergency that is occurred. And you better believe it, those ships, lots of stuff is happening that we can’t see. Right? And it’s the same with any industries, you take away the availability, you need to measure that. So how bad would that be? Okay, so my suggestion to put this on cost this much, but the risk is that how likely is that to happen, etc. And then we talk about it. And then sometimes they find the money, and sometimes they don’t, or we decide on to kind of like, compromise halfway in between. And that is a lot of your job. Doing app sack is like compromising and finding a way where, you know, the devs can still do their jobs. The app still function, they’re still usable. But you are not like crying in bed all night being like, I’m gonna lose my job or we get breached, for sure. Because it’s scary. so bad. is we worry about that. That’s not being a lot of people outside of security might know. But there’s like a lot of stress involved. If there’s a very poor app that’s in prod, I worry about it. Like, please just, can I just get the money for the left this this quarter and not wait until next quarter? Because that’s like 90 more days of danger? Or like, I know, I’ve said laugh a lot. That’s like a band aid that you put on, instead of writing really good cup. Yeah.

Jamie

Yeah, I think there’s something in your book that you talk about a, like a responsibility sign off sheet. I forget the official risk signup

Tanya

sheet again,

Jamie

sorry. So I thought I was three quarters of the way there.

Tanya

You’re amazing.

Jamie

I completely go got it completely wrong, it’s fine. But I love this idea of saying, Hey, I have identified this problem. Here’s what I think it would cost to fix it. Here are like you were saying here is the cost the potential costs if a malicious person gets hold of it, or perhaps if you live in a state or a country where there are fines. You know, here in the UK, we’ve got the GDPR. Right. And in the EU as well, they can take a huge chunk of your profits for the whole year, or a million pound or multi million pound fine, just because we’ll just again, bodyguards. But just because your system has been hacked, and user data has been exfiltrated. So if you put that to someone and say, Look, I know it’s gonna cost $8,000 I love this idea that you have, here’s this document, you put your name to it, manager, but you accept this. Yeah,

Tanya

yeah, I actually, um, a few years ago with a client, I was explaining so I was on a project for something else. Like they want me to do some other thing and I said I need to explain the threat model of what you’re doing to you doing right now. And I’m like, the likelihood of a data breach happening as well. But your company will be over, because the data you’re collecting is so sensitive. And so I’m not in to like, for instance, with Cambridge Analytica, so this is not related to them whatsoever. But like when that data like that company’s gone, no one wants to. And Facebook’s. Finally, the normals understood how much Facebook was spying on them, the people who are not really interested in privacy and security. And so it damaged the reputation, it cost them a tonne of money and reputation and deleted accounts and all of that. And I remember telling the client, I’m like your business will be done, it will be over. It will it is catastrophic risk. And so I’m telling you not to store this in that third party place, and that you need to do it in your own system behind your own network, that the risk is too great. And there, because it was very sensitive data. And I’m like, What if this third party has an employee, and they have an ethical concern about what you’re doing? And so they actually ended up cancelling the entire project, and just like not doing the thing at all, because there was such catastrophic risk. And I remember one of them saying, like, do you think we don’t know that we’re not stupid, and then the other one saying, I didn’t know that. And then them telling me Two weeks later, we’ve cancelled it completely. We’re not going to gather that data. It turns out there there are ethical issues there. And, like, it’s not for me to tell them. You shouldn’t do that from an ethical standpoint. But I’m like, if your customers found out you did that, how would they feel? And they’re like, well, they won’t find out. I’m like, what, what. And I feel like, I feel like just a conversation with a security person to understand the different ways that risk could be affecting them, just the half an hour to an hour conversation, once in each project, could change the course of the project so dramatically, for the better, right like for the better for that company. And it’s not the security, people don’t want you to do this, or we don’t want you to do that. It’s that we don’t want our company to ever be in the news, for reasons other than doing a good job and selling a great product and whatever other positive things, right. I never want a company that I am doing work with to be in the news for data breach, or for you know, a gross violation of privacy, or whatever, right? It’s like, because that reflects on me as an individual. But also, you know, when people work in security is because that’s part of our value system. Usually, like there’s a small percentage of people that are just like, I want money. So I work in security, but a very large percentage, you will find people were like, it really matters to them on a personal value level to protect others. And so, yeah, anyway, I have a lot of fields on the topic,

Jamie

though, I totally understand. You know, I feel like if if developers, designers, project managers, whoever, if they spent more time thinking about how is this going to affect the user? Or even just ask them the question, do we really need this data? You know, a lot of people until things like GDPR. And is it? Is it CRISPR Sis, but they did that I know that California or Florida has their own. There’s lots of different rules around the world about what data you can collect. And I think that until these regulations came out, a lot of people were like, now we’ll take your phone number and your Social Security add your mother’s maiden name, we don’t need it. But we’ll take it well, I have all this data. And so yeah, like you said, it just takes a person to step up until you realise what this means.

Tanya

And think about who you could sell it to. Because you would be shocked at what they sell about us. Does the company DuckDuckGo recently, so they put in a request to Google I don’t know if you saw it to ask just exactly what do you collect on us when we use your product? When we search something in google.com? What do you collect? And they did I guess some sort of like legal request, and then Google gave it to them and it was it was it so you can you can look that up. If you want to feel afraid and know why I I always use DuckDuckGo and less DuckDuckGo has failed me which is very rare. And it’s usually only if I’m doing like very in depth research on a very niche niche niche thing. And then I’m like, Okay, I need to consult more search engines than just this one. But if I’m going to the hardware store, or you know, I’m trying to, you know, book a, I don’t know some sort of appointment, it’s just, I can trust DuckDuckGo with that. They’re not going to tell everyone did you know Tonya dyes her hair, it’s not really purple. Yeah, but Having having anyway, I feel like privacy is a thing that I wish that privacy and ethics is the thing that we could teach software developers alongside security. Because, yeah, I remember I say, live in Victoria Canada, which is, it’s a beautiful island off the west coast, just above Seattle. And I wanted to instal their parking app, and the privacy violations of things that they wanted. So I tweeted at them, and they’re like, Oh, it’s in line with our privacy statement. I’m like, so yes, you need to know my geographical location, because you want to see that I did park my car there. Okay, sure. that’s reasonable. And you wanna know the time okay. But if one had access to my photos, it wanted access to my contacts. And I was like, No, and they’re like, within can’t have our app. And there’s, they’re making it less than less easy to put cash into a metre. Right? They’re trying to make it you have to use the app? No, no, no. Actually, that reminds me, I should hassle them online about it some more.

Jamie

fighting the good fight, I like it. So there’s lots of things about, about privacy there. And I do think that because we develop as a kind of the the last line of defence, we should be able to the who are saying stand up and say, hey, look, I don’t think this is right. I don’t think we should be tapping into someone’s photographs or their video, because all we want to do is log that they have popped somewhere, or, you know, saying Do we really need to capture this information. But I guess that’s that’s something that we should be teaching our developers, then the current generation and the next generation, whatever Gen. I hate to use the word generation, because I’m worried that it becomes like an ageism term. But all the developers should at least be able to feel comfortable having these conversations and say, do we really need to do this? Is this really required?

Tanya

I also feel like, Oh, I’m sorry, I feel like the reason that they put all their permissions is because then everything just works. Does that make sense? And so if it just works, they’re like, Okay, well, I don’t want to turn anything off in case it will break it. It’s like, No, we really need to do least privilege at all time. So the least amount of permissions that you need to accomplish your job is how many you should have. And that applies to your apps. So maybe it would be nice if your app had all 20 permissions, and it would work really easily. But if you only really need two to get your job done, then that’s how many you should do because then you’re only endangering those two, right. And like, you’ve just reduced your amount of permissions by 90%. And when I was a dev, there’s like it works. That’s my job is to make it work. But as a security person, I now understand, it’s my job to ensure not only that it works, that it keeps working, that it works correctly, and that no one can mess with it. Right. And that if something’s a secret, if there’s a secret and all these other security factors, I want to make sure that no one can make it work in a way it’s not supposed to. And that’s not a lesson they’re really teaching in universities or boot camps, which is frustrating. And that’s why I wrote the book. Because you do not make money writing a book. So anyone that’s listening, you’re like, I’m gonna make lots of money. Unless you’re someone like Obama that’s super famous, or Oprah, like Oprah writes a book, it doesn’t matter. She could write anything she wanted to write, but I am not those people. And no one is going to just shell out $50 for a book, unless it’s actually really good. And you make very, very, very little money on textbooks. But I wanted it to exist, because I went to college in the late 90s. And there was nothing on security. And people tell me now that there’s still almost nothing or if there is it only has to do with access management, and maybe a little bit of network stuff. But there’s never in their software development classes, how to do the right thing. Like Oh, hello, world. So do you know the Hello World programme that they teach everyone everywhere. It literally teaches you how to ensure your app has crossed a script. So the first thing you do is how to output something to the screen. Perfect, great. But the second thing is always let’s get the person’s name from them. And we don’t tell them about the dangers of getting input and how you should make sure it’s what it’s supposed to be. And then we immediately reflected the screen without opening coding, or any sort of protections. And then it’s like Thank you, you just programmed reflected cross site scripting, and literally This is the first lesson we teach every single Dev and do we need to teach security the very first day, maybe not But there needs to be a second part of that. That explains. Okay. So there are things that aren’t safe on the internet. Right? And so how can we make this a more secure lesson? So hello, secure world, right? And it’s just um, yeah, Boot Camps all over the planet everywhere. They’re just teaching everyone how to make insecure software. They’re teaching them how to do it wrong, and makes me want to pull my hair out.

Jamie

I think I think that’s a big problem, though. Because it’s, you were saying there about, hey, we’ll get we’ll get all the permissions, right. It’s like the very first time that you ever put a content security policy on a web app. You put the content security policy on and nothing works. And you sit there I mean, I’m a follically challenged gentleman. So yeah, I sit there and pull what’s left of my hair out trying to get the content, the the website to work again. Because I’ve told it only only allow sort of the resources from these particular places. And then, you know, and then you end up with a content security policy that then has unsafe inline, and it’s like, well, what’s the point?

Tanya

Yeah, they started to star. They’re like, everything’s okay. No, everything’s actually not okay.

Jamie

Exactly. Yeah. There’s a reason that you’ve created that allow us, right.

Tanya

Yeah. So this podcast is the dotnet podcast. And you were talking about when we should start security for projects, like when we could start security for programmers in general is in frameworks, like the dotnet framework. They did this really cool thing. So the OAuth group creates this thing called the OWASP, top 10. And it’s vulnerabilities that pentesters just keep seeing over and over again, and they want to raise awareness. Well, what the dotnet framework makers did is they took one of them and just programmed, they just changed the framework. So it automatically eliminated one of them. Like, don’t worry, we got this. And they, and it’s, they created this thing called the anti c surf token. So C surf is a vulnerability where basically, we all log into things all the time, like, I don’t know about you, but like, I’ll want to shop online. Let’s say I’m gonna buy running shoes. So I’ll be super obsessive, and like, look at shoes for maybe like four days, and I’ll be logged into, you know, AliExpress, or Amazon or someplace like that. I just leave it open. Meanwhile, I’m like checking emails doing other things, right. And so if I clicked on a link in an email, and if it was vulnerable, to see, sir, it would potentially execute a command with my logged in account with my credentials and go do something. But dotnet automatically now passes this anti c surf token, so that users don’t have to worry about this. But programmers don’t have to worry about this. That’s the beauty that’s the furthest left, I can imagine is that the dev just doesn’t have to learn this anymore. Because I don’t know. Honestly, I wish that the O OS could kind of like meet with all the different framework makers and say, like, Can we just eliminate the top 10? Or can we eliminate like half of them? Could we set up some secure defaults with you? We do this Can we do that? Like, I know that a little bit of that happens. But gosh, it would be so beautiful to have every single thing possible written into the framework. So because devs have to learn so much already anything we could take off of their plate. And it’s just handled perfectly for them. And it’s automated, like the anti CSRF token in dotnet.

Jamie

Yep, I’ve I’ve had discussions with my friends, fellow devs, about this before where it’s been like, okay, so traditionally, in much a maybe three, four years ago, MongoDB, when you instal, it didn’t have any kind of security enabled on it, and anyone can poke at that database. But that’s because the default tutorial is let’s build an out. They didn’t call it this. But let’s build an insecure, MongoDB instance. I feel bad because I’m feel like I’m picking on MongoDB. But it is something that happened. And I’m like, well, can’t we just make the default tutorial, the one on one quickstart guide. Okay, so you could do this, but now you need to set a secure password. And now you need to set multifactor. And now you need to disable ports, like, do that as part of a quickstart for people because, like you were saying that devs have to learn so much that you may only get 10 minutes to start playing around with a new technology before you have to then oh, wow, I’ve got to just commit that into into production, right? Because there’s so many. I’m not saying that a lot of developers commit insecure code directly into production and know about it. But what I’m what I’m saying is that if we’ve got to three hours to get to grips with a new technology and then it has to be committed an asset Maybe they’re doing the full DevOps lifecycle, push it straight to, you know, doing the Netflix thing, push it straight to production. And don’t worry about it, because it’ll be fine. Like, but you’ve just introduced this vulnerability that is, it’s there by default, right? Can’t we just set like you were saying there, but the framework, developers, can we tell all of the technology developers look just just make it secure by default? Yes,

Tanya

yes, I actually would fight that fight with. So whenever I see documentation that’s like that. And I used, I used to work at Microsoft. So if I saw something, and they would say, set this to start out start, I would just descend on them. I’m like, Hey, no. And they’re like, well, we don’t expect people to copy this and put it into prod. And like, they will. That’s what devs do. That’s what I did. I would go on Stack Overflow, I would find the top thing I would paste into my code. And if it compiled and it worked, I was like, sweet next task. And whatever is voted at the top of Stack Overflow, you better believe it is the most insecure way to do anything, because they’ve removed every barrier. And, you know, the Microsoft docs, people would update things and like, actually, you know, do stuff, but on StackOverflow people are rather like, like one person can’t say, Oh, no, it’s not good. If it has 2000 up votes, right? It doesn’t matter if I’m like, Well, I’m a study expert. And I think this is bad, because blah, people are, yeah, on page 32, you’ll see Tanya’s comment. But meanwhile, everyone’s like, Oh, this was voted up 2000 times and copy and paste. Yeah, good. So the Stack Overflow, people actually made a security area. Because they saw that happening, and they wanted to help. And I thought that was really cool. So if you are a dev and you are looking at how to do something, you can look up, what is the most secure way to do blah, and it will take you probably, you know, minute and a half instead of 30 seconds. But your code quality will improve immediately. Yeah.

Jamie

I think that’s one of the other problems, right? So we’ve got so like I said earlier on security itself is a huge topic, you know, your app security, info, security, cyber security, which again, is a huge topic in itself, you’ve got all of these different branches, all of this stuff, the you need to cram into your head as, as well as the code, you’re writing the the maybe the architecture, maybe you using microservices, so you don’t have to remember so much. But there’s all this stuff that needs to go into your head. And I’m worried that because there’s so much right, you talked about sea surf. So that’s a user the CSRF therapy serve, cross site request forgery,

Tanya

site request forgery. Sorry, no,

Jamie

that’s fine. Others sanitising inputs. There’s x ss, the cross site scripting attacks, which hopefully, pretty much nullified by modern browsers. But who knows? No, no, no,

Tanya

it’s still there. Oh, definitely drives me I know, all the time all day long.

Jamie

Sorry. No, that’s fine. You’ve also got like SQL injection attacks, all of these things that you’ve done after like, I need to know all the security. Right? So is it worth trying to do that? by how hyperbole of no all the security? Or is it a case of, Okay, I know how to do this one thing. And I’m going to look for all the places where that one thing exists, and maybe suggest some changes? What would you What would you recommend for devs? Who are looking at projects, legacy or brand new projects and going I think, you know, should they look for all the security issues, I’ll just look for the one and report that.

Tanya

So I actually teach secure coding, because you know, I run a security school. And what I usually tell clients is listen, if you can send all the devs on secure coding training, but then all of the ones that actually review pull requests, if you can get them to so I call it the 17 commandments of like, if you want to write code that’s good enough to put on the internet, you must do at least these 17 things. And so if you could just get them to do the top three, just look, every time for those three, you will eliminate 80 to 90% of every type of bug just off the top. And they are input validation. So when I say input validation, I mean checking to see if the thing you’re receiving is what you think it should be. And then it’s correct. I do not mean removing bad characters. And that sanitization. And sometimes in super special cases, you want to do that, but a lot of devs are like, yeah, I validated the input in the user field. And like, did you validate the stuff in the URL parameters? Well, no. Did you validate the stuff that came out of the database? Why would I do that? Did you validate the stuff from the API, but I have no It Yeah, every single input, assume anything. And I, so I’m going to be very silly for a minute, but I joke like validate everything, even stuff from your mom, because my mom wouldn’t send me a virus and I opened it because she’s my mom. And she’s like a super intelligent person, and like, her computer got infected with malware, right. And if she didn’t send it to me, but the point is, is like, apparently, if I can’t even press my mom, that means you can’t trust the data from your database from an API from here from there. And so if every, every single input is validated, and then second, every output to the screen, you encode it, if it’s from the database, unless it’s a label that you have programmed into your actual app, every single thing, if it’s from anywhere output encoded, just in case, even if it’s from your database. And then the third thing is, specifically for SQL or other database level injection is always use a parameterised query and never do inline SQL. So inline SQL is where you’re like, Oh, so what is your name? Oh, it’s George. Great. So select star from table where name equals, and then that variable that is in line SQL, instead, you should call a query. So in SQL stored procedures, but you know, it’s prepared statements in PHP, etc. And so instead you call the get, you know, get client data, whatever. And then it’s like, oh, what are my parameters? Your parameter for username is George, okay, great. And that takes away all the power from the thing when you output in code, it takes away all the power. So if someone has put any code in there, it’s like, I’m sorry, this is data, and I’m going to treat it like data, even if it looks just like code. And if everyone everywhere that reviewed code, caught all those three things, even if they caught it, 80% of the time, it would be magical, like so many devs, they’ll tell me, like when I was doing pen testing and more full time appsec like, okay, I fixed it great. Me, I’m in them what I fixed it. I’m like, no, no. And so eventually, it’s like, Can I just come to your desk? Can we code together? Like, I don’t mean to be a jerk. But can I? Can I drive like, let me. So then I started doing lunch and learns. And then that’s how I started teaching. Because I would be like, I don’t mean to be weird, but can I drive? Like, can I type? And then I would just be like, you do this and you create a regular expression and blah, blah, you know. And it turns out that that is, when someone learns it, they can’t stop seeing it. So like, there’s this Junior app set person I’m working with. And, you know, we’ll review code. I’m like, Oh, it’s there. Oh, it’s there. Oh, it’s there, because you can’t not see it. And we’ll even review code and languages I’m not super familiar with like PHP. I’m like, Oh, yeah, there. Oh, yeah. There. And he’s like, I’m like, once you get used to seeing it, you’ll never be able to not see it for the rest of your career. You’ll be like, Oh, that’s, that’s an input that’s not validated.

Now, I have to report it both.

Jamie

Yeah. Like I said at the start, right, is the the fundamentals as long as I’m, as long as we don’t mean basic stuff, but the fundamentals that they the actual security things you need to be doing. can be you can they are platform framework, and language agnostic, right. Like you were saying, though, I’ve seen a there’s a SQL injection attack in PHP, there’s a

Tanya

no SQL injection attack.

Jamie

Yeah. Yeah, exactly. Right, is

Tanya

also like an operating system level attack, or LDAP, or whatever. Like, if it accepts commands, someone’s gonna try to inject some

people are the worst.

Jamie

I mean, only as a as a real. So I think I’ve given this example on the podcast as well. But I’d like to tell you this example. Anyway. There was one time when I ordered a, a pizza to be delivered from a large pizza, multinational conglomeration, who used to sponsor a lot of sporting events. That’s probably not vague enough, but that doesn’t matter. And the delivery instructions box was like, you could have 50 characters, and that’s not enough characters to give the information to the delivery driver to find my house. Because over here in the UK, sometimes houses are difficult to find. And I just had right click inspect Oh, at we got jQuery on the page, okay, selector dot txt equals, and I just typed it all in. And it skipped over the validation because the validation was happening on the field, not in JavaScript and not on the server. Have a knot in the database. And I know that because when he got delivered to me, they put a little sticker on the box. And the sticker was like three times longer than the books. Because I just found that lorem ipsum as well just to see what would happen. And it’s, it’s kind of ridiculous. And that’s just me messing around. Because I wanted to order a pizza and I needed extra space, I wasn’t intentionally doing anything malicious, someone malicious comes along, they may put in, they may attempt to do a some kind of injection attack or whatever, try to put some code into the database that is next right out, you take over that machine and that company were vulnerable to that attack. And I found out accidentally, what if someone came along and was malicious about it, right?

Tanya

A lot of the reason why, like from a security perspective, people really want people to use Content Security Policy header, or all of those things. And why they have fields short is because if you are vulnerable to cross site scripting, those little fields, like the 50 character limit means that you actually can’t write a really kick ass attack. So what malicious actors usually do if they find you’re vulnerable to cross site scripting, the first thing they do is call out to a malicious site so that they can put pages and pages of JavaScript in. So if they had found your vulnerability that you found they could put a giant script in there, right and do all sorts of things, assuming it was also vulnerable to cross site scripting. And to be quite frank, around two thirds of apps are if you really, really look at them. And so that’s why. So like, if you can only make an attack, that’s 50 characters long, it’s going to be like a message box or something, or like stealing a cookie or something, it’s not going to be the same as the power someone could have pages of JavaScript. And so yeah, combined that vulnerability you found with some excesses. Oh, yeah. Game over?

Jamie

Absolutely. It’s, like you say that once you start seeing it, once you’ve seen it once you do indeed see it elsewhere. And I mean, I could have gotten around that by there was some JavaScript on the Okay, so there was another website, that I, I used to use that it didn’t have very good validation on the password field, right. So you can use any number of characters you want, and what the rules on the page were really good. It was like up to 100 characters and special characters and whatever you wanted, right? And that’s great, because then I could just go Password Manager, fill in that field, generate one I don’t even need to know. But every time we did, it would fail. And I was like, well, I it’s telling me what I’m putting in is valid. So I jumped into the JavaScript, and then this submit method, they captured that form Submit. And they were doing like lots of regex is in JavaScript to validate before sending. Like, that’s great, because I can just put a breakpoint in there, change that to true and it passes change that to true and it passes genes that determine it passes. Or I can just short circuit that and just send the data is ridiculous. And I managed to send a zero length password, and it crashed their website, because the database accepted it. And it was they tried to hash a string that was empty, and presumably divided by zero error, and took the website down. Like I’m not doing anything malicious. I just want to store my password.

Tanya

Yeah, there’s actually, so there’s software called a web proxy. And that’s exactly what it does is it just lets you circumvent all of the JavaScript, and you just get to talk directly to the web app, you’re like, Oh, I would like my password to be 35,000 characters. Thanks. And unless there’s validation, also, on the server side, which PS is where you should put that validation is, like, it’s game over. It’s so true.

Jamie

It really is. It really is. So let’s aside from we hack bubble, and the ways to contact you, and to learn directly from you in how you and how your team and stuff like that. What are some of the places that you like maybe web resources, maybe books a week talk about the book that the listeners should look to, to get to get started in this journey, right, because I feel like everyone should know this stuff.

Tanya

So I am a big fan of OAuth, the open web application security project. I also run an informal mentoring programme every Monday on Twitter. And if you use the hashtag, cyber mentoring Monday, every Monday, on them on Twitter, I will retweet you basically and try to help you find a professional mentor that’s been pretty powerful and kind of awesome. And there’s also so more self promotion, you know, every month I’m going to be doing an open discussion about the chapters with Alice and Bob with a bunch of guns. And we’re going to go through so like this month, we went through all the fundamentals of security next month, we’re going to your security requirements for web apps, and all of those discussions and the recordings are free. And you can get all of it Alice and Bob, learn calm. And lastly, I would join the security community. So that can be whether it be through like, we have purple as a community, but there’s a bunch of online community. So if you’re a woman, there’s Whoa, sack women of security, or we are hackers. There’s, oh, there’s Katie Paxton fear, insider PhD, she has a community for bug hunters. And what’s really good there. Like there’s just all sorts of there’s the many hats club, that’s a really good one. There’s women cyber jitsu, there’s there’s just like the list goes on and on of so many different, really great groups where you can meet other people and kind of learn stuff together. Okay, so one last one is the Oh, wasp dev slop show. So I started that with my friend, Nicole Becker, and my friend, Nancy curry, she leads it up now. She’s amazing. And basically, once or twice a month, they have a bunch of guests, and they live stream and do technical stuff together. And they’ve been teaching for free with me on the peripheral more recently, because of my startup. And for years and years now, it’s been like four years or something. And so yeah, there’s lots and lots of ways for you to learn. But having one or more people go along the path with you makes it so much easier. and way more fun.

Jamie

Excellent. What I’ll do is I’ll get some links, put those in the show notes. So if you are listening through, just click through and check that. So what I’d like to say to you real quick, because I know you got to sort of rush off is Thank you ever so much again for being on the show. And there were a lot of topics that we didn’t get to talk about just because I had this idea, the great idea of hundreds of topics. And that kind of happens with me, I end up sort of waffling on and going on in different tangents. So, but thank you ever so much for helping out. And I feel like everyone should at least go get the book. Because it is a fantastic book. I have to say I think I got through it in about a in one session. I was just like, yep, gotta keep reading got to get ready. So

Tanya

thank you. Thank you so much. Thanks for having me. I’m actually planning. So my next course is secure coding, but then we’re going to be making quote unquote language packs where so one is like the general agnostic one, but then the next one. We’re going to do like a deep dive into each language. I would love to come back on when we do dotnet to give like some dotnet secure coding secrets.

Jamie

Sure, absolutely. The invitation is always there absolutely.

Tanya

Thank you.

The above is a machine transcription, as such there may be subtle errors. If you would like to help to fix this transcription, please see this GitHub repository

Wrapping Up

That was my interview with Tanya Janca about building application security into your projects and when to do it. Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at dotnetcore.show, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice - head over to dotnetcore.show/subscribe for ways to do that - and to come back next time for more .NET Core goodness.

I will see you again real soon. See you later folks.

Follow the show

You can find the show on any of these places