A Better Way to Pentest for APIs

00:04 Hello, everyone. I'm Katy Nally. I work in product marketing here at Synack. Welcome to A Better Way to Pentest for APIs, the Synack webinar. Before we hand things off to the speakers, a few rules of thumb. Please feel free to ask questions at any point throughout the presentation. There will be experts behind the scenes to provide answers. If you want to speak with someone from Synack directly, you can reach us through our website or by requesting a meeting or demo through the navigation bar at the bottom of your screen. Lastly, if you'd like to revisit the content presented,

00:35 you can use your email and unique URL to access the webinar on demand. Thank you again for joining us and now I'll turn it over to Mark to introduce the agenda. Hi there, my name is Mark Kuhr. I'm the co-founder and CTO here at Synack. Thank you for joining us today on our API webinar. Today we're going to start with a brief introduction about API definitions, get everybody level set on what is an API. We're going to talk about where API solutions fall short.

01:05 Then we're going to jump into where offensive testing can play a role in finding the most exploitable vulnerabilities in your API stack, and then go from there into how to overall reduce risk. And today we also brought in a guest named Chris Rodriguez from Sabre. Really great to have you today, Chris. Thank you so much for your time on the webinar and we look forward to hearing about your experiences in the land of API security. Yeah, absolutely. Happy to be here.

01:41 Chris, would you like to go ahead and introduce yourself along with telling us a little bit about, API security breaches? Yeah. So my name is Chris Rodriguez. Like they said, I'm the manager of application security over at Sabre. And so for those of you guys who don't know, Sabre is like the glue between travel agents and hotels, airlines or rental cars, anything that involves travel. And so anytime you go to a conference or you know, for business, that's kind of the revenue and business that we're into.

02:14 And so, what we're doing here is we're trying to discuss and bring to light the types of importance of security around API penetration testing. You know, this is a new topic. Anytime my CISO goes out to a conference, you know, he comes back with questions about API security. And so this is where we're at. And, you know, to get kind of a foundation of who is

02:44 affected by this, just look at the list that we have here. This list shows known exploits done by bad actors to big companies. You know, every size is affected by this and you know, we just have a few here, but you can think about, you know, T-Mobile had one, Facebook had one. You know, these are gigantic companies, who have great budgets, especially in their security systems. But they're still vulnerable to this type of attack.

03:15 Let's double click on Peloton for a bit. I mean, I was on my Peloton earlier trying to work up a sweat and lose a few pounds. And honestly, I didn't really think of cybersecurity being a part of that ecosystem. But you know, now that you sit back and look at it, it's just a giant computer on a bike. Yeah, exactly. Fascinating. What do you think? You think they're, you know, analyzing their APIs for security vulnerabilities now post breach? Surely. Surely they are, especially because of regulation that

03:46 comes with an actual data breach. But, look at LinkedIn, you know, LinkedIn, how much data is in LinkedIn? You know, anyone who wants to promote themselves or, find a new position or find a candidate that fits their organization's needs, those are on LinkedIn. And so, you know, you almost have to have a profile there. And so all your information and all of

04:16 your interests and things like that, that's just floating around in there. And I think if you have an API that... Everyone has to have an API. Everyone has an API for their systems and what happens is, you have a responsibility to protect that data even through something that's not as, you know, personable as a web application.

04:47 Well, all these companies have large security teams, right? They all spend a lot of time on security, so let's see if we can get into where the gap may have been. I think that, you know, there's certainly a growing need to pentest these APIs. API abuses are increasing, and I think it's mainly due to just the prevalence of APIs, specifically headless APIs that are, you know, conducting transactions that are machine-to-machine, maybe don't get enough scrutiny. And, you know, the prevalence of

05:18 APIs is further a result of just changing architectures for web applications. It's not like we haven't had, you know, service-oriented architectures in the past, but I think the growth of microservices architecture and the popularity of that has led to an explosion of the API footprint. But what do you think Chris? Absolutely. I have to echo that microservices comment because you know, everyone is trying to get out of, you know, traditional data centers.

05:48 They're trying to get their applications into the cloud. For most businesses, that's the most economical. You know, they don't have to maintain those servers. They just pay a service provider like Google or AWS and they're taking advantage of that tech transformation and producing microservices, decoupling those monoliths that they had previously to make it easier to maintain. And I definitely don't blame them. That's what I would do. That's what you know, does. And so and then yeah, go ahead.

06:19 Now Chris, beyond the web applications, I mean there's certainly the things that drive the GUI and we're seeing that, but we're also seeing like a lot of headless applications too, where developers want to expose their data sets. For example, if you're LinkedIn, you may sell a data API to advertisers so that they can target ads better to certain people. It seems like that business-to-business relationship is also important and growing. Have you seen that at Sabre? I mean, is it part of what you guys are doing in your business as well?

06:51 Yeah, of course. So you know, Sabre is basically a business-to-business company and we can't build UIs for every certain component because one, it's not feasible, but two, that's not what you know, the customers or people who are ingesting our information need. They want to ingest that data, manipulate it in some way to fit their needs and then produce it, you know, on their side. And so APIs are the only way to really do that,

07:24 to have that flexibility for your customers. Right. So they can customize their applications based upon the functionality you're providing. So there may be a myriad of use cases that maybe you didn't think of at the time of developing the API that a customer or third party vendor may bring to the table, right? Right, right. And so you know, you have those web apps that hit the APIs but where I think we're seeing a really big increase is the headless APIs that

07:55 have no UI on top that anyone can go and hit and gather that data and present it in the way that best fits them. So I mean we had an explosion of web applications over the last twenty years and web application firewalls became a big security spend item. And so, you know, where are solutions like that falling short when it comes to APIs? I mean, it seems like the technology overlap is tremendous. Yeah, absolutely.

08:25 Existing solutions are not able to keep up with a lot of aspects of APIs. Yeah, so you know, this first bullet here on this slide, risk-based versus compliance-based, you could write a book about how that impacts security, right? You know, every aspect of security. It's almost like, you remember that Marshawn Lynch video where he's... Was he told he had to do an interview for the NFL and all he said was I'm just here so I don't get fined.

08:57 That's essentially what happens with risk-based versus compliance-based. And I think, you know, it's just like a pro tip on how to impact or combat that is you have to educate the business on how to see security as it needs to be baked in instead of stapled on at the end. And so what we do is on my AppSec team, we work with the developers, we do tactical training sessions we

09:28 call Zero to Hero where we teach the ins and outs of security. We try to build that security concept culture and we work with the dev teams on that end and then we have our CISO and our business security officers go from the top and help the teams prioritize with their functional work because ultimately the functionality improvements are what pays the bills, right? And so we help them prioritize that data, that feedback from the vulnerabilities into their

10:00 normal process and we squeeze it from both sides. And that's how we try to fulfill this and try to get back, push away the compliance-based, you have to do this or else type of approach. Right. Well, in compliance-based testing, it doesn't seem to always find as many vulnerabilities as you would expect because it's not very vulnerability-discovery-centric. It's more adherence to standards so you can get your business certification and use that to sell more widgets or whatever.

10:32 But let's talk about the failed automated security checks because there's been a lot of SAST and DAST vendors over the past twenty years as well that you know, they have good solutions that can test for web application vulnerabilities and it seems like the API is a more structured form of communication. So you would think there would be an easier way to test that. It's very structured. We know requests and responses we expect from these APIs. In your mind though, like where are you seeing some of those,

11:03 you know, legacy solutions falling short? Yeah, so that's honestly the best way to explain it. And so think of it this way, we have our web applications and you can create a crawler that crawls through that application, submits forms and everything, right? But with APIs, you know, you have to do everything in a certain order. You have to, you know, complete the requests exactly if you want data to come back with the UI.

11:34 The back end system kind of takes care of that for you. So all you do is submit the forms or click on the pages and you get the data you need. With APIs, you have to know the order. So yes, I know that this data structure only takes, you know, my address. But what addresses will get you the data that you want in order to test the next step? Select your ZIP code, you know, or whatever. The format and the sequence. Yeah, you're absolutely right. Whereas a crawler would take like a random walk approach

12:05 across the application and click and it seems like we're seeing emerging, I think of QA test harnesses and security solutions coming together where QA teams, quality assurance teams are building very targeted checks to make sure that the APIs are functional and they're providing that functional level of testing. But perhaps the edge cases, fuzzing of the APIs is something that's not present in current tooling. And so I think that ability to launch an API

12:42 security test and ensure that every aspect of the API has been tested —every request type, every variant of a specific request has been tested—I think is a major advantage and we'll talk more about our thoughts on that as well. But, you know, moving beyond that, I think the dynamic APIs, I mean, just the rate of change in these APIs is immense. Development teams are even more distributed now and you know, they're pushing changes constantly and it doesn't seem like security or even QA teams in some cases can

13:16 keep up with the rate of change. Right, absolutely. You'll be surprised how, you know, how many people have such a small security section in their unit tests or their regression tests for their QA teams, right? But it's even harder whenever those APIs are changing constantly. And you know, what you can do is build it as you go, you know, and that's what we tried to do over at Sabre is try

13:47 to hook it in at the time of development. We try to bottleneck that technical debt and so that these dynamic APIs don't just get out of control with the new features and functionalities that come in. Yeah, that's a really important point. I think having good change control processes is the missing layer here. But even that, you know, the ability to flex with your staffing, it's a challenge.

14:17 I think it touches on the collaboration point here where, you know, it's just a it's an unknown to security teams sometimes when those developers make changes and even if they're told when changes are coming out, sometimes they're too numerous to keep up with, you know, given all the other things going on in security teams, it's it's a very hard problem for organizations, especially larger ones to solve. Or just take for instance, the example of decoupling your monolith into microservices. You know, the underlying

14:48 business that you're trying to solve doesn't change, right? It's just what's in the back. But to someone who wants to test that, it changes vastly. And how do you document that? How do you, communicate that to everybody? You need to be very careful about, not forgetting about the new things that you've created because those things need to be tested as well. Yeah, that's a really good point. I think there's a lot of different use cases that don't get shared internally. And then if you have a public-facing API where you

15:19 have users constantly consuming changes, you actually have to support all the previous versions of the API as well, which presents another challenge. How do you keep track of all these changes from version to version? It seems like an explosion, you know, exponential problem set. Yeah, it absolutely is. You know, defensive tooling, you know, the scanning solutions, I mean we've talked about how some of them are falling short. You know, I think offensive security can play a role here. You know, what I mean by that is really talented pentesters coming in

15:53 and trying to knock over these APIs and steal data. If you look at, you know, the Peloton case or the LinkedIn case, I think a lot of those vulnerabilities could have been found by a determined team. The trick is how do you marry that pentester workflow, going in and finding those exploitable vulnerabilities with the rate of change, of the APIs and these other things around poor collaboration and the dynamic nature of it. I think it presents a very difficult problem for most businesses. How have you guys thought about integrating your offensive team

16:26 into this? Yeah, so, you know, I think we're at a good place with our defensive security. It's everybody is, you know, on the same page that it needs to be done. The offensive security is also something so we've done what's called Hack Yourself First. This is a training session. I didn't coin the phrase. It was Troy Hunt, the guy who manages haveibeenpwned.com.

16:59 But the idea is teach your dev teams and QAs how to do mini penetration tests on their applications, using the same tools that bad actors would like Burp Suite or you know, just command line applications. And this type of learning means that you don't have to put an AppSec person on each dev team. You're creating that security champion for each team. You're planting that seed and then that seed of security just

17:31 grows throughout the entire dev team and eventually the organization. And that's that's how we've really started using the offensive security. And of course we have, you know, Synack that we leverage for a majority of it, but we're trying to go, like I said, we always try to squeeze it from both ends. And so if dev teams are finding their own vulnerabilities, that means that the ones that are really hard to find are going to be found by the experts at Synack. That's right. Yeah, that's a good point. You want to build that capability onto your teams and decentralize security as much as possible.

18:03 I think that can apply to just about any problem in security, where you're just if you do everything through a central team or everything flows through that service provider model, it's going to end up being a bottleneck at some point. So let's talk about what these focused API tests can do because I think that's one of the most interesting parts of API security is that you know exactly what the API should be doing. If you get the right documentation, you know that it can accept certain requests, it's going to send certain responses and you have that contract.

18:36 So, you know, some of the API vulnerabilities that we see even with that firm contract—I think the two most important categories are authorization and authentication, anything to do with users and their ability to extract certain levels of information from the back end system. You know, authentication can sometimes be a bolt-on, and there's different approaches for doing that. And so I think these, whether authorization or authentication can be the

19:06 predominant vulnerability category for APIs, especially when it leads to the excessive data exposure. I think these are all very related. And if you look at, you know, the LinkedIn or Peloton cases, both of them are very similar in that regard, that APIs were put into a system that maybe had too much permission to access data and somebody didn't check that work. Have you ever seen that be an issue?

19:36 Any experience in authorization or authentication solutions for these APIs? If you think of it this way, you know, we have, you know, everyone has an API. Think about it this way. There's always going to be some sort of authorization or authentication you know, environment in that section before you can move on to the next step. And so if you think of it that way, that's the most common denominator between all APIs is so I'm not surprised that you know,

20:06 we're seeing all of these authorization and authentication types of findings. But once you get past that, for the ones that are open, then you're going to start seeing another level of, you know, actual application-related vulnerabilities. And so I think for these authorization and auth vulnerabilities, we're seeing those because the way you do that in an API is gonna be quite a bit different than what you do in a web app.

20:38 Everyone's been writing web apps for years, right? And now we're making this paradigm switch over to API-centricity. That takes some time to get used to and to, you know, actually reinvent the wheel almost for, you know, that authorization type of control. Well, it just seems like everybody takes a different approach, you know, You know, there are bearer tokens, there's OAuth. I mean, there's lots of different ways to authenticate APIs and users to APIs,

21:08 but that association between the user's identity and what they're authorized to do with the API is something that has to be enforced. And you've got to really think about how you want to do that when you're designing the API. It needs to be at the design phase, not a bolt-on later. There are very few cases where you're going to launch an API that's just public and anybody can do whatever. And so it's it's interesting to see the different trade offs people make when you start getting into the design discussions. Exactly. And there's some things that no one ever talks about.

21:40 Like for JWT for instance, you know, you have to sign it. Some people don't even know that and they don't sign their JWT. So that means that any authorization changes that happen inside of it could impact your application negatively. Oh, that's scary. Yeah, a lot to get right there. I think the pentest on just that authorization layer can be a very important one and you know, should be comprehensive enough to handle, you know, the back end authorization of the user as well. So you understand how users are getting their

22:12 tokens cut to them. And I would say that, you know, all these things are kind of scary to talk about, but there are experts that know this, and those are the experts that you want to do your penetration testing. Yeah, yeah. It's a key part of it, but I think it's important to share with the experts as much as you can about how you design your service and get all of that information at the forefront of the test. Share how you built it, the architecture diagrams, how the user database is set up,

22:43 if you're using Active Directory, you know, things like that are good to know. And I think for, you know, user authentication service-to-service comms, there's a lot of managed service providers that are worth looking at, whether it be, you know, your Okta or your, you know, Auth0-type models. There's a lot of reuse in that that is important and you know, it's like they say about crypto, don't go build it yourself, try to find something on the shelf that's already battle-hardened.

23:13 Yeah, exactly. I think the misconfiguration is another prevalent one. Just the fact that things are changing so often under the hood, you know, did I get my encryption right? Did I set my parameters that I'm going to be accepting through this call? Is it enforced at some level? Is there an API gateway or API proxy in line that's handling some different part of the flow in terms of filtering requests? There is a ton of you know,

23:45 small decisions that need to be made that could, if made incorrectly, lead to a breach in that misconfiguration arena as well. Any thoughts on the use of like API gateways or API proxies to make deployment a little safer? You know, from a business standpoint, I think they are great. I think, you know, you should try to leverage that just to reduce the complexity and help you really protect your applications.

24:15 But you know, these types of gateways are great for, you know, you as a developer, you don't have to worry about that portion, you can focus on your functionality and let the gateways handle that sort of authorization authentication because they take this idea, you know, I have five APIs that I'm writing. If I'm going through a gateway, then all I have to do is set up my authorization tunnel from there rather than having to set it up for each API team.

24:46 And those are gonna be different the way they do it. There might not be a standard that you use. And so you're just introducing risk by rolling your own essentially. So put it through your gateway and then one team and you can consult with your security team and you know, make it as great as it can be. Yeah, I think there's a lot you can mitigate on the edge, using solutions like that. But there's also no substitute for a human adversary. I think getting a look at your APIs and the changes in your APIs by human

25:20 pentest is unparalleled in terms of its benefits. Now, our approach on this is basically to deploy a number of hackers at a time against an API, give them the information they need to be successful and to use it, and then they use their security expertise to go find those exploitable vulnerabilities and try to abuse the API like an adversary would. Through that process, you know, we're looking at providing transparency of coverage and showcasing the proof of work so you can see exactly what the testers

25:52 are doing while they're doing their work and have the assurance that each endpoint was actually tested by an expert. And then, you know, at the end of the day, you have a very well-defined report that shows that you've looked for the OWASP Top 10 category of vulnerabilities across the APIs. That can also be used in your compliance certifications to say that you're doing everything you can to find these vulnerabilities in advance. And, you know, I think that's just as important to take both the

26:25 compliance route to have the evidence that you did everything you could, and then also the offensive security route saying, Hey, we threw a bunch of hackers on it, incentivizing them to find vulnerabilities in advance. I think this can also be, you know, done as part of a pre-production push where you're testing these APIs pre-production, and I know, you know, you've mentioned this before about how you integrate with the development team. But, you know, what about, you know, doing all this testing pre prod and prod so you're catching the

26:56 differences and also trying to find vulnerabilities earlier in the cycle so developers can fix them? That's the main... How do you think about that? Yeah. So, you know, I always tell people who ask what AppSec is, you know, our main goal is to get developer buy-in, but essentially make sure that we are in every stage as far left as we can go. So when they get hired, we do training, you know, as far as left as you can get. And then we build it up after that,

27:26 and we eventually get into their CI/CD pipelines and add in our, you know, security scanning, those defensive protections and then you got to get to that place where you can also put in your offensive scanning and/or pentests. And you know, I think if you can build out your program in a way that includes that left in your SDLC and not save it for when you're at user acceptance or production,

27:56 then you're going to be in a much better place. Even if they're not finding those vulnerabilities, at least, you know, have experts that are looking and when they do find them, they're going to be those vulnerabilities that slip past your scanners slip past your QA instance and are the ones that are proven exploitable at the end of the day. It's a defense-in-depth strategy, right? Getting developers more security-aware, then having the experts on the other side post-deployment to really find those

28:26 hard-to-discover vulnerabilities. But it's the old adage: defense-in-depth works. You know, if you can catch it early in the cycle, the development cost goes way down as well. Exactly. Now, lastly, I wanted to touch on, you know, Synack's approach for API pentesting, specifically on headless APIs to provide that service-to-service communication. As I mentioned, we do deploy researchers across those API tests. They record their work providing screenshots and proof of coverage. And at the end of the day, you're delivered fully verified exploitable vulnerabilities on

28:58 the API stack itself, and these reports can flow directly to the development team. So they're continuing their education process around what's exploitable so that they can hopefully prevent it in the future. That evolution and that learning is so important day to day and having that elastic capacity with someone like Synack Red Team that you can deploy your changes at will at the speed of your own development team and ensure that it's going to keep pace with the desires of your

29:29 security program. Yeah, I do have to say one thing about this. The reports that Synack provides are top-notch. You know, I can give them to a QA or even a system owner and say, hey, this is a report, recreate it. If you have questions, let me know. They almost never have questions. They are able to reproduce the vulnerability, show it to their dev teams, fix it and then get it retested and it's done. And so, you know, I applaud the reports that Synack puts so much scrutiny on.

30:01 It's time well spent. I appreciate that. I appreciate that feedback. We thank, you know, Synack Platform team and Synack Red Team for what they do to deliver this product to the world. You know, with that, everybody on the call, I appreciate you joining us today. Thank you for your time and, you know, we'll be around for questions at the end. Back to you, Katy. Thank you.

30:31 Thank you, Mark, and thank you, Chris, for a wonderful webinar on API security. And now we will be ending the webinar. If there are any remaining questions, you can always reach out to us through our website or on social media. Have a great day, everyone. Thank you.

No lines match that search.