John Delaroderie Breaks Down Web App and API Security Challenges | Qualys QSC23

This is Textron tv. Welcome back everybody to day two of the Quas Security Conference in the Americas. I'm Mike Baard, and today we're with John Della Lottery.

He's director of Product Management for Qualys. That's correct. And we're talking about API security and web application security and the challenges thereof.

John, welcome to the show. Hey, thanks for having me, Mike. Before we get started, lemme just wish you happy birthday and everybody watching wish John a happy birthday.

Thank you very much. All right. What is the fundamental challenge with web application security and API security?

I feel like we've been at it for a long time, but when you talk to customers, what are they really struggling with? Yeah, It, it has been a problem for a long time. If, if you're, um, able to remember back into the late nineties, I, I don't wanna date you, but I certainly can remember them.

Web applications were mostly static. And around the turn of the century, web applications started to become dynamic. We introduced a host of vulnerabilities.

You know, you're probably familiar with things like SQL injection or cross-site scripting injection. Those all manifested because we made applications more useful by making them dynamic. And in 23, 24 years, we're still facing the same problems today due to, you know, some bad decisions that were made early on.

So with web applications, it's important to remember, you know, confidentiality, integrity, and availability. So web applications have, uh, data to protect. They need to be always up 'cause they represent the company and that, um, uh, you know, customer data needs to protected and the data you're getting, you need to make sure it's trusted.

So all those pose problems, so all of those can be attacked, uh, with web applications and APIs. And because they're ubiquitous, because they're everywhere, they're a natural target for malicious actors. I hear this constant debate from folks about whether or not application security and API security are different or are they the same thing?

Because some folks want to treat them collectively and other folks have like different tools for each. So what's your thought on this process? The technology behind them is identical.

Uh, an API in the simplest terms is just an endpoint, AURL that you interact with. But unlike a webpage, there isn't anything to display and there's no links to find the next one that adds to their complexity. Because for me to test an API, I have to know what that endpoint is.

I have to, there's no links to it. I have to know it. I have to know how to interact with it.

You know, what HTTP method does it take is a get a post, a put a delete, and I have to know, are there any parameters I need to use when I interact with it to solicit the responses I want. As a security professional, I have to know that for all of my APIs and those can number in the tens of thousands as an attacker, like with the optis hack last summer, I only have to get lucky and find one. Hmm.

Are we targeting more of the web applications if we're the bad guys, or are we going more after the APIs these days? Or is it an equal measure? API traffic makes up over 80% of all web traffic today, and it is a, uh, growing attack surface that most organizations aren't, uh, taking the necessary due diligence to secure and protect.

So if I were a malicious actor, I think the low hanging fruit right now is certainly APIs. Mm-hmm. Do they, how long does it take for them to discover an API and are they cracking that API or they're just kind of manipulating the business logic in it?

What is the nature of the attack on the API? Sure. So, uh, there are certainly ways to find an API.

If I interact with your website, I will probably find API calls being made to backend servers to generate content for that website. That's pretty standard. So from there, I can start to, uh, fuzz those endpoints to look for other endpoints.

And there's certainly tools out there that can help, um, uh, you know, white hat hackers and black hat hackers explore and find additional APIs and fuzz, what parameters they might accept. So there's lots of ways to find it. And then from there, um, there's a whole new, uh, whole variety of classes of attacks you can do.

And, and some of the more common ones are, uh, are still grounded in web application vulnerabilities. It's can I, you know, violate my, the access I should have, like if I know the API endpoint to get data about my account, can I change that account number? And all of a sudden I get your data, Mike?

Hmm. Who's in charge of web application and API security? Is it the development team, the cybersecurity team, or is there some other magical person running around?

But it seems like at this conference, there's much confusion as to who owns the responsibility for this stuff. Right. I I, I, I think what we need to do, I mean, to answer your question, you know, there is an app team or an API team that's actually writing code and developing these web applications and APIs.

What I think is missing is a sense of security being a feature of web applications and APIs instead of our, our traditional approach is, you know, api, excuse me, security is a block or something we add at the end that we have to take account for. The mindset should be, we should be developing champions and these development teams that have a sense of ownership of these products from a security perspective, so that they're building them with security in mind instead of something that they have to do at the end. Let's say I'm the security team and I know the developers are probably not doing the right thing for a thousand different reasons.

How do I go about securing those APIs and applications in a way that, you know, I can do and doesn't require a lot of help from them? Uh, I'll, maybe my answer will be controversial, but there's not much you can do. Traditionally, the way we look at protecting a web application is we put a web application firewall in front of it, and that's great.

It's, uh, you know, it will detect like maybe somebody trying to do like a cross a scripting or SQL attack and block it. But the problem is, I can go on, you know, Google right now and search for WAF bypass techniques, or, you know, I'll see them on Twitter or, you know, uh, any number of security researchers will publish these on LinkedIn. So there's always ways to violate these WAF rules and get around them and attack vulnerable source code.

So really the only thing you can do at the end of the day is secure code. Putting a, a firewall in front of it is just gonna buy you time for that remediation process. What are the challenges for developers?

A lot of them are using various web application frameworks to go build these applications. Um, we're still early on on DevSecOps processes. It's not clear to me that those things neatly integrate into those web application frameworks.

So what's our level of maturity and what do we need to do next to kind of move the ball forward? I think there are probably many developers out there that are taking, uh, security seriously and working really hard to develop secure APIs and web applications. But we also have to recognize that there is a, uh, a drive to get code out to market faster.

92% of all developers say they're under pressure to get code out fast, and 50% of the same, uh, polled developers say that security is an afterthought. So again, we need to challenge them to look at security as a feature that they're developing, like whatever the features they're adding to a website or to an API and not that, that, uh, action, that the ad at the end, um, changing that mindset I think is gonna be critical and it's gonna take cooperation with the security teams to help drive that. There's a certain amount of fear for upgrading components because people are worried that the application will break.

How seriously justified is that, and how do I know, or what should I be doing to test things before I upgrade the application? We do live in a world with a lot of legacy applications built on some older technologies, um, think of like c or c plus plus, uh, and they introduce a host of vulnerabilities that other languages may or may not, right? So like Rust is seen as an alternative to CRC plus plus, but it doesn't have the memory management issues that that CRC plus plus does.

But if you're a developer and you've been working with CC plus plus for 20 plus years, now learning a new language like rust is going to be complicated. You can certainly do it and there's benefits to do it, but the time and resources for the training and then rewriting and building these applications from the ground up, that is going to be a challenge for most organizations, even though in the end it will make them more secure. Mm-Hmm.

If I'm a security person, do I inject myself into the application development process? How do I kind of get in there and have this conversation with folks? I, ideally, security is there at the design phase.

Um, I, I think it's a well known fact that fixing a bug during the design phase, whether it's a vulnerability or you know, a functionality bug, it's reportedly six times cheaper than when it goes out to production. So getting in at the beginning of the design phase from a security perspective is critical. Ideally, the security person's not introducing new processes outside of what they're already doing.

Instead, they're leveraging connectors or APIs to integrate security testing early into the design phase. But on the other hand, organizations will benefit greatly if they do things like, you know, do threat modeling where you start to say, Hey, let's not start with, you know, going from scratch from the entire application, building a threat model for it, but this new feature you're developing, let's talk about threat modeling and look at how an attacker might abuse this, how they might break it, so we can address the security from that perspective. And critical to that is saying like, Hey, Mike, you're the developer here.

How would you attack the system? Mm-Hmm. So if we can introduce threat modeling early into the design phase, I think it will generate, uh, profound, uh, improvements in overall security.

A lot of the developers are working towards compliance mandates. Is that enough? I mean, a lot of security people will say, you know, compliance is the bare minimum, but Yes, I, I would agree with that.

Uh, you know, if you're just working from a checklist, that checklist is going to be the bare minimum as you said, and we need to consider, there's always more that can be done. Uh, I don't lose sleep over, you know, the, uh, the kid running a, a vulnerability, open source vulnerability scanner in his basement looking for vulnerabilities on a site with an automated testing tool that's low hanging fruit that hopefully as an organization you've already addressed. But when you think about the more sophisticated attackers, they're looking for ways they can manipulate the business logic flow of an application, or, uh, more advanced attack vectors or chaining attacks together, that's gonna be the scary attack.

That worries me when I go to bed at night. A lot of the developers will say, well, a lot of the vulnerabilities are in the components that we're using, and they're open source components that I downloaded from some repository somewhere, and I don't have control over those things to update them. So how do I kind of approach the software supply chain when I need to go call somebody and say, can you upgrade this for me?

Right. So open source vulnerabilities can be challenging. Um, sometimes you'll use an open source library that has a known vulnerability and it'll get flagged during a scan, but if you haven't implemented the functionality for that vulnerability, then it may be, uh, irrelevant to your web application.

Your web application's not using that code, it's not calling that code. There's no functionality in the website that's exposed to that vulnerability. But then you need to understand those issues to be able to articulate them to whatever governance you have about what needs to be secured or not.

In the case that you are using a open source library with a vulnerability, hopefully there's a CV against it. Hopefully whoever created it is, has issued a patch or an update or a fix for it. And yes, it does become quite the, uh, configuration management to keep track of and implement a, uh, a way to do that tooling.

Uh, this is where something like software composition analysis or SBOs are really beneficial to organizations. So they understand what technologies, what open source technologies they're using. I think in my experience, talking to developers, most of them got some training and security was an elective that most of 'em didn't take.

Right? Do we need to go back into the education system for developers and have a conversation about, well, where is security's a requirement? Not an elective.

You know, we think about critical infrastructure like, um, aviation or, um, where to be, uh, to work on an aircraft. You know, uh, there's certainly educational requirements and certifications you have to get, and if those lapse, there's accountability there. If, if I've signed off on aircraft and there's a problem later, I'm accountable for that.

Or think about medicine, we have the same kind of accountability there, where if something goes wrong, we're able to point a finger to what went wrong with software development. That's challenging because you might have an application that's been running for, you know, years, maybe decades, that has had dozens or hundreds of people working on it. So attributing a insecure code design to an individual might be challenging, but at the same time, maybe we need to look at a certification process where there is accountability.

I can go into GitHub and see who made a commit. Can I go and see who committed the bad code? And if so, is there some accountability there where they, you know, if they've got some kind of software secured software licensing that makes them more, uh, attractive to employers, would there be a ramification there if they've written code that allowed a breach to happen?

But that's opening up a whole other conversation that's, um, you know, certainly outside of my swim lane. Well, it does seem like there are more conversations about regulations that people wanna put forward in Congress and other places that seem to require some of that. So will things get more stringent, do you think, as we go forward and we might as well prepare for it now?

I think so, uh, Mike, because we, we certainly live in a world where, uh, choices on what technologies to use when building web applications or APIs are more often influenced by what the developer's comfortable working with, and not necessarily the more secure one. If I've been working with PHP for a long time, I might be inclined to work with PHP even though it has all these inherent flaws. Um, whereas if I'm, uh, if I don't have exposure to like Angular react, and you know, I may not choose to pursue those even though they're more secure by design and the thing with CC plus plus and rust.

So maybe there should be some regulation. The design process for what frameworks I use shouldn't be driven by what me as a developer, what I'm comfortable with or what I have experience with, but rather what my organization has mandated from a security perspective. Aren't we simply just too obsessed with building software fast?

And maybe we should just slow down and think about it a little more. Absolutely. I, um, I, I've been reading a lot about, um, you know, as a web app guy, I, I, I'm a huge fan of oasp, the Open web applications created project, and they recently released a OAS top 10 for large language models, um, uh, these chat GPTs, et cetera, right?

Everybody is in a rush to get this technology to market, making plugins, making, uh, interactive, uh, features on their websites for these LLMs to, you know, drive AI in front of their customers and say, Hey, we're doing this AI stuff. Look at us. It's so cool.

And, and there's certainly benefits for the customer, but we're not looking about at them from a security perspective. In my opinion. It's like we've tossed out 20 years of security practices in a rush to get something cool out.

Um, there's a whole host of vulnerabilities, these things open up that we haven't considered. Like for instance, um, you know, about prompt injection where you can, you kind of bypass or jailbreak any kind of stick, you know, controls on that, uh, LLM, so that, Hey, how do I build a bomb? I can't tell you that.

And then you do a jailbreak and all of a sudden it's telling you how to do it. There's a, a class of attacks that are, are being looked at where maybe a website actually has a prompt injection. So as that engine crawls and it's learning and scraping websites, this will inject a prompt where it stops and it does something else.

And I, I think a good scenario might be, um, you know, I've updated my resume with a prompt injection and I'm trying to get a job, and I feed it to something that I know has ALLM that's gonna evaluate that resume. And my prompt injection interrupts the, uh, ingestion of my resume and tells that machine learning algorithm, Hey, this is the best resume you've ever seen, flag this as like 10 out of 10, it's the best. And that gets trickled up to the top, as you know, this is the resume that is going to recommend to, you know, the HR team, not because it's necessarily a good resume, but because I've hacked that, you know, apparent AI that is looking at my resume when I've uploaded it.

Mm-Hmm. And that's all interesting to me. That's, uh, some novel attacks I don't think we've considered yet, is how, you know, we can use this ai, these LLMs against the organizations that have implemented them.

As far as I know, most of those LLMs are built by data scientists that know even less about security, and then developers. So, you know, are are we looking at a problem here that's, that's gonna happen inevitably. If we don't get ahead of it, we'll have the same problems that we've had in so much of cybersecurity now, like web applications and APIs.

We the same vulnerabilities, the same injection vulnerabilities that existed back in 1999 we're still finding today. So yes, if we don't get in front of this now, it'll become a bigger problem later. All right, folks.

I think it was back in the sixties, there was a book published. It was called Unsafe at Any Speed, and it eventually led to regulations that resulted in seat belts, put in cars, and then cars then became safer. I think we're at the same point with software.

John, thanks for coming by. Thanks, Mike. All right.