S07E12 - Grokking Application Security: Malcolm McDonald on Securing Your Apps

Sponsors

Support for this episode of The Modern .NET Show comes from the following sponsors. Please take a moment to learn more about their products and services:

• RJJ Software’s Software Development Services, whether your company is looking to elevate its UK operations or reshape its US strategy, we can provide tailored solutions that exceed expectations.

Please also see the full sponsor message(s) in the episode transcription for more details of their products and services, and offers exclusive to listeners of The Modern .NET Show.

Thank you to the sponsors for supporting the show.

Embedded Player

The Modern .NET Show

S07E12 - Grokking Application Security: Malcolm McDonald on Securing Your Apps

Supporting The Show

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

Episode Summary

Malcolm McDonald, author of the new book “Grokking Web Application Security”, recently joined us to discuss the importance of securing web applications. Malcolm’s book aims to provide readers with a comprehensive understanding of web application security, and he shared some valuable insights on how to secure apps from various tech stacks.

One of the key takeaways from the interview is that securing an application is not dependent on its programming language or framework. Rather, it focuses on understanding HTTP requests and the vulnerabilities that can be exploited by hackers. Malcolm emphasized that most code serves as a machine for understanding HTTP requests, making vulnerabilities universal across different technologies.

Malcolm also discussed the concept of “secure defaults” - setting up an application with security features enabled from the outset to prevent common vulnerabilities. He stressed the importance of being proactive in securing an app, rather than relying on patching after vulnerabilities have been identified.

The interview highlighted some key resources for readers looking to learn more about web application security. Malcolm recommended checking out his book “Grokking Web Application Security” and its accompanying website, hacksplaining.com, which provides more interactive content focused on specific vulnerabilities.

The conversation was informative and insightful, providing valuable lessons for anyone interested in securing their web applications. With secure defaults and proactive security measures being key to preventing common vulnerabilities, readers will find Malcolm’s book a comprehensive resource for learning about web application security.

Episode Transcription

This should be a mantra for anyone working on web applications or web APIs: you should validate any input of the application as much as possible. When you conceptualize it, all the malicious input into your application comes across in an HTTP request at some point. It’s either in the URL or in the body. That’s generally speaking, unless you have a supply chain attack, that’s generally the vector by which your application will be attacked. Before you even start to kind of think about specific vulnerabilities, if you narrow down what is permissible input right out of the gate, then you kind of close the door on so many different vulnerabilities without even thinking about it.

Welcome friends to The Modern .NET Show; the premier .NET podcast, focusing entirely on the knowledge, tools, and frameworks that all .NET developers should have in their toolbox. We are the go-to podcast for .NET developers worldwide, and I am your host: Jamie “GaProgMan” Taylor.

In this episode, Malcolm McDonald joined us to talk about the importance of Application Security, knowing the basics of secure coding, and backing that all up with both “secure by default” designs, and subscribing to CVE notifications.

So what you find in your career is that if you set down kind of sensible default behaviour in your codebase earlier on, then everyone will follow that. You establish, kind of, best practices. It might take a little bit longer, but if you say, “this is the way we do this over here,” then even yourself when you, kind of, come back to, will kind of, reproduce that path. So the initial, kind of, like first few check-ins to your source control are key to, like, establishing best practice

One note before we begin: some of Malcolm’s audio is a little rough. Mark, our superstar editor, has done what he can, but there are parts that might be a little unclear. If you have trouble with the audio, please remember that there is a full transcription linked in the accompanying show notes.

Anyway, without further ado, let’s sit back, open up a terminal, type in dotnet new podcast and we’ll dive into the core of Modern .NET.

Jamie : [0:00] Hey, Malcolm, thank you for being on the show. I really appreciate it. I appreciate whenever anyone wants to be on the show and hooks up with me, and that’s probably not the right way to say it, but gets in touch with me and says, “let’s do this, let’s talk about some stuff. " So I really appreciate it. So thank you for spending the time with us.

Malcolm : [0:19] Thank you, Jamie. It’s nice to be on.

Jamie : [0:23] Excellent, excellent. Well, it’s nice to have you on.

Jamie : [0:25] So I wonder, I ask all of my guests this: I wonder, you know, there’ll be people listening in going, “who’s this Malcolm chap?” Would you mind perhaps giving us a sort of brief introduction, kind of like an elevator pitch, just so that everybody knows what, you know, the kind of stuff that you do, the kind of work that you do. We’re going to talk about your book as well, and hacksplaining and things like that. But I wonder, people are listening to this going, “who’s this guy?” So who’s this guy?

Malcolm : [0:56] Okay, absolutely. I’ll read straight off my LinkedIn profile, if it helps. So I’m Malcolm McDonald. I’m a veteran developer of about 20 years who specializes in web security. Most of my career has been working at banks or fintechs and most recently PayPal.

Malcolm : [1:20] But I’m currently the CEO and creator of a website called Hacksplaining. Which is a web security training application and as you mentioned I have a new book coming out called “Grokking Web Application Security” on Manning Publications. So the bulk of my career has basically been in web application security, but I’m from a development background so that’s the long and short of it.

Malcolm : [1:53] I should also mention given the nature of the podcast: I’m not a C# expert. I’ve had the pleasure of working with the language of various points in my career, but wouldn’t, kind of, class myself as an expert at all. So uh bare in mind, I’m not going to be recommending any specific libraries.

Jamie : [2:14] Okay. So what we’ll do is we’ll cancel the um the the spotlight to shine in your eyes, and I’ll tell the bad cop to go away. That’s what we’ll do.

Malcolm : [2:23] Okay. Okay. Yeah, I find in an audio format, it’s hard to talk about code except in that. It’s when you learn to, you’re actually mispronouncing function method names and class names for a long time. It’s when you actually bring them up in a meeting. So I’ll try and avoid that.

Jamie : [2:51] Yeah, sure, I understand that. Well, I mean, so one of the reasons for having you on the show was I figured: you know, a lot of .NET devs do web apps. And you’re going to be talking today a little bit about your book, but also some of the things to do with hacks planning, and some of the things that I think a lot of web app developers sometimes get… not necessarily wrong, but not great when they’re’re working on web apps. And so when we planned this out I was hoping that we could talk like technology agnostic; that way, whatever we talk about is applicable to every kind of development, right?

Malcolm : [3:29] That makes sense.

Jamie : [3:33] Excellent. Okay, so we’ve talked about the fact that you’ve got this book coming out. So let’s talk about that first, right. So, I mean, I know the title of the book do you want me to say the title of the book or are you happy just introducing the book to everybody?

Malcolm : [3:47] Yeah. Yeah why not

Jamie : [3:49] Okay, cool. Yeah So like I know that the book is called, like you said earlier on, “Grokking Web Application Security.” So, I guess the first question, and it’s probably in the title of the book, but who is the book aimed at? Like, are you aiming this at juniors, at architects, at anyone in between? Like, can I get this for a friend of mine who’s just started their journey in software development they’ve qualified, they’ve got their first job, and they want to learn how to up their skills. Like, what’s the pitch here for the book?

Malcolm : [4:28] So yeah, you touched on a very good point there. I wanted to write a book that had everything a junior developer needed to know about web security in one 300-page book. In my past career, I’ve been in various situations where I’ve led development teams or mentored junior developers and things like that. And I mean, given that almost every application you write nowadays on the internet, security is like a big part of what you need to know before you start releasing software. But there’s so much material out there that it can be very intimidating just to sort of try and browse the internet, go through the OWASP or the MSDN sites. And try and kind of make sense of everything.

Malcolm : [5:29] So this book is essentially my attempt to kind of whittle everything down to just the essentials and not leave anything out. So it covers every aspect of web application security. Where there’s more to learn, it kind of recommends further reading. But it’s basically the book I would want to put on a new member of my team’s desk and say, “read this and come back with questions.” Because we all know the importance of security, but it can just be very intimidating to try and get started.

Malcolm : [6:11] So this is my attempt to map the territory and say, “these are all the things you should know.” And at the same time as I was kind of writing it I was filling in kind of little gaps in my own knowledge, so it works very well for a more senior developer just to kind of brush up their knowledge; because I mean the software changes quickly, and there’s things that are threats now that weren’t a couple years ago. So it’s a good… nobody wants to go to their manager and say, “hey, I feel like I don’t know enough about this stuff.”

Malcolm : [6:52] So this is like the cheat book to say, “hey, just read this stuff and you will have a better sense of what’s out there, and what you should be worried about.”

Jamie : [7:05] Sure. So, of the things that I often say to people that I work with, juniors or apprentices; I often take on an apprentice every year and just sit with them for 13 to 14 weeks of, you know, eight hours a day of, “let’s build something real together.” And one of the things that I say to them is, “get a real grasp on the fundamentals,” because it doesn’t really matter to maybe 60 percent 70 percent of the extent, doesn’t matter which language, and technology, and frameworks you’re going to be working with; the fundamentals are all the same, right? So like I could quite easily write an insecure web app using .NET, in the same way that I could write an insecure web app using go or rust or javascript or it It doesn’t matter what technology, right? The fundamentals are all the same, right?

Malcolm : [8:03] Yeah, it’s an interesting point. What I found as I became more advanced in my career is that when you learn, say, your second programming language, you actually grasp your first language better. You basically realize what’s specific to a language in what’s just a general kind of technique across the board. But yeah, you kind of rush up against the same concepts again and again, so they’re fairly applicable generally. And in most people’s careers, we’d cover at least a couple of languages, even if you kind of have to reluctantly dip your toe in JavaScript, for instance, or whatever else.

Malcolm : [8:54] I’m not bashing JavaScript, I do write Node most of the time nowadays, but it was quite a change of pace when I started swimming in those waters.

Jamie : [9:06] Yeah, definitely. I found, because I’ve done quite a bit of work with React, and the thing that I found the hardest with React was not changing paradigms, was not thinking about, “this is a front-end framework,” was not none of that. Not a JSX, none of that. The thing that I found the hardest was the lack of a debugger, that was the hardest part.

Malcolm : [9:29] Oh. I mean Microsoft has like Typescript and things like that forReact now. So it’s, I don’t know, it’s… [in] the tech world, they reinvent everything every five years so. Like JavaScript’s now getting back to where all the other languages were. So the debugger is still a little unreliable, but they’re getting better.

Jamie : [9:53] Well, yeah. Yeah, it will get there. And the work that has been put into JavaScript over the last 25 years is fantastic. So it really is coming along. It’s brilliant. These days, it’s a brilliant language. Node is fantastic, and Deno… if you’ve never used it, Deno is really, really good. It’s by the same chap who created Node but I believe he describes it as, “what I would have made if I knew more about Javascript before I made node.”

Malcolm : [10:31] That’s interesting. We so rarely get a chance a second chance to kind of fix our mistakes. I mean, as you kind of touched on: most of, we’re all generally working programmers. So like the code that goes out the door is the finished product. And we, yeah, it’d be nice to have that luxury.

Jamie : [10:55] That’s true. That’s true. So we’ve got Grokking Web Application Security. And I know that you said earlier on, there’s hacksplaining.com which is a website that you used to give out, is it correct that you give out training on there and like extra, sort of, the next level up I suppose from the book. Is that right?

Malcolm : [11:15] Yeah so it’s a precursor to the book. It was the reason the publisher approached me. Hacksplaining is… it’s a completely free website, [it] includes 35 uh interactive exercises that would demonstrate various vulnerabilities.

Malcolm : [11:38] And it’s aimed to be kind of more interactive than the, kind of, most sort of training. So to the extent it’s possible on a website you are able to hack various applications, put yourselves in the shoes of an attacker; exploit the vulnerability in a kind of a dummy web application, and then go on to learn about, “look at the code, see why it’s vulnerable, and what could have been done to address it. " So it’s very kind of bite-sized kind of lessons. It’s themed around these, right? Each vulnerability takes about half an hour to go through. And it’s aimed to, like, if you have 30 minutes of your day, you want to learn about, say, cross-site scripting or directory traversal, or various kind of vulnerabilities, you can just dive in there. And it became very popular because I shared on Reddit, and everyone was like, “okay/ This is way more explanatory than most material.” And that’s the target.

