Adam Gleeson:

Hello and welcome to another episode of Tales from the CyberLab. Today with me I’ve got David Dixon, who is one of my colleagues within CyberLab, and he works in the security testing team as a Pre-Sales Consultant. Hello, David. Welcome to Tales from the CyberLab. Would you like to tell everyone a little bit about yourself?

David Dixon:

Yeah, sure. My role at CyberLab is Security Testing Pre-Sales Consultant. Effectively, my role is to support our commercial teams in having client engagements. We typically have Teams meetings to scope projects for pen testing and a number of other security consulting projects. Been in the cyber security industry coming up about seven years now. Before CyberLab I was with a relatively known company called NCC Group where I worked mostly in commercial roles and then eventually made the transition into pre-sales.

Adam Gleeson:

Cool, thank you. And today we’re going to be talking about cyber security for websites and web apps, so ‘Cyber Security for Websites and Web Apps Explained’ is the title. So why do we need website and web application testing? And I guess maybe it’s worth actually thinking a little bit first of all about what the differences between when we talk about a website or a web application, are we talking about the same sort of thing?

David Dixon:

In principle? Yeah, I mean generally people might define websites and web applications as sort of two different things, but ultimately a web application is any application that can be accessed via a web browser and that provides functionality or can access services over the internet. But ultimately even a brochureware site or a static single page website is still technically a web application. It’s just the terms website and web app are just two categories of the same.

Adam Gleeson:

It’s one of these phrases that’s just sort of become in common use unless you’re actually working in and around that sort of stuff. Sometimes it can be like, well, is it a website application or it a web app? Is that something different? But I think exactly like you said, a lot of, I mean even on mobile devices now, the applications that we have on there or the version of the application that’s on the mobile devices is built using web code, isn’t it?

David Dixon:

Yeah, absolutely. And you think about apps like Spotify, Amazon, or Instagram, they are typically mainly access from mobile devices, but you can also now access them and control them in the exact same way via web browser.

Adam Gleeson:

And I think I can remember, again, it’s one of these things where I suddenly realised how old I’m getting, and I can remember the days when it used to be that the mobile applications would be developed using one software package and then the website would do something else. There was never a feature-parity between the two of them. Anyway, I digress. So the long and the short of it is, so why do we need website and application testing? And to my mind, maybe simplistically it’s all software and it’s therefore predominantly made by humans, which means that it’s inherently flawed.

David Dixon:

Yeah, exactly. So I mean, any application is going to have vulnerabilities to a degree. I doubt there are many applications that have been built flawlessly out there. Maybe there are. I’ve never seen one, not that I’ve seen. But yeah, the reasons as to why do we need pen testing, I mean a number of reasons, but I mean assurance and peace of mind. If you’re a business or organisation that provides an application, particularly if you are working in the e-commerce sector, you want to make sure that that application is secure, that it’s not going to effectively knock your business offline in the event of a cyber attack. You also want to provide assurance to stakeholders, partners, and ultimately probably most importantly customers that their data is secure and is always being protected. And then there’s also compliance reasons as well. There’s multiple legislations out there such as GDPR, and depending on what region that you operate in, countries might have their own privacy laws and you have to comply to. So, there’s a number of different reasons really.

Adam Gleeson:

And at the end of the day, these things, these websites and these web applications in particular, they’re internet facing all of the time. So, they’re constantly exposed. So, they’re probably very easy targets to an attacker, I’d imagine.

David Dixon:

Oh yeah, absolutely. And particularly if you are a company that works in retail or you provide an e-commerce platform, they’re particularly attractive targets to cyber criminals for a number of reasons. But typically for the data that they hold, there’s a lot of sense personal data there. There’s potentially payment information, so like credit card debit details.

Adam Gleeson:

The crown jewels in that instance are very, very close to well logically that they seem very close to the surface of where an attacker could actually go.

David Dixon:

Absolutely. And it’s not just data as well, but sometimes the accounts themselves are lucrative to hackers and cyber criminals. There’s an evergreen market on the dark web for not just stolen credit card details, but also in effect stolen accounts as well. So, for example, if you wanted to just make payments through someone’s account or change their details, so products or things got shipped to yourself, for example, stolen credentials is a vast market on things like the dark web. So yeah, there’s a tonne of different motives really.

Adam Gleeson:

It’s both endlessly fascinating and terrifying at the same time. The amount of stuff that is out there now. So, you mentioned e-commerce, and that’s something that we’ve been looking at internally in cyber lab as well. Anyway, so going back to what we were saying around that, the crown jewels are located quite close to the surface of the website, but also the types of threats increase all the time. They, I think I’ve mentioned this on pretty much every podcast that we do, that cyber threats are increasing all of the time. Without going into too much technical detail, what kinds of threats do we face when it comes to web applications? So, when we’re talking about testing these things and securing them, what is it that we’re trying to secure them from?

David Dixon:

Yeah, I mean, well there are dozens if not hundreds of prevalent vulnerabilities facing web applications and not just applications but APIs as well. However, best way to summarise what are the most common vulnerabilities would be to look at the OWASP Top 10. So, I think the acronym is the Open Worldwide Application Security Project, which is an open source. Anybody can log on, go online and find this list. But it’s basically an open-source list that is regularly updated with the most top 10 common and prevalent vulnerabilities facing any public web applications.

Adam Gleeson:

So that’s probably a good starting point this start to get an idea about what the types of threats are there. And again, when we’re talking about e-commerce, if a hacker was able to take an e-commerce platform down and certainly the likes of Microsoft where that’s like most of their business, unless the organisation has an enterprise agreement directly with Microsoft, then businesses are consuming these things through e-commerce predominantly, aren’t they?

David Dixon:

Yeah, absolutely. And also as well, it’s not just about protecting your data, like I said, there’s risks there for availability and operational resilience. Hackers might be using vulnerabilities that exist in the web app itself to try and take down the application or steal data, but also as well, they might execute things like DDoS attacks to try and flood the application with so much traffic that the server can’t cope.

Adam Gleeson:

And then that has an impact on the actual business as well.

David Dixon:

A hundred percent, yeah, you can imagine, I’m trying to think of a good example. Like a company like Amazon that requires 24/7 global availabilities, the largest e-commerce platform on the planet. You can imagine the financial damage that would be incurred from just a couple of hours of downtime. They’d be talking tens if not hundreds of millions to try to by the time it takes to recover and get the service back up online. So having service availability and making sure that there aren’t any vulnerabilities that could disrupt or even take the application offline in its entirety is also just as crucial.

Adam Gleeson:

And then also if there was data breaches and stuff like that, there was one I remember that we were talking about previously, major cart, that was an attack against British Airways, I believe.

David Dixon:

Yeah, absolutely. Yeah. So, some people might remember this in the news from a few years ago. I can’t remember the exact year now, but I think it was one of their customer facing mobile applications which was compromised and effectively it costs British Airways, something in the vicinity of 70 million, or no, sorry, £20 million in fines as a result for a GDPR breach. And this is just a perfect example of how not taking security seriously enough or not being able to demonstrate to bodies like the ICO who are the ones that basically…

Adam Gleeson:

-and that was a direct result of a web app?

David Dixon:

Yeah, it was web app compromise for sure. And it costs, there was two million of users records compromised and obviously as a result they suffered a financial penalty.

Adam Gleeson:

So, I mean all of these different things we’ve talked about quite a bit there, but this is really why we need the website and the application testing one, the fact that it’s made by humans, so there are going to be flaws in it, unfortunately. And people doing bug bounces and things like that as well as the malicious hackers looking to exploit it. E-commerce is a big driver in business at the moment, and then the number of threats is increasing exponentially, as we say every episode. And then the knock on effect with someone like British Airways especially, it’s going to have, not only have they incurred fines from the data protection, they will have made losses through downtime. They will have lost trust and loyalty within their customer base as well.

David Dixon:

And probably what’s quite common and what you see is a trend in behaviour following a cyber incident, particularly of a public traded company, is that their stocks might drop, people might not trust the company as much, so they might withdraw their investments from that company. I mean it doesn’t happen all the time, but depending on how severe that breach is and also kind of how the company handles that incident handles the fallout can really have a reputational effect on their share price basically.

Adam Gleeson:

So that sort of in a nutshell covers why we should be doing this testing. Now, what does website and API security testing actually mean? And I think before we go too much further, let’s just consider what the differences between website security testing and API security testing. Can you tell us a little bit more about that?

David Dixon:

Yeah, sure, I can try. So website or web application testing typically is looking for vulnerabilities on the user interface. So think about the application front end, and there are two different, well, there are different types of testing that you can do. There’s what we CyberLab would call unauthenticated versus authenticated,

Adam Gleeson:

Ok.

David Dixon:

That’s basically unauthenticated is trying to hack the application or look for vulnerabilities without any user credentials or logging in.

Adam Gleeson:

-so just starting with a blank slate?

David Dixon:

Yeah, imagine a hacker’s approach who hasn’t got any leverage or any credentials to log in. They’re just looking for any kind of low hanging fruit as it were. And then authenticated is the kind of opposite of that where we are looking for vulnerabilities from the perspective of a logged in authenticated user.

Adam Gleeson:

Do you think that there’s perhaps less of a focus on the security of things once someone’s logged in? Do people tend to think, well, it’s behind the authentication, there’s kind of like the authentication is going to block, so if they’ve already authenticated, then we don’t need to be as secure once they’ve authentic?

David Dixon:

I think it probably depends on the application and the industry that it’s in some kind of apps that aren’t deemed as likely targets or as attractive targets, maybe they don’t feel like there’s much of a risk. So maybe you’re right, they feel like as long as they’ve got a sufficient login screen with sufficient authentication protocols like 2FA or signal sign or something like that, then there’s probably not as much emphasis on what risks are behind the one to user logs. It logs in. However, think about open banking apps for example, or if you log into your bank account online, then absolutely they’re going to need to make sure you as a customer want to know that there are no vulnerabilities there. Absolutely. Also not just through GDPR, but things like FCA regulation and there’s a myriad of specific requirements for the finance sector in general that they have to apply to that if an application wasn’t secure enough, even past the login and authentication process, that those companies would be in serious trouble because of inadequate security and following best practises. However, so going back to what’s the differences between web app testing and API testing. So application testing, it really depends how granular that test is going. Like I said, it can just be from an authenticated approach, but ultimately you’re looking at the overall functionality, potentially the codebase and also the business logic, the overall functionality of the application and including the backend components. With API testing, API testing isn’t typically looking for vulnerabilities of any exposed endpoints that website or application will use. So think about the best way to think about it is not just can malicious actors exploit vulnerabilities on the application front end, but can they get access to data that’s being communicated by the APIs, for example, or can they manipulate functions that the API endpoints use?

Adam Gleeson:

So that’s how, trying to pretend like they they’re a genuine thing.

David Dixon:

Yeah, exactly. Yeah. So a good example of that is the company Peloton, which was the home workout outlet, which kind of blew up during lockdown. They suffered a breach I think in 2021 where the hackers were able to exploit a vulnerability in one of their APIs that will basically enable any user to request data without prior authorization or authentication. So basically just hijacking the authentication process.

Adam Gleeson:

Right. Okay. So essentially sending via, before all we air on, I’m just conscious we haven’t actually explained what an API is now. I think most people watching probably will know what an API stands for: Application Programme Interface. And it’s a mechanism by which we can have integrations between disparate applications and allow them to communicate securely behind the scenes.

David Dixon:

Yeah, it is effectively an application can’t run without an API the best. Effectively it is what an API is being used to request or pull data that any user might be either uploading or requesting via the app frontend or like you say, it might be used to communicate with other services or other applications to again, pull data or edit or data and so on. It’s effectively the backbone of an application really.

Adam Gleeson:

So going back to just before I took us off at a tangent there, we were talking around the Peloton breach and the fact that someone was able to pose and pretend that they were an application requesting information via an API.

David Dixon:

Yeah, I think it was more that. So basically, so when a user logs in and then sort of authenticates that it’s using an API, sort of like what you might call A JSO web token for example. I’m not sure if that’s what was used specifically in this case, but that’s what tells basically the backend that the users who they say they are basically that they’re, so that’s kind of what the prior authorization authentication is because of a vulnerability that was present in Pelotons API hackers were able to exploit that so they could circumvent that authentication process and effectively get access to any user account data. And that data included I so names, addresses, telephone numbers, and also in some cases location data as well and also the user fitness data as well. But that might not be as sensitive.

Adam Gleeson:

It seems to be these days that all data is of interest to someone to some degree, someone is able to monetize it or get something out of it. It drives me mad. It really annoys me that they’re getting money for my information and it should be me that’s getting money for my information.

David Dixon:

Listen, well, this is the reason why it’s so important to test APIs and indeed applications equally.

Adam Gleeson:

So just to sort of sum that up and the website testing and the web app testing is really testing the front end, the typical things that we’re looking at there are possibly SQL or LDAP injection. Now I don’t want to go into too much technical detail because, because I’m going to get out of my depth. I’ve got a routine, I’ve got enough knowledge to be dangerous, but I’m by no means a specialist on it. Cross site scripting is another common flaw that gets left in there. And one that you mentioned was broken access controls.

David Dixon:

Yeah.

Adam Gleeson:

Can you elaborate on that a little bit?

David Dixon:

Yeah, so this is actually probably surprisingly to some people that it’s actually the most common vulnerability in the OWASP Top 10 that we mentioned earlier. And I think it’s remained the most common vulnerability for a number of years now. I don’t think the OWASP has been updated in about two or so years. I could be wrong, but I do know that broken access controls has been pretty much number two and number one for a good few years. And ultimately broken access controls is pretty much what it sounds like. It’s just misconfigurations in the authorization or authentication process, not having sufficient limitations or segregation in terms of user access privileges. So for example, if an application has different tiers of users that should be able to access different things that broken access controls can be exploited so that a user might be able to escalate their privileges to that say of an admin. And quite often, and I said this is the most common thing, so it’s not so much like a code base or really technical vulnerability.

Adam Gleeson:

That strikes me very much with my old administrator hat on. When you were setting up domain policies and things like that, if you weren’t aware of these particular security settings, you just, if you didn’t, you wouldn’t know. They wouldn’t know that they were there. Exactly. Yeah. And some of these things would mean that some of the other controls that you’ve put in place wouldn’t actually be enabled or wouldn’t be active unless you’ve configured something somewhere else.

David Dixon:

Exactly that.

Adam Gleeson:

These things have been ironed out over the years, but-

David Dixon:

-I think it’s always a constant kind of effort to make sure that these vulnerabilities aren’t present or if they are, that they’re remediated following better practises. Because like you say, applications are inherently flawed. So even though people and generally people are aware of them, there are still plenty of people that aren’t depending on how they develop applications, might create vulnerabilities along the way that previously weren’t there, but then have been introduced since. And it really ultimately comes down to your cyber security strategy and at what point do you embed security into the development life cycle.

Adam Gleeson:

Absolutely. Yeah.

David Dixon:

I think a really good point to kind of segue into there is follow best practises framework is the best sort of advice I can give to application security and being able to sleep at night.

Adam Gleeson:

So moving on, how do we actually go about doing web application security? So let’s talk around the frameworks first of all, and then we’ll come back to the more traditional approach of code reviews and penetration testing in particular. So OWASP, we’ve talked about that before. This is typically offers you the top 10. It’s a really easy way to gain visibility into what most common things.

David Dixon:

And it’s not just a list of the top 10. There are tools and documentation there to help you out so you can look for those things yourself. However, being a cyber security expert is expensive. Say if you were to look at doing your own testing entirely and just doing that all in-house, you’re looking at potentially high cost and resource issues. There is skill shortages in the cyber security market. So that means that resources are more expensive.

Adam Gleeson:

This is one of these things that I come back to and it’s like getting anything done. I mean, I had the light bulbs change in my car. I was just being lazy this morning that when I was in Halford’s I just said, how much is it to do these? And he said, it’s five pound for each bulb. And I was like, I’ll just go ahead.

David Dixon:

But then you know that they’re done by an expert.

Adam Gleeson:

Rather, I could do it, but I wouldn’t be able to do it in the same amount of time.

David Dixon:

And also as well, if you do something and something goes awry, then you are responsible for it.

Adam Gleeson:

I wasn’t going to say that because I wasn’t going to insinuate that I get things wrong but yes, there have been instances where the rubber cover gets dropped down into a part of the engine that my large hands won’t actually fit in. Exactly.

David Dixon:

And I think it’s just a peace of mind that it’s being taken care of by an accredited expert. So I think as a baseline, most pen test providers should be CREST-accredited. So if you are looking for a cyber security partner, I would definitely look to see if they are CREST-accredited. That’s kind of a globally recognised gold standard with regards to pen testing. So if they are at that level, then you’ve got peace of mind that they’re going to do a good job basically. So engaging cyber security partners that’s CREST accredited, you’ve got peace of mind that they’re going to follow a set process and methodology and that also they’re going to handle any sensitive assets in a secure manner and compliant manner as well. But also as well, sometimes it’s necessary for compliance and regulatory requirements that you can’t just do mark your own homework.

Adam Gleeson:

No, I think cyber security and getting these things right is so important. It’s like would I go as a completely unqualified mechanical engineer or mechanic or anything like that? Would I want to mess around with the brakes on my car? Probably not.

David Dixon:

Yeah, exactly. Or go and see a doctor if you had a specific illness or a condition or something that was wrong with you, would you want self-treat and diagnose or would you want that specialist? This is very true. This is very true to be able to triage and take care of you. There’s a number of huge benefits to outsourcing pen testing I think. But then also beyond pen testing also you can follow frameworks like SDLC, which is a Secure Development Life Cycle, which is again, kind of what it sounds like. So every application will have a development life cycle. Security is basically embedding that into every step of that process from sort of inception to completion.

Adam Gleeson:

Rather than the mill traditional approach of like, well, we didn’t really think about cyber security in the first place. We were just trying to be, so now we’ve built the product and now we need to secure it. And it means that you are then trying to retroactively reverse engineer the product or to do things like that rather than it being built into it.

David Dixon:

Exactly. And you can imagine the headaches that would cause a lot of departments, it would also cost a lot of money potentially, and it could even potentially delay the project time. So if you are working to tight deadlines to get something to production and you’ve had a seamless development life cycle, and then you’ve got to the point of, okay, now we test it and you find out the application is full of holes, now you’ve got to go back 10 steps and potentially rip it all out.

Adam Gleeson:

That doesn’t sound like fun and I can’t imagine, think you’d be very popular either.

David Dixon:

But I think SDLC is becoming a much more common approach now to application development. I think. And again, it’s something that you as an organisation can be directly in control of. You can decide how much emphasis and how much import gets into testing iterations of the application throughout the process. And then you’ve just got that peace of mind then that even if there are any kind of changes you have to make, they’re more than likely going to be less stressful and require less resource and costs at the end.

Adam Gleeson:

Just to loop back to pen testing, obviously what you do, a lot of you do the presales, a lot of on penetration testing and you mentioned CREST. There’s Also CHECK certification. What’s the difference? Because I can remember a few years back when I did a little bit of pen testing training as part of my role as a cyber essentials assessor and CREST was quite a well regarded sort of standard at that point. Now it’s not the case that it isn’t well regarded, but it seems to be quite to a penny nowadays. Lots and lots of people have that, whereas CHECK is a lot more specific or a lot more.

David Dixon:

Yeah, it is. So the best way to think about the two is CHECK is typically a regulatory requirement for anything public sector or to do with kind of defence. So it’s a requirement for any projects that might involve kind of handling any official sensitive data or might be dealing with applications or infrastructure, any technologies that are either directly in use by say government or emergency services or provisioned by private companies into those industries. So CREST is just a global standard. There isn’t typically any legal requirements that I can think of where CREST is mandated, but it is just kind of like if you have CREST, then you are deemed-

Adam Gleeson:

I think I would imagine that if I had a need and I was looking at someone-

David Dixon:

You wouldn’t request CREST. Yeah, absolutely. We get that a lot in tenders. So we get that as a baseline CREST and CHECK also depended if they’re public sector, but usually as a minimum we always see CREST as a minimum requirement. So

Adam Gleeson:

You mentioned just before about CREST certification. Is this a recognised standard? Yeah, exactly. Methodology for penetrate testing.

David Dixon:

It’s more of like a globally recognised rubber standard if you like. It is a gold standard for all cyber security disciplines and services really. And that does include pen testing of all kinds. So CyberLab for example, we are a CREST certified company for penetration testing services and security consulting, but we’re also CHECK Greenlight certified as well. So for anybody who’s not sure what CHECK is or what the difference between CREST and C CHECK, so CREST is, again, it’s not something that’s run by any kind of government entity. It is just kind of its own independent body that certifies security providers or IT service providers. And CHECK is a scheme run by the NCSC, the National Cyber Security Centre. And that is specifically for testing requirements that are involved in typically the public sector or defence or military or kind of anything that under that kind of level. And typically CHECK is required where there might be infrastructure technologies or applications that handle official sensitive data, all might have access to sensitive assets. So for example, councils, local government and emergency services will have access to what’s called the public sector network. So anything to do with that has to be tested under a CHECK scheme. It will be a nice to have, if you are, you’re a pen test provider and you’re not CHECK certified, you legally cannot deliver that work. It doesn’t necessarily mean there’s a change in how they would conduct the pen test. It’s not like a different methodology. It’s more around the security clearance and the data handling.

Adam Gleeson:

That’s what I was going to say because that was one of the things that the came not as a surprise as such, but it was something that I hadn’t really considered properly. It was around after we’ve done a penetration test, that information is incredibly sensitive.

David Dixon:

Oh, absolutely.

Adam Gleeson:

Yeah. If a hacker was to get hold of that, then that’s kind of given them almost a road treasure into that customer’s environment.

David Dixon:

Absolutely. Or they could just look to see what the critical or high vulnerabilities in that report was and then just focus on that. So yeah, you’re absolutely right. Not just for CHECK work, but for any pen test work, any security consulting that produces a report out of the back end of that is absolutely sensitive. And that’s why we have very, very strict processes and policies when handling that information and when we’re delegating the reports to the client once the test has been completed. So we never share anything like that over email. Of course, we always have a designated points of contact, it’s always deemed client confidential. So the report is, it can’t just be shared willy-nilly with you, whoever, even within the client’s organisation, it can only be accessed by specific sort of individuals.

And we also use a secure file upload repository as well. So anything that for report or supplementary information to do with that pen test is all stored securely and safely. And then by policy we delete those records after a certain amount of time as well for data retention policies and compliance.

Adam Gleeson:

Excellent. I think we’ve actually run out of time. I’m afraid that’s a shame.

It’s one of these things is endlessly fascinating and you constantly uncovered different things that you maybe hadn’t considered or you hadn’t looked at it from a certain point of view. I think in summary, really, if you have web apps, if you have websites, you need to make sure that you’re testing these things just to make sure that you’re protecting yourself. Because typically when I mean penetration testing, I tend to think in terms of firewalls and network perimeters, things like that. And maybe not necessarily thinking about the web applications or even mobile applications. I would imagine that it could be extended to that as well. Yeah, absolutely. So it’s absolutely something that you need to be doing and it’s something that you need to be doing well and using someone like CREST or Czech certified organisations is probably some safe advice to follow. So thank you very much, David. Thank you. Thanks for having me. Hope that this was interesting to the people watching. And I’ll be back next time with another set of tales from the CyberLab. Stay secure.