Mastering Web Security: Myths, Strategies & More!

Unveiling Web Security Vulnerabilities

Sebastian Brandes: Hey, my name is Sebastian Brandes, I'm one of the speakers here at GOTO Copenhagen. I'm also the Founder of Heyhack. And I'm sitting here at GOTO Unscripted together with?

Scott Helme: I'm Scott Helme. I'm the Founder of Security Headers and Report URI. And I'm also doing a talk here on similar topics to you, I believe.

Sebastian Brandes: Yes, exactly.

Scott Helme: So you already had yours today, did you just say? So I've only just arrived, unfortunately, due to travel problems. So I actually missed that. What was the topic?

Sebastian Brandes: So we spoke of a very large study that we've done on web applications out there. We've been scanning around 4 million services and checking for all kinds of things, everything from security headers, or missing security headers. Sort of a basic thing, but a very important thing. We've also looked into known vulnerabilities, so known CVEs on servers that are sitting out there. We have a service also where we can go ahead and do sort of the extra step and do more of a pen test. But we've obviously not done that without the consent of these 4 million sites. So we've kind of been scratching the surface a little bit. But that's really been enough to sort of build out this report, or sort of, like, say something about the state of web app security out there. And many of the things that both you and I have talked about for many years are still very much relevant out there. And I think it's about time that many organizations take this a little more seriously, and maybe invest a little more into AppSec.

Recommended talk: The State of Application Security 2023 • Sebastian Brandes • GOTO 2023

Scott Helme: It's definitely a common trend, isn't it? I think just going to what you said there about how it kind of feels like we're still talking a little bit about the basics. But then at the same time, it's like, well, I'm still talking about them, because they feel really relevant. And, you know, sometimes we look at areas of the web where we've made really good progress. And, you know, HTTPS, obviously being like the poster child for what we can do when we put an industry to work on a thing. I think a lot of people, especially, like, with me founding Security Headers, it's like, if you do a security header scanner, you've got all of the security headers. It doesn't mean you're not going to get hacked. It's a really good indicator, I find, for other things as well.

And a lot of the time, these things are...like, most security headers on-off configuration, essentially, aren't they? It's a good indication of the security posture of the organization. It's like, well, have they got the basics in place? And if they don't, can we then allude to other things that they may not have in place as well? I think they're important. If you deploy all security headers, you can't say, we are not going to be hacked now, you know. It's not that kind of security. But I definitely think they're great starting blocks. And if you're running a web app, you know, the basic levels of protection that you can get for really simple things, I don't think you can beat that anywhere else.

Sebastian Brandes: No, exactly. And I think especially...speaking about security headers, I think one of my sort of, like, a thing that I keep talking about all the time is content security policy. I think we're sort of on the same page there, right? So it's just a shame that it's not been deployed more often. Not that it's a catch-all thing that's just gonna save you from all kinds of types of issues. But it's a good type of insurance. Like, if you do introduce something that you're not well aware of at the time, it might catch you, right? Like, particularly cross-site scripting and many other things. What do you see, like, based on the results from Security Headers, with respect to CSP specifically?

Scott Helme: It's one of those things that's been a slow burner for a very long time. We are starting to see, like, the continuation of just a very steady trend., I have another project of mine called Crawler. Ninja. That's actually the domain. I scan the top 1 million websites every day. One of the things that I look at is, do they deploy a valid content security policy. And I can go back every single day for around about six or seven years now. And we see this, like, very gradual trend. And it's only the top 1 million sites, but arguably, they're the 1 million that are most likely to have a CSP because they're the biggest.

So, we look at that and think, well, you know, we've got, like, this very steady rise, and I'm still waiting for the hockey stick like we had with HTTPS. I'm hoping, like, there are some new PCI regulations, if you're an E-commerce site, the new PCI regulations come into effect in 2025. They will require a content security policy on payment pages where users put card data because they keep ending up with JavaScript, like you said, some dependency that we didn't want or we didn't know about. Content security policy is the number one thing to help you with that.

Sebastian Brandes: Now you're saying most security headers are, like, an on-and-off kind of thing. But I think CSP might be the exception to that.

Scott Helme: Correct.

Sebastian Brandes: You need to do a lot of configuration and keep it up to date.

Securing the Modern Web: Strategies and Challenges

Sebastian Brandes: What's a good practice you think for working with a good CSP and keeping it relevant?

Scott Helme: So I should probably preface that with, I'm hugely biased because that's what my company does. So, you know, full transparency to everyone out there. But the biggest thing that you kind of hinted at, there's like two components that we break it down into. Number one, building the CSP, because it requires you to write a list of all of your external dependencies. And most people can't even begin to write that list. So we built a thing called the CSP Wizard, which will create the basic policy for you, and say, well, here are all of your external dependencies. And then you just need to tell us, "Oh, well, we expected to have all of those, but I don't know what this one is. So, you know, throw this one away." And then the ongoing maintenance as well, because of course, sites are quite dynamic these days, they change a lot. So you have to keep the policy up to date with what you have.

And the thing everyone's worried about doing is breaking their site. You know, so if your content security policy doesn't allow JavaScript to load, and that JavaScript is essential, that functionality will break. And this is a really big thing that we come across with all of our customers. And you don't have to run the content security policy in enforce mode to get the value. There is a content security policy report-only mode, which is like a safe test mode. So if you deploy policy in that mode, and then it starts sending reports, like, hey, you've just got this new JavaScript dependency. You're still getting that feedback, and you're getting it instantly. And you can take action immediately.

Whereas when most sites get hit with cross-site scripting, or, you know, like, a supply chain attack, they don't realize until weeks or months later. And it's like, okay, well, you know, yes, you're going to have a cyber-attack for those 12 minutes. But it's better than 12 weeks. Right? And that's what usually happens in these cases. I think you're absolutely right. CSP is pretty much the only one that's not an on, offsetting. Because the content security policy is about writing, what should be on my site, and therefore everything else should not be on my site. And of course, that is unique per site.

Sebastian Brandes: Yes, exactly. Another pragmatic way of doing it, that's how I do it, at least myself, is to put a very restrictive CSP up and first, try to run your site sort of in localhost on your own developer PC and see what breaks, right? They are going to help you quite a lot just by looking at the tools, seeing which... Yes, exactly. And it can kind of work the same way. Right? The issue we find sometimes is if you depend on some third-party services. So for example, in our own product, we've got a HubSpot chip. Unfortunately, HubSpot doesn't think about security the same way I think you and I do, right? So they'll invite you just to put in a script tag there, of course, no dependency integrity tag either on that. They kind of want to be able to live update whatever they put on your site. Not only that, they also like to change the host names wherever they put their scripts. So it's very hard to, like, keep that running in production. Even if you've said it the right way and it worked whenever you developed it, it might break sort of along the way.

Scott Helme: Third-party dependencies can be dynamic as well.

Sebastian Brandes: Yes, exactly. And what's a good way of going about that? Do you have any suggestions in that regard?

Scott Helme: There's a couple there actually. So, like, both of these are in my talk tomorrow, actually, because they are the biggest problems that people come across. And obviously, those are the problems that we should talk about. So, the first one that you mentioned, SRI, Subresource Integrity, is for people listening. If you don't have that on your script tags, you absolutely should. Apart from the fact when you download essentially dynamic JavaScript from someone like HubSpot, one of the examples that I give is, like, the stripe.js file, or if you have other payment processors, they require you to load this JavaScript file. And it changes every single day. And then it's very difficult to pin that down and say, what should it do when what it does changes every day. So, now, we have a feature in content security policy, where you can basically say, look, I want to load my dependency for, you know, stripe.js or hubspot.js, whichever. And then I trust this dependency, so I'll allow it to do whatever it wants to do.

Recommended talk: Crypto Heist: The Aftermath of a Government Website Cryptojacking Attack • Scott Helme • GOTO 2023

So it kind of gives you the strength to lock it down and say, I only trust, you know, HubSpot or Stripe. But I trust them to do what they need to do. So, it's kind of, like...you know, the only real scenario you need to worry about is, like, oh, well, what if Stripe gets hacked? And I'm like, well, if that happens, we're all doomed. So I'm kind of okay with this. It's a reasonable approach. It fixes the problem that you just mentioned, which is one that people come across all the time. You know, I have a dependency that loads dependencies. How on earth do we deal with this? And that's called strict dynamic in CSP. So you can say, look, I trust this dependency, let it go do its thing. And apart from this dependency, I also have these other three. And that's it.

Sebastian Brandes: Exactly. That's a good way.

Scott Helme: So it can be done, it's just, again, like you said, CSP is one of those features where it just requires that little bit of configuration because it's unique per application.

Sebastian Brandes: Switching maybe to sort of another topic, but still sort of along the same lines here. Quite often, when we engage with new organizations, we do these pre-scans of their infrastructure. So we try to map out all the different services that they expose. Quite often, when you speak with an organization, they'll have a lot of attention directed towards sort of their main applications, right, their main customer portal, or whatever that might be. Right? But very often, we find issues in these legacy applications that still tend to be out there, right?

Scott Helme: Shadow IT, we call it.

Sebastian Brandes: Yes. All of that stuff, right? And if you haven't set HTTP only for your cookies and host only for your cookies, there might be sort of a risk of leaking these cookies across your domain. So even a very old application that might even be up for decommissioning, it's not getting a lot of attention in the organization any longer, could still sort of take down all of the rest of the stuff. What are some good ways of sort of managing that, or maybe first of all, becoming aware of that, and trying to contain sort of the risk associated with those applications?

Scott Helme: I kind of picked up, like, two distinct angles there, I guess. One is the kind of shadow IT thing where, you know, there's an application that's working and no one's looked at it, or touched it, or patched it for however many years. But then I was kind of also getting a hint of the other, which is like the internal external perimeter. We seem to have, like, very, very different security equations on each side of that perimeter. That's something that... Because I used to be a penetration tester if we go back quite a few years. You know, that was my first foray into the security industry. And it's a really common thing to be like, oh, well, this is an internal application. We don't therefore need any of these security things because we have this impenetrable firewall on the outside. I've even seen scenarios where missing, like, some of the security controls that you mentioned there. People forget that you can hop that perimeter quite easily with things like cross-site request forgery.

If you've got a person inside the perimeter that visits a website on the outside, some innocent innocuous site, and then they start running JavaScript, that JavaScript can communicate with those applications internally, right? Just send requests to internal IPs, spam them all in a loop and, you know, off we go. So, yeah, I think we need to kind of break down this idea of the internal versus external, you know, thing, especially as like a security boundary. And we see that with HTTPS as well still. Oh, it's an internal application, it doesn't need HTTPS. And we're like, well, the network is the network, as far as my view goes. If it's going across the network, it's going across the network. It doesn't matter if it's inside or outside.

And then yeah, in terms of the kind of, like, shadow IT/legacy thing. One of the organizations that I work with at the minute, they're focusing on, like, how do we actually map our infrastructure? You know, like, we can't fix the things that we have if we don't know the things that we have. So doing that kind of inventory, or that audit of all of your exposure is actually really one of the first things. So I do a lot of work with a DAST scanner company as well, whom we've recently partnered with on security headers. One of the best things about the scanner is its capability to crawl. And, you know, whenever we look at it in comparison with other DAST scanners, it's like, okay, well, like, really, the most important thing is coverage, because, you know, there's no point finding 100% of vulnerabilities on 40% of the application. So it's really kind of, like, the first and foremost thing is you've got to try and push coverage to 100%. And, you know, that's why I think that's such an important angle because you've got to know what you have if you're ever going to secure it.

Sebastian Brandes: Yes, exactly. I think we're kind of working with a mantra that you can't assess what you can't see. So if you're not going to find the functionality in the first place. I think, unfortunately, there are a few legacy providers in the industry that speak very much about sort of the very vast test that they're running. But might not be up for the task of crawling modern web applications that are very JavaScript or client-side heavy. And so they might not be able to find all of the interesting bits of the application where it's probably needed.

Scott Helme: Think about all of, like, the authentication flows, business logic, you know, payment flows. There are so many different things in any kind of modern app nowadays.

Sebastian Brandes: Yes, exactly.

Scott Helme: I find as well, with a lot of the legacy kind of approaches, they're testing for vulnerabilities and technologies that the application doesn't even show signs that it uses. And it's like, "Oh, well, our scan is gonna take four days." And I'm like, "Well, yeah, but you can dump three days because we don't use any of that stuff." So, we need to be a lot smarter about these things.

Sebastian Brandes: There's not a big point in testing for backups of .htaccess files if you're not running an Apache server in the first place, right?

Scott Helme: It's like, oh, we're currently on the SQL injection part. Great, we use Mongo.

Sebastian Brandes: Exactly. There you go.

Scott Helme: Why are we here?

Beyond Boundaries: Securing Shadow IT and Legacy Applications

Sebastian Brandes: Exactly. So, certainly true. Speaking a little bit about sort of these sort of shadow IT or things that are running out there that you might not be aware of. We just recently spoke with a large organization that had this funny little application that somebody built, kind of like smelled a little bit like an application that had been built by a developer on a Friday afternoon, sort of as a tool to help their colleagues. Right? And so it was a password generator. Basically, this little app that could generate a secure password, sort of, I guess is an alternative to a password manager that might have this built in. So you could just use it. And it was a publicly exposed web app on a subdomain on their main website.

Now, unfortunately, this developer probably had the intention of helping their colleagues be more secure by helping them create secure passwords. But it turned out that it was vulnerable to cross-site scripting in itself. Yes. They weren't very strict about using some of the good flags, so they had lots of leaks across their domains. You could really start, like, lots of the ingredients for a good attack were definitely present there. I think I'm just mentioning that case because we've seen many of those types of applications out there that nobody pays attention to because it's not a critical application. Well, it's on a critical domain, and you haven't really gotten all of your other stuff in order, right?

Scott Helme: And they start out with the best of intentions, don't they? Like you said at the beginning, somebody thought, you know, I'll quickly put this together. It'll be really helpful. But then it's like, okay, but now we have more stuff. And I come across so many things like that, where they start with the best of intentions, and they've got no, you know, budget oversight management, and they just kind of, like, sit there and work. And yeah, it's quite funny.

Sebastian Brandes: I think sometimes in security, unfortunately, there's a little bit, of this idea where you have so many problems, you know, related to security. You've got 100 problems, you try to develop a solution for it. Before you know it, you've got 101 problems, right? So you kind of have to stay on top of what you're doing with respect to that.

Scott Helme: I'm trying to remember the old saying for that one. It's like, standards of toothbrushes. It's like, everybody wants to use one, but nobody wants to use somebody else's. We could probably make, like, most of the tooling that we have to do most of the things that we need, but we always need more tooling. We always need more applications.

Sebastian Brandes: In the talk that I gave, I had another case that was very similar to this example that I just gave. It's a public case at Checkpoint Technologies. They had some researchers there that found an issue at Epic Games, the producer of "Fortnite." Same thing, again, they have this old site for "Unreal Tournament 2004." I think they had a competition or some sort of a tournament at some point where you could see all of their stats. And you could just tell from the web design that it had been sitting there for a long time, right?

And turns out, it's vulnerable to cross-site scripting. They had an issue in their OAuth flow that let anybody basically redirect back to any other domain on funepicgames.com. So they could trick somebody into logging into their account, and then redirect back to this old application. It's a public study. And I guess Epic Games has been okay with, like, revealing that. It's on Checkpoint's blog, if anybody wants to check it out. But again, it's kind of to the same point that it's quite often these things that you're not aware of that will, you know, make you fall. And not always your main app that gets a lot of attention, right?

Scott Helme: I think it kind of potentially goes a little bit towards the kind of defense-in-depth strategy as well. We still come across this really super traditional view. Part of the internal external perimeter is part of that kind of... that really traditional view, where, like, there's one way to solve a problem. It's actually, like, well, you know, we can break this down, there can be multiple smaller mechanisms that actually combined, provide a larger benefit overall than just viewing this as like, you know, we need to solve this one problem. And I think that's why people, like, in the course that I'm doing this week... So I'm doing Troy Hunt's Hack Yourself First workshop on Thursday and Friday. And we still do a little bit of SQL injection. And people are like, well, you know, have we not solved this now? And I'm like, well, actually, no.

Recommended talk: Lessons From Billions of Breached Records • Troy Hunt • GOTO 2022

Sebastian Brandes: Well, there was a little application called Move it It that turned out to be vulnerable to ...

Scott Helme: I wonder if anyone's heard of that one. I think a lot of it comes from... To kind of, like, bring it back to the point, people will look at that piece of vulnerable code and be like, right, this is the vulnerability, we've now fixed the vulnerability because we patched that line of code. And I'm like, right, but we need to go more holistic. You know, we need to kind of take a step back and think, okay, actually, rather than just keep patching these vulnerabilities when they pop up, is there a way that we can step back and think actually, you know, is there something that we could fundamentally change at a slightly higher level, that would blanket all of these issues? It goes back to that really traditional...oh, this is the vulnerability, we'll patch this. Fixed. You know, tick on the compliance box or something like that. So yeah, I think that would be another good thing, is to start looking at solving security at a way more kind of broad-spectrum scale.

Sebastian Brandes: Definitely. And speak a little bit about SQL injection. So, there are many web application firewalls out there that will tell you just by the sort of a whip of a magic wand, they'll fix all of your SQL injection issues.

Scott Helme: I have such, like, a fundamental problem with being the answer to everything. And it's not to say that they...you know, they serve a fantastic purpose, and we should have them, and we should use them. But I think everybody misses the part where they're like a temporary solution to the problem. And then we go fix the actual problem. And that second bit is usually the bit that I find that doesn't happen.

Sebastian Brandes: We just did a test with a large web application firewall out there. And my personal experience is that they have a tendency to reject a lot of genuine users. So they can generate a very bad user experience, especially if you put them in a strict mode and a prevention mode. But they might miss the actual attacks, right? So we had one case of one specific web application firewall out there, where just by making any query that would include the words union and select, it's going to just reject it as an SQL injection attack, right? So we had set up this little demo on the OWASP Juice Shop, I guess, the industry-standard web app for testing these kinds of things. If you don't know it, it's basically, I guess, the world's most vulnerable application, I guess you could say. We'd made a test where we would, you know, do some tests against it without a WAF in front, and one where we would put a WAF in front.

And we just tried making a request to their search endpoint, so having this bogus query, saying, "Hey, Joe Biden has just given the State of the Union, and the American people have chosen to select him as President." And just that little weird phrase was... Yes, exactly. But on the other side, and this is the thing that most of these web application firewalls suffer from, you can try to insert some different characters that are not going to affect the actual SQL query that you want to execute. But it's going to break the rule engine. So, you can try and play around with it yourself. But many of them cannot handle load bytes for some reason. So if you put load bytes into the middle of your SQL injection attack, the WAF is not going to protect you. And you can still execute that query.

Scott Helme: We have a similar kind of part...one of the modules in the workshop, again, where we do filter evasion. And, like, cross-site scripting filters are another alongside SQL injection, they're another really common one. The idea that you can write... And I guess this is the overall point of the module. But the idea that you can write some filter that will catch all the bad things, implies that you know all of the bad things that exist. And I'm like, well, you know, can we sit here and say, I definitely know about every single thing that could go wrong. And I'm gonna write a list of them and then stop them. I was like, you know, I think just on that explanation alone we can agree, you can never write a filter that will catch everything.

Sebastian Brandes: Exactly.

The Fallacy of Filters: A False Sense of Security

Scott Helme: By that very definition, straightaway, filters are kind of... I find them a lot of the time a false sense of security. Because people are, like, oh, we have, you know, a cross-site scripting filter, a WAF. So now we don't need to worry about it. And it's like, have the filter in the WAF, try and have it as your first point of contact, but still make sure that you're properly escaping outputs, you've got a content security policy. You know, like, this is the defense-in-depth strategy. Right? Like, we've now got three things. And they're all relatively easy to do. You know, it's like most frameworks will take care of the encoding part for you now. And content security policy requires a little bit of, like, work, but really not a lot. And sticking a WAF up is, like, clicking a few buttons now, isn't it?

Sebastian Brandes: Exactly. I feel like a lot of people have a lot of hope, or expectation in a WAF or that the WAF is just going to do all of it for you. But if you sort of compare it to network firewalls, I mean, not a lot of people would expect that you can just buy a firewall from Cisco to protect your network and not configure it, and it will still fix everything for you. Right? Like, I know many people whose full-time job is to just configure Cisco firewalls in the network.

Scott Helme: Well, they're just, like, an unknown kind of dark art or something, aren't they? I'm sure they have, like, special sauces in Harry Potter that would qualify for configuration of especially, you know, kind of hardware firewalls like that.

Sebastian Brandes: But I guess the point is just like, okay, I mean, configuring your firewall is a full-time job, whether it's a network firewall or a web application firewall, essentially, right?

Scott Helme: But people overlook that a lot. Just the complexity of any given role, I think. We've got a lot of... I've actually been writing a blog about it. We've had a couple of issues on Report URI recently, like, technical problems. And it's like, oh, you know, I really need someone that's good at, like, building... A DBA, basically, was where it was going. And I was like, I really need someone that's good at, like, knowing how to structure the data and build the queries. And I'm like, that's a person, that's a job. You know, like, that's a whole art in and of itself. So, yeah, it's the same with so many different security roles as well. You know, there's a lot to it, and a lot more than people usually realize.

Sebastian Brandes:  So, Scott, we're talking about all the problems in application security here. And I guess lots of the viewers, you could be a little depressed about how hard it might be to actually fix these things. But what could you do? What would be a good way of setting up an application security strategy?

Scott Helme: Wow, I think you've got to have direction from above, in the, like, developer level, first of all. You know, I think whilst we can definitely promote it and drive it from kind of developer technical staff level, if it hasn't got the support, or the initial direction, at least, coming down from the top, like we're done.

Sebastian Brandes: Exactly.

Scott Helme: My side of things comes more from, like, the technical testing, and the fixes, and the implementations. In terms of driving a strategy internally, you've got to have people invested. You know, and this is coming from my kind of slightly uninformed view, I guess, on this. But you've got to have people invested. You've got to have people understand that security is everyone's responsibility now. You know, I think we have, again, this very traditional view, where we have an organization of a thousand people, and there's a security team of five people. And it's like, well, that doesn't really work anymore. You know, we need to take that focused security knowledge and just, like, sprinkle it across the whole organization. Because I think everybody having a very small amount is better than everybody having nothing, and five people being, like, responsible for security.

Sebastian Brandes: Yes. Definitely.

Scott Helme: I think, you know, that kind of baseline knowledge across organizations. We've got to understand, like, nothing is ever the user's fault. I've been in organizations so much, where users are kind of just blamed. It's like, oh, they clicked a link in the email, and our infrastructure blew up. And I'm like, well, your infrastructure is really the problem in that. If I can click a link in an email and blow up your infrastructure, I don't think the user was the problem there. It just requires a bit of a change in mindset from a lot of the traditional views on how we do security, I think.

Sebastian Brandes: I think I totally agree with you on that. And then I think people have to understand that it's luckily not so hard to fix many of the massive issues that exist then with app security. Like, setting these security headers for all of your services might seem like a daunting task. But if you actually look into what it requires for many organizations, it could be done within a day or two. I mean, it's not a lot of effort. But the outcome or the protection you'll get is high, right? You get a lot out of it. What we find quite often is to have somebody own it in the organization. And that will typically be the security division, right? Having a CSO or a director of security or whatever, but still getting the developers on board. Because quite often, developers have to sort of implement things, whether it's content security policy, or correctly sanitizing some input, or escaping HTML characters. But if you understand the underlying problem, and the Open Web Application Security Project, or I guess it's called the Open Worldwide Application Security Project now...

Scott Helme: I think it changed and no one saw.

Training Strategies in Application Security: Balancing Automation and Education

Sebastian Brandes: Exactly. I kind of just switched out the W there. But they have a super good resource. And maybe just for somebody to...or for the viewers at home to have a look at the cheat sheet series at the OWASP. It's super good. And they've got basically coverage of all types of issues you could imagine in a web app. And then I guess the training. I'm super happy that you're giving this training here at GOTO now.

Scott Helme: Should be good. I'm looking forward to it. Thursday, and Friday, are for the training. I've definitely not done GOTO Copenhagen before. I think I did a previous... I go to, like, lots of different events, so it's hard to go back. Especially everything before COVID. It's just like, I forgot all that now. But yeah, I think I did a GOTO somewhere else as well. I can't remember which one it was specifically. Are you workshopping this week? Are you training?

Sebastian Brandes: No, not this week, unfortunately. But I'd be happy to sort of take a sneak peek at yours.

Scott Helme: Good. Yeah. Feel free to come and jump in. The beginning of day one is, like, a little bit of setup and introductory kind of stuff and getting some tooling ready. But yeah, by like the morning coffee break, we're hacking stuff.

Sebastian Brandes: Very cool. It's very hands-on, I guess then.

Scott Helme: At least a third of the time, I would say is, you know, I demo basically a community attack. I explain what happened. I'll do some SQL injection, dump some data out, and explain what happened. And then literally, the first step is, right, go reproduce this. Go and do it yourself. Dump the data out of the database. You know, then people figure out they can change other people's usernames. Then we usually have a little bit of fun. And then yeah, it's like, right, let's go look at, you know, what happened? How did this happen? And then the end of every module is the resolution.

Sebastian Brandes: If you miss this week's training here, is there any other way you can jump into this training or access it in some way?

Scott Helme: On my website, I always have an upcoming events section down the side. And it's got things like the registration link for here. I've got another one... So I do a lot of private ones with companies and their own on-staff. But public ones, there's one coming up at the beginning of January in Norway, one in January in London as well. And they're both public for... You know, if you've got, like, one person. I keep doing those because they're accessible. You know, if you've got three developers, you can't have a full training course with three people, it doesn't work. So I like to keep the public ones on offer as well.

Sebastian Brandes: Very good.

Scott Helme: And yourself, are you...

Sebastian Brandes: We are mostly doing training whenever we engage with organizations. So, we try to bundle things together in sort of one package. We have an automatic web application scanning solution as well. And as I've said before, I care very much about coverage like you do as well. So we try to, like, make that sort of the baseline of things, where we recover as much as we can. And then we train developers and organizations to understand the outputs of these scans. I mean, many tools have the tendency to just produce a long list of issues that nobody really understands. It becomes kind of this thing that you don't dare touch. And alert fatigue is a big thing in our industry as well.

Scott Helme: False positives are so bad for just the overall improvement of security.

Sebastian Brandes: Exactly.

Scott Helme: Like, once you give somebody, like, three false positives, they're just ignoring you from now on. 

Sebastian Brandes: Exactly. So if you, from sort of the automatic side of things, can reduce the number of false positives, and you can upskill developers to understand the output a little better, it might not seem as scary. You know, fixing cross-site scripting issue, even though it's got sort of this high severity mark on it, and everything's red, you can fix it within five minutes if you know what to do. Right? So, like, combining sort of automatic solution with, just as you said before, sort of a baseline level of knowledge in security, seems to be the perfect recipe for getting started with this.

Scott Helme: And it's interesting to see that we're obviously both independent, and we've, you know, like, naturally just come to that conclusion. And there are other people that I observe in the industry as well, that have really similar approaches. And it's really easy. Like, when you're doing it, you just look at the results. Right? And then over time, it's like, oh, well, that one didn't work so much. And this approach was better. And we all kind of might end up naturally following the same path. And it's just based on the results, right?

Sebastian Brandes: Super cool. Thanks a lot for the chat, Scott Helme.

Scott Helme: No worries. Thank you as well.

Sebastian Brandes: Good luck with the training this week.

Scott Helme: Yes. I hope you have a good conference.