Malcolm : [12:50] I’ve had to run various kind of training sessions at, kind of, banks, and fintechs, and security training tends to be like pointing at PowerPoint slides. It can be so tedious. So this is an effort to make it more interactive and just remove all the unnecessary elements. So you see precisely how the vulnerability operates, what the risks are, and then you see code that addresses those vulnerabilities.

Jamie : [13:26] Right, right. Interesting because… so my experience of attending internal training for security best practices is definitely, “point at the powerpoint.” But then it’s maybe type of folks that I’ve worked with and alongside of in my career, but most of the time it’s, “we’re gonna give you,” what is it? “Death by powerpoint for 45 minutes. Then we’ll tick a box and have an auditor sign to say that we’ve done the death by powerpoint so therefore we’ll make secure code from now on” Right?

Malcolm : [14:04] Yeah. No I mean a lot of institutions they know about the importance of web application security but.. and they’re obliged to do kind of formal training. But generally speaking we all have a good knowledge, may be patchy in parts. So it’s one-size-fits-all really kind of worth doing. As you say, you just get very bored sitting in a meeting room or on Zoom or whatever. So this training is arranged around, “OK, I know where the gaps of my knowledge are. I want to learn about cross-site script inclusion or kind of more obscure threats. And concentrate on that.” It’s kind of self-guided.

Malcolm : [14:55] But yeah, as I said, I managed to get on the front page of Reddit with it, which means I’ll have traffic on and off for years. Also, it was horrendous on my server cost at the time. But I learned about what the Reddit hug of death is. So there you go. I can put scaling web applications on my resume.

Jamie : [15:20] Yeah, you definitely should. You definitely should. And, you know, all of us know that the easy way to do that is just put it in front of Cloudflare, right? That’s not the easy way to do it at all. I’m just being silly, everyone.

Malcolm : [15:35] Thankfully it’s largely static content nowadays, so I’m like I can use a CDN. But yeah there’s a whole separate podcast to talk about the challenge of scaling web applications so.

Jamie : [15:50] Definitely, definitely.

Jamie : [15:50] Okay, so with the description of the book, and the description of the website sort of taken care of, What I would love to do is to sort of pick your brains about some of the things that–without giving away the secret sauce of of the book, or without giving away, “hey don’t bother going to the website,” please do go to the website folks–but, like, if I was wanting to pick up, like, the the maybe top three things to do with web application security and I was lucky enough to sit with you, say for instance over lunch, and say, “right where do I need to focus?” Because you know, from my perspective having gone through the process of learning and still learning. It’s a lifelong journey.

Jamie : [16:42] Going through that process and trying to figure out where I should be spending my time to learn these things, where would you say folks should start, right? Because like security itself is a massive thing, and then application security is slightly less massive but still equally massive That doesn’t make sense, but hopefully everyone knows what I mean then: When you niche down to web application security, before you niche down by framework and technology, that’s still a pretty big subject. So where am I starting? What am I doing?

Jamie : [17:17] I mean, the answer to that question really depends on, A) what you’re working on, and B) your degree of experience, I guess. I mean, I do agree with this. It’s kind of sad. I think about these things late and night, what are the top three things to recommend to a general developer starting out or looking for advice? Yeah there’s there are kind of a bunch of kind of common themes in the book which do kind of crop up again and again. One is, and this kind of like, drills down by specificity immediately, but you should know how to be secure in the framework or library or language you’re using.

Malcolm : [18:15] So nowadays, there is actually generally good documentation for security on each of the kind of major frameworks. I think the best example of this is the, this is a bit not really relevant to your listeners, but say the Ruby on Rails guide to security is front to back, covers everything. It covers everything that can happen on a web application and how the framework kind of protects against that. So that’s the kind of thing you should be reading. It’s like if Google is working nowadays, it would be like Google, your language, your framework and security. And if there’s any kind of guide by the author of the framework or the team building it they will have answered a lot of your questions. In many scenarios you may find yourself wanting to know more about the threat itself, rather than the kind of protections that [are] put in. So that that’s where you kind of you branch out and do more reading.

Malcolm : [19:22] But yeah, find some dedicated documentation about the framework you’re using related to security, and try and just kind of imbibe that very directly. Yeah, so I mean that’s so that’s that’s point one. I mean that can that can work for modern frameworks, you might find, many of us and most of our career working on legacy code bases or whatever. So that approach doesn’t necessarily work.

Malcolm : [19:57] So the next piece of advice would be use the tools you’re given. So try not to reinvent the wheel. This is kind of the largest source of security mistakes is when we build our own authentication; we try and do session management ourselves, or we do anything around encryption. When it’s hand-rolled encryption, it’s just a minefield of things that can go wrong. I mean, of course, there are developers out there who know this stuff, but I certainly am not smart enough to build this stuff from scratch.

Malcolm : [20:35] So just be very wary, if you seem to be replicating things which may be built elsewhere, just use what’s off the shelf. Not only will it save you time, but it will also… Um it will kind of avoid you kind of stepping into the traps that the developers already kind of kind of avoided in the first place

Jamie : [21:03] Oh sure, yeah. If I can just butt in there just for a second there: there’s an argument for building it yourself if you really, desperately, want to know how it works but.

Malcolm : [21:19] Oh yeah you know.

Jamie : [21:21] But, like wasn’t it… wasn’t there a problem… is it heart bleed? They probably know that all the vulnerabilities have such horror horrid names. But there was a there was a vulnerability in OpenSSH. Like the folks who write this have, you know, Ph.Ds in cryptography and they got something wrong, right? And so I’m not speaking for you at all, Malcolm, but I don’t have a Ph.D in cryptography, and I don’t have several years of experience doing cryptographical stuff. So when it comes around to writing cryptography and authentication, and stuff like that, I reach for a library, right?

Malcolm : [22:02] Yeah, yeah. And you should do, I mean you’re right. Building yourself is a great learning exercise, and I do recommend that. But generally, you don’t want that in production code. That should be like, “okay, I’m going to build a web scraper,” or, “I’m going to build a little mini database.” Once you get really deep in the material, you get to experience why these things are difficult, and you appreciate what the existing libraries have done. But yeah, there’s the things you should do in your day-to-day job, the things you should do on the side. And generally, just using the material supplied is the safer option.

Jamie : [22:57] Most definitely, yeah, I agree.

Malcolm : [23:01] On the flip side, is that when these random methods are discovered in established libraries, you need to become aware of them very quickly and patch them. I’ve worked on a banking software where it’s secure because it’s so obscurely built that nobody would take the time to hack it, but I don’t think that’s generally recommended.

Jamie : [23:26] Yeah, security by obscurity is never a good practice, in my opinion.

Malcolm : [23:31] No, no.

Malcolm : [23:34] Yeah, and then the third theme that comes out in the book, and this should be a mantra for anyone working on web applications or web APIs, is you should validate any input of the application as much as possible. When you conceptualize it, all the malicious input into your application comes across in an HTTP request at some point. It’s either in the URL or in the body. That’s generally speaking, unless you have a supply chain attack, that’s generally the vector by which your application will be attacked. Before you even start to kind of think about specific vulnerabilities, if you narrow down what is permissible input right out of the gate, then you kind of close the door on so many different vulnerabilities without even thinking about it.

Malcolm : [24:36] So any piece of code which takes an HTTP request, or data, or data from a request should be kind of restricting the most minimal range of inflatable inputs. And that plays a bit on so many different attacks. There’s essentially three approaches to that. One is, the happiest one is, you just have an allowlist of permissible values. So you know what the enumerated values are in a request parameter or in the body. You reject anything else. And that will make your HTTP endpoint super secure. Obviously, it doesn’t work for things like email addresses. You’re not going to know what the universe of possible email address is.

Malcolm : [25:32] So you can also do blocklisting, so removing anything which looks malicious, or the old-fashioned pattern matching. So it’s either a regular expression or just removing any illegal characters from a string before you kind of pass in that information downstream.

Malcolm : [25:58] And yeah, yeah, that’s really kind of the one thing. If you can kind of think through all the points at which your application takes HTTP input and processes it, then that’s basically kind of the gates of the castle, and that’s where you want to be securing things first.

Jamie : [26:20] Yeah, no, I haven’t, I don’t think I’ve explicitly been as, I don’t want to say explicit again, because that feels like it’s a redundant word, but I’ll use it for now. I haven’t been as explicit with my apps when following this particular rule, but I can definitely say that you need to be validating… assume that the user is not good, right? Assume that they are a bad actor; validate as much as you can and I often give um an example of a story it’s a real thing that I… that happened to me, or that I did a number of years ago

Jamie : [27:01] A large, shall we say, fast food delivery service… I was on their website, and I was getting some fast food delivered, and they had a box that was a user input box that was, you know, “please help us to find your house by giving us some details.” Now, you know, from your accent Malcolm I could tell you were from the UK at some point. Those who aren’t in the UK, some of our houses tend to be really difficult to find. And so I was trying to type out, you know, vague directions from where my address looked like it appeared on Google Maps to where it actually was, and I hit a character limit of 20 characters. And I’m like, “well this is just silly. I can’t, there’s no way… You can’t say anything useful in 20 characters.” So I did the, you know, I’m telling you all this so that you know this, and so that you don’t go and do this. The particular website that I was using has been patched against this, because I reached out to them after I broke their server with what I’m about to tell you.

Jamie : [28:03] I did the old right click, inspect and there wasn’t a max length property. But what I noticed was there was some javascript running on the website. On the key up it would check the length of that box and if it was greater than 20 it would just ignore whatever you’re typing. So I did what any any developer would do, and just stuck a breakpoint there and told it, “no. It’s fine, just let all my key presses through. It’s fine.” I typed out what I needed to type out, and then I copied four paragraphs of lorum ipsum, and hit POST… hit send. I never received that order because I broke the website, because they were doing front-end validation only, right.

Malcolm : [28:44] Yeah, it used to be my favourite technique when we’re kind of validating internal apps: is finding a text box and trying to cut and paste the entire text of Moby Dick into an input somewhere and see what happens. But yeah, the lesson there as well is: that kind of validation for kind of string length should happen on the server side. So you shouldn’t have been able to kind of break the server in that fashion.

Malcolm : [29:12] And this is kind of one of the things brought up in the book actually is: that there’s a kind of huge number of kind of client-side validations you can do usefully for… to guide users uh up front, before you submit the web request, for everything. The essential validation for security should be on the server side. So anytime your HTTP request handler is taking input it’s like, “what could go wrong? Is it over long? Does it contain unusual characters? Is it malformed?” that’s the kind of the gateway into kind of most applications when you’re trying to hack them.

Jamie : [29:52] Yeah absolutely. And I love the the phrase that you used there when you said, “you can use all sorts of client-side validation to guide the user,” rather than to stop them from sending something malicious. You’re just guiding them in the direction of, “this is the kind of data that we want,” right. Like you said, you don’t want to be relying on that client-side validation because I just proved I can right click, inspect, and stop that validation from happening, right.

Malcolm : [30:23] Yeah. Now I enjoy, nowadays, when you bring up the chrome debugger it’s like, it gives you a warning saying, “do not cut and paste any code here from suspicious strangers,” for hacking Facebook or wherever else.

Malcolm : [30:38] The other thing I hate is it’s like, if you perform the validations as you’re typing them in, and this is like a pet peeve of mine, but you’re midway typing in an email address and it tells you, “this is not a valid email address.” It’s like, “I haven’t finished typing this field. Can you please have a little bit of patience?” I mean, there’s a whole lot of podcasts about UI design, but I mean, it’s the big subject.

Jamie : [31:09] Yeah, I often liken that to, you know, if you’re ever having to sign up for something, say you go to the you know you go to the dentist, and they ask you to sign in and say, “well, you know, what’s your name? We’ll sign you in.” And you say, “well, my name’s Jamie.” And you get to the end of “Jamie” and they go, “and your surname! hurry up! You haven’t said a full name yet!” That’s What that is, right.

Malcolm : [31:27] Yeah, yeah. I mean it’s common on bigger websites. It also seems like: does nobody who writes this code ever actually use this website? Do not get frustrated with the things yourself? This is your first time doing this? That’s an interesting point actually, because it’s we just all do kind of user stories and testing stuff like that; but a big part of, like, writing good applications is trying to think through how someone would use them

Malcolm : [32:06] And that’s kind of a lesson, I mean, developers or kind of people in tech don’t get a reputation for like being particularly intuitive or like empathetic. But it can be really helpful to kind of put yourself in someone else’s shoes. And I do find that kind of writing user facing code requires you to sort of be empathetic to their needs and kind of just kind of thing through, “what would I want to do if I was facing this page?” And think like that. At the same time it, kind of going back to web security, it’s lik trying to think through how an attacker could attack your application. It’s the same thing. It’s like, if I was not necessarily a bad person but a bored script kiddy what could I do?

Malcolm : [33:00] For instance, disabling the key down listener in Chrome Debugger, and kind of pasting the text of Moby Dick in the text field. Yeah there’s… it’s real, like trying to think, kind of step back from the code base and trying to act kind of interacting the application, in a way that somebody else would

Jamie : [33:24] Yeah. Absolutely because you’ve shared one I’d love to share one as well. My pet peeve is the “incredibly secure” websites that don’t allow you to use password managers. It’s a real annoyance of mine because, you know, it’s really important to me that I have secure enough passwords; and so I don’t know the passwords because they’re all in password managers. And there’s a certain website that I have to use every month to check some stuff, and they explicitly disallow password managers which is against a whole bunch of advice from several different governmental bodies across the world that say you shouldn’t you should not block the use of password managers; and, in fact, blocking the use of password managers promotes password reuse, which is bad.

Jamie : [34:20] And when I reached out to them and I said, “look, right. Please don’t block password managers because I want to use all 48 characters that are available to me,” because they allow up to 48 characters per password; so my password is 48 characters. It is that simple. And there is no way I’m ever going to remember it because I don’t want to, because you know I care about security. And they came back with, “well, we adhere to, you know, ‘industry standard’ best practices. And so we block the use of password managers.” And I’m like, “no . The industry standard best practice for password managers is to enable them everywhere by default.”

Malcolm : [34:56] Yeah. I mean, yeah, we have kind of moved past the, like, password must be eight characters with a number on the end, thankfully. I mean, before the kind of use of password managers, I was terrible at what password were used. I can remember about seven things, and one of those things is a password. So I reused the same couple of passwords in four words in different places. Again, it goes back to the kind of usability of the application. It’s people can’t remember these things. So this is a whole kind of chapter in the book as well about password policies.

Malcolm : [35:38] If you enforce various kind of characters, people will inevitably put a dollar sign in if they’re in the US, or exclamation mark in the end. If you require a number, there’ll be a number at the end. And it doesn’t really increase the complexity of the password in a meaningful way. The studies show that the longer password is good. I’m not… obviously a password manager where it’s genuinely obviously what the password is, the strongest. So, yeah. I mean, it’s hard to… for password management it’s hard to think of, I don’t have any more passwords in me I can’t think of another password. Yeah I was, for the longest time, I was using the one that was assigned to me by my very first sysadmin. I was like, “okay that’s my password now. that’s going to go in all the web websites.”

Jamie : [36:38] Yeah. Modern pass… like you said modern password management is tough. It’s a not a trivial problem to to solve, other than throw everything in a password manager and just trust it you know. That’s that’s what I do.

Malcolm : [36:51] Yeah. I mean one of these days the password managers will get hacked, but they’re generally pretty, pretty, secure. The only thing, the frustrating thing is like when you if you like, say I use Chrome on my laptop and then I have an iPhone. So they don’t share the passwords. I’m going to end up typing out these kind of really long strings which is really frustrating. But yeah.

Jamie : [37:21] So, I guess what are some of your other pieces of advice that are covered in the book, but without giving away all the secret sauce for the book, for making sure that we’re building secure applications?

Malcolm : [37:36] Actually, so since we’re talking about passwords, that’s a big thing, is kind of building a strong authentication system. A lot of the time, the various component parts of authentication will be available via libraries or frameworks, so you don’t have to reinvent the wheel. But there’s situations where it can be useful, or the framework you’re trying to use is too overbearing, and it kind of enforces a certain kind of approach which doesn’t gel well with the application itself.

Malcolm : [38:20] Authentication is an interesting thing to solve for yourself, but be very wary of the pitfalls. It’s the one place where there’s so many things that can go wrong that you might not be familiar with. So okay it’s my bullet point list, and if anything seems or sounds unfamiliar to you, as a listener, then go in just reading about it. So you should know how to hash passwords; so when you store a password, generally speaking, you don’t want to know what the password is, but you want to be able to retest when it’s re-entered again. And the way to do that is you store a one-way encrypted hash of the password in your database, and you recalculate that value when it’s re-entered.

Malcolm : [39:18] So that’s kind of, I mean, hashing is a big, big, big area. And what you’ll find if you go to Reddit and you say, “I’m using this hashing algorithm,” they will say, “that’s not strong enough. You should use something else.” So everyone is very kind of vague about what you should be using. But nowadays, learn what bcrypt is. bcrypt is somewhat the standard answer to, “what’s a strong one-way hash?” What’s nice about it is you can up the complexity with a simple kind of parameter in the bcrypt library, and it’s available in all different languages and frameworks. So that’s a good one to use.

Malcolm : [40:07] The other thing is, the scenario you’re protecting against here is if somebody leaks, gets into a database, they shouldn’t be able to have a full set of credentials they can start spanning other websites with. So in the worst situation you will have a, kind of, table users table, say, containing all the usernames and the encrypted password. And if it’s well encrypted, then it’s not really useful to the attacker.

Malcolm : [40:36] And then the other approach to that is when you, before you do the encryption, you inject an element of randomness called the salt or a pepper. And there’s two different aspects of this. And that means that if two users have the same password, their hash will end up differently. And you have to save the salt alongside the password hash when you do the test for when it’s re-entered.

Malcolm : [41:12] And that really is like the difference between the salt and the pepper is: salt is, I actually kind of love the terminology here. I don’t know which cryptographer came up with this. The salt is specific to each password and stored in the database. The pepper is common to all passwords. It’s still the same element of randomness, but it’s not stored in your database. But it’s stored typically in a configuration store or even code base. So it means the attacker, in order to kind of attempt to kind of crack these passwords, has to get both pieces of information. You have to compromise two systems in order to even get started.

Malcolm : [41:56] So, yeah, that’s the kind of the industry standard. There’s an exercise on password management on hacksplaining, actually, that goes through it. So it’s probably a better job of explaining it than I am doing right now. So that’s a good thing to learn from that.

Malcolm : [42:15] And then actually, while we’ere on the subject of authentication is… If you want to move beyond passwords, and any kind of secure application should do more than just a username and password, then there’s a whole kind of plethora of options for multi-factor authentication; which means generally getting your phone out of your pocket and interacting with that device to provide a second kind of authentication factor to log you. And that can look like, I don’t know, Jamie, have you used the authenticator apps where you have to type in a six-digit number?

Jamie : [42:56] Yeah, yeah, I have. And initially, I didn’t like them. But now, I actually really like that when I have to supply a, what do they call it? Time-based one-time passwords. Is that right?

Malcolm : [43:13] Yeah.

Malcolm : [43:14] Supplying them is, it makes me think, “hey, you know, in order to hack this account not only does somebody need to know my username and password, but now they need to have access to this particular instance of this app running at this time.” So, you know, it makes me feel like my accounts are more secure. Whether they are more secure or not, I don’t know, but it makes me feel like they are.

Malcolm : [43:38] I mean the cryptographers will tell you that they are, but I don’t know. We all kind of put our trust in them.

Malcolm : [43:45] But yeah, that kind of thing, the one-time password, via a kind of app, is actually relatively simple to add to an application nowadays. So there’s libraries for putting up QR codes and then synching to, say, Google Authenticator or Authy or anything like that on the phone. And if you have a relatively sophisticated audience for your application, if they’re kind of tech savvy, then it’s not too much of a hurdle; and that’s definitely, that will kind of generally close the door to all of the most sophisticated attackers. So it’s definitely to be recommended.

Malcolm : [44:24] In the past year, we’ve seen more and more people, sites using passkeys, which is a very newish web authentication standard. And it’s generally, kind of, vaguely described because it’s in the browser APIs. What it turns out to be is you end up taking a photograph, getting your phone’s camera out, taking a photo of a QR code and then visiting a URL, which then your phone will kind of identify you on, kind of the iPhone with like a face ID. And then in the background, the application will kind of recognize what’s going on. That that was very disconcerting the first time I came across that. “Why am I taking… what’s my camera on my phone got to do with this? Why is the involvement in conversation?” But, yeah, it is the kind of same kind of security principle and it’s a little easier than typing out a six digit number.

Jamie : [45:29] Yeah, it’s still along the lines of that. I know it’s not multi-factor but it is that kind of idea of having more than one factor, right. You know, I get a lot of pushback from people when I tell them, “we need to implement multi-factor authentication,” and they say, “but I have a username and a password. " And I’m like, “no, no, no, no, those are one thing,” right? That’s something you know. You need to have something you have, or something you are, or something you can get. Those are factors, right? That’s how I understand it anyway.

Malcolm : [46:00] Yeah, yeah. So it should be, that’s why you’re involving a secondary device, or potentially if your laptop has a fingerprint recognition, you can also use that. But I’m always a bit… They had that on the iPhone and they took it away. I don’t know. I don’t know what their security perhaps was there. Maybe it was all fake.

Jamie : [46:28] Who knows?

Malcolm : [46:30] Yeah. Trust the experts, which you shouldn’t generally do, but in this situation it was like, you don’t really have much choice. We’re glad that sign-on is switching over to passkeys and web authentication, because there are so many six-digit numbers in my Google Authenticator app now, it gets quite difficult to scroll through them. It’s like, “how many GitHub accounts do I have? I should pile this down somewhat.

Jamie : [47:02] No I know you mean. So because I work as a contractor–I guess in the U.S parlance it’s “consultant”–so I have a whole stack of MFA apps on my phone; one for each client or whatever, right. And the reason that I do it that way rather than having one that has everything in it is because then, at the end of that contract or the end of that piece of work and if I’m definitely not going back, I can just uninstall and remove all of the data for the particular app for that particular client; and there’s never any way I’m ever getting back into those accounts, right.

Malcolm : [47:40] Yeah. Well it’s good for them but it’s also like, kind of [don’t] phone me on friday night at 9 p.m with a security problem, because I can’t get in. I deliberately locked myself out.

Jamie : [47:53] Yeah, yeah.

Jamie : [47:53] Cool. So I know, because I’ve looked into it and I’ve gone through things like penetration tests and stuff like that, there is such a thing as OWASP–the Open Web Application Standards, sorry the Open Web Application Security Project–which, if you don’t know about it folks you should definitely check out. After you’ve done reading Malcolm’s book, by the way. And I know that they have like a top 10 of, “things that are important that people keep getting wrong in application security.” Do you think people should start there, or is that just a good idea to just know that that list exists?

Malcolm : [48:37] It’s a good starting point. There’s a couple of things. They do actively go out and do surveys, and see what vulnerabilities are actually out there in the wild and being taken advantage of. So it’s a good map of the territory. And thinking about the OWASP nowadays, rather than being super specific, it’s more like a set of categories from different kinds of classes of vulnerabilities.

Malcolm : [49:11] So it’s a fair jump from going from the OWASP top 10, which you should know, you should least be familiar with the names of these vulnerabilities and what they generally entail, to actually, “how does this look at the code base level? And how do I protect against this?”

Malcolm : [49:31] Yeah, not to oversell hacksplaining, but hacksplaining was my attempt to make this more concrete. This is not… to learn web application security, certainly, from my point of view, I need concrete examples. Like, how is this exploited? How does it manifest? And how do you protect against it? And the OWASP site tends to kind of talk to things at a higher level. So it’s like, “untrusted input. Don’t use untrusted input,” or things like that. But it’s like, what does that mean?

Malcolm : [50:10] I can’t conceptualize abstract thoughts when I’m as a coder. So, yeah, I mean, certainly read the OWASP Top 10, kind of track it as it changes. They tend to refresh it every couple of years or so. But, yeah, you should have to do some work to make sure it relates to your day-to-day, kind of, practical coding because it tends to be a little obscure. Also, I mean OWASP as an organization, they do kind of great work, but their websites are kind of a horrendous mess in places. So much is out of date. I mean, because it’s a non-profit and it’s not actively maintained, you can feel like some of this is super specific to Java developers using Java 1.4. It’s like, “how does this relate to kind of modern coding?” So it kind of can be patchy. And that’s why it’s a good idea to kind of find a security guide for the language or framework you’re using. So like, yeah, a modern sort of .NET kind of security guide should tell you most things you need to know. They tend to be pretty frequently updated.

Malcolm : [51:31] On the other hand, if you’re using, if you’re like, various points in my career, I’ve been maintaining ancient Visual Basic code bases. So you kind of, on your own, it’s like legacy apps. I do wonder how much of the internet is running on legacy apps. I kind of imagine most of it is. Yeah you have you have the luxury in the UK, Jamie of having a National Health Service. Over here we have healthcare providers and private insurance companies which have the worst websites. Either banks or health insurance just tend to have like the most outdated, kind of, ugly websites that are clearly running on kind of PHP 1.0 or whatever else.

Jamie : [52:26] Yeah I, whilst I have no concrete proof, it’s all anecdotal evidence; I am pretty sure that a lot of our critical–maybe not critical infrastructure, I don’t want to scare people–but a lot of our modern infrastructure is actually just built on lots, and lots of legacy stuff, right. It’s legacy all the way down. And and that, kind of, really it worries me a little, personally. Because I know things like you know with things like COBAL and things like that those, technologies that a lot of, not all, but a lot of the older financial institutions and things like that, are built on things like COBAL. And I’ve said it quite a few times on the show, and I’m reluctant to say it again, but like there’s very few people alive who can write COBAL now, right; let alone read it. So, you know, what do we do?

Malcolm : [53:21] I mean, yeah even not kind of going back as far as that, a lot of kind of, big companies, the code base gets established and handed down as people leave and join the company. And it becomes an exercise in archaeology to kind of just keep this thing running, so that’s common enough. Hey, I don’t know if I’m allowed to speak too much about the PayPal infrastructure, but you will be surprised how much of the financial sector is running on very, very, old code which is kind of battle tested. So there’s an advantage to it, but it’s that there’s so much, kind of, people, kind of, little workers going in there and rebuilding things as it’s running live, but it’s sometimes amazing to think these things actually are still up and running. PayPal is very secure, and you can definitely trust your money with them, so don’t worry about that. Of course.

Malcolm : [54:30] The other system, interestingly, I learned about recently was a lot of the credit card companies still use fax machines, or at least use fax channels behind the scenes to transfer documentation and things like that. So once this technology is in there, it never really kind of gets replaced.

Jamie : [54:54] Yeah, because if it’s not broken. right. It’s still working.

Malcolm : [54:57] Yeah, yeah. I mean it’s never… I kind of done various jobs in my career and it’s, like, it’s never fun to get put on like, “hey maintain the stack. Try and fix this code that’s completely alien to you.” And trying to kind of get presented with a code base where it’s a completely, kind of, out of date a paradigm. It’s been chugging along on a bunch a couple of like Windows or Linux servers for a decade. But I mean, that’s the job, that’s… we are a lot of us are, kind of, maintenance engineers and that’s kind of necessary to kind of to kind of do. So I don’t know.

Jamie : [55:44] Oh absolutely, yeah. Absolutely, I agree. I’m conscious of the time that we have together and I wonder if maybe if you have another five or so minutes, I’d love to get your thoughts on secure by default. I know that that means we’ve, kind of, not very nicely segued into something; but if you have the time, have you got like the next five or so minutes?

Malcolm : [56:09] Sure, yeah, yeah. So actually, I have a good segue for that. The way I write code, and I think this is the way that most people approach kind of problems, is we don’t have to admit it. What we do is we take an existing code base and then we tweak it. So much of our work is kind of replicating patterns which are already in there, whether it be it from Stack Overflow or ChatGPT or like a blog post somewhere, or just, “using existing copy across existing classes and then rename it” people out there.

Malcolm : [56:46] And that’s, kind of, it’s just saving time. It’s a sensible way of doing things because it’s particularly boilerplate code. So what you find in your career is that if you set down kind of sensible default behaviour in your codebase earlier on, then everyone will follow that. You establish, kind of, best practices. It might take a little bit longer, but if you say, “this is the way we do this over here,” then even yourself when you, kind of, come back to, will kind of, reproduce that path. So the initial, kind of, like first few check-ins to your source control are key to, like, establishing best practice. That’s what I like to think about by, kind of, default behaviour: is like it just add the code base just kind of starting out on the right foot. And then you’ve kind of set the template for other people to follow.

Malcolm : [57:44] The other aspect of like secure by default is probably just assume that your application will get attacked at some point. Most of the writing code which goes on the internet or kind of is called from HTTP in some fashion. So you can assume that there will be maybe just drive-by attacks. If you are a high-profile target, there’ll be like more specific attacks. So assume that somebody is going to try and hack you from day one, which is kind of intimidating.

Malcolm : [58:23] But if you follow, kind of, just a fairly, kind of, sensible set of guidelines around security it’s, like, it’s not at a high risk. You’re not… most of them not going to get targeted by some kind of high end, Russian hacking group with a fun kind of a codename with the FBI. Most kind of attacks on the internet, basically, come [from] scripts that just kind of poll URLs and check for admin pages on WordPress and things like that; or the new kind of SQL injection attacks. So as long as you’re kind of closing the door on those kind of, the low risk attacks, you are generally going to be secure in the long run

Jamie : [59:11] I can speak to some real-world experience of those low-level attacks. One of the websites for one of the apps that I’ve built routinely gets people trying to go to /wp-admin.php, which is the login page for WordPress. And it doesn’t use WordPress, so that’s where your analytics comes in. But what was great about what I did was I set up a 301 redirect that if anyone goes to /wp-admin.php, they’re bounced automatically to Rick Astley’s “Never Gonna Give You Up.

Malcolm : [59:52] They’re looking for some very disappointed attacker.

Malcolm : [59:55] Yeah , and it it’s interesting. Like, if you do have a, kind of, a website with any kind of traffic, you do see these, kind of, very familiar attacks: just kind of scripts pinging stuff. And I don’t know what the kind of, value of, kind of, hacking someone’s WordPress site is, but I guess it’s easy enough to do and there’s so many unpatched instances of going, it’s worth the attacker’s time.

Malcolm : [1:00:24] There’s a whole chapter in the book as well, and on the website, about updating dependencies and patching security holes. There’s another aspect to building a codebase and maintaining it. So just being on top of when there’s new vulnerabilities, and knowing how to address them is another aspect of our jobs. You may have an in-house security team as well, if you’re lucky enough to [work] at a big enough company. But we’re sure we’re kind of mindful of that at the same time. The aim is that when the security team come knocking and asking, “have you patched the heartbeat vulnerabilities?” If you’re already there, you can say, “it’s all taken care of.” That involves a fair bit of scanning Reddit, or HackerNews, or social media sites and whatnot.

Malcolm : [1:01:16] Or listening to Jamie’s podcast.

Jamie : [1:01:21] Yeah, I often tell people that the best way to, first off, know what you’re running. So if you can get SBOMs or just know what things you are using to build your stuff, and then go ahead and sign up for mailing lists–the official mailing lists–for those things, right. Because you you don’t always find it, but most of the time you find that they will announce, “hey, there’s this really critical vulnerability. You need to upgrade,” either publicly on, like, their social medias or through a mailing list, and so you get to know that pretty quickly.

Malcolm : [1:01:58] Yeah. I mean Manning is a great one of that particularly because when you have a, kind of, deployed library or framework, if there is a vulnerability then immediately hackers will start scanning for it. So if you’re sharing a codebase with other people you don’t want to be behind the curve on patching, because then you are definitely a target. So that’s one aspect.

Malcolm : [1:02:24] On the other hand, if you’re writing and maintaining a COBOL codebase from thirty years ago, then that’s less of a concern. But I mean it’s… there’s different ways of securing an application; there’s different kind of concerns depending on the recency of your your framework.

Jamie : [1:02:40] That’s true, yeah. That’s true.

Jamie : [1:02:41] Excellent. Well as we start to wrap up, Malcolm, I wonder would you be able to remind listeners of the book, and the website and so then, obviously they can go ahead, take a look at those things and check them out. And then maybe, yeah, would you mind doing that?

Malcolm : [1:03:02] Sure, yeah. So the book, which I’ve touched on a couple of times in the podcast, is called “Grokking Web Application Security.” It’s, kind of, on Manning Publications, but it’s available on Amazon and so on. And the website, which is, a kind of, more interactive version of the same thing, more kind of focused on specific vulnerabilities, It’s called hacksplaining. I’ve always been a bit indifferent about the name but it’s memorable at least.

Jamie : [1:03:31] Yeah, yeah. It’s kind of like the word “explaining,” but with “hack,” instead of the “ex,” right.

Malcolm : [1:03:37] Yes. Yeah, yeah.

Malcolm : [1:03:39] Excellent

Jamie : [1:03:40] Well, I’ll get links to those, I’ll put those in the show notes; so no one has to like figure any of that out whilst they’re listening. So that’s not a problem.

Jamie : [1:03:47] I would like to thank you, Malcolm, for spending part of, what I’m guessing is your morning and my evening during this recording. Because I think I feel like, regardless of like, I said at the beginning, regardless of the tech stack involved, and yes there are nuances like, “hey, how do I secure a .NET app?” versus, “how do I secure a Java app?” versus, “how do I secure a go app?” There are nuances in each of the frameworks and technologies, but I feel–and I may be wrong about this, but I feel like you’ve proved my point for me–that there are a number of things that are super important, that it shouldn’t really matter which language and framework that you’re using. So I really appreciate you coming on, and sharing all of that stuff with the listeners.

Malcolm : [1:04:35] It’s been a pleasure Jamie. And, yeah you’re right. It’s most of our code is a machine for understanding HTTP requests. So yeah, the vulnerabilities kind of crop across the board

Jamie : [1:04:51] Excellent excellent. Well like I said Malcolm, thank you so much for spending this time with us. And best of luck with the book.

Malcolm : [1:04:57] Okay. Thanks Jamie.

Jamie : [1:04:59] Thank you very much.

Wrapping Up

Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. I’d like to thank this episode’s guest for graciously sharing their time, expertise, and knowledge.

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 the podcast's website, 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/review for ways to do that—reach out via our contact page, or join our discord server at dotnetcore.show/discord—all of which are linked in the show notes.

But above all, I hope you have a fantastic rest of your day, and I hope that I’ll see you again, next time for more .NET goodness.

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

Useful Links

• Malcolm on LinkedIn
• Grokking Application Security
• Hacksplaining
• Hash function
• Bcrypt
• Supporting the show:
  • Leave a rating or review
  • Buy the show a coffee
  • Become a patron
• Getting in touch:
  • via the contact page
  • joining the Discord
• Music created by Mono Memory Music, licensed to RJJ Software for use in The Modern .NET Show