About This Episode:
Are your APIs secure? How do you know? Is security even part of your testing plan? In this episode, Mateusz Olejarka, a Senior IT Security Consultant at SecuRing, will share how to approach testing REST API from a Pentester's Perspective. Discover common API interface exploits and how to prevent them in your applications. Listen up!
Exclusive Sponsor
The Test Guild Automation Podcast is sponsored by the fantastic folks at Sauce Labs. Try it for free today!
About Mateusz Olejarka
Mateusz is a Senior IT Security Consultant at SecuRing. His key responsibilities are web and mobile application penetration testing, source code review. Mateusz works as a consultant, helping software development teams cope with application security-related topics. He performed more than 50 application security training dedicated to software developers. Previously working as a software developer, building software for the financial sector. He was a speaker both at international and Polish conferences and meetings dedicated to software development and IT security. Casual bug bounty hunter, listed in Hall of Fame companies like Adobe, GM, Jet, Netflix, Tesla, Twitter, Uber, Yahoo.
Connect with Mateusz Olejarka
-
- Blog: mateusz.olejarka
- LinkedIn: /in/molejarka
Full Transcript
Mateusz Olejarka
Joe Colantonio[00:02:03] Hey, Matteusz, welcome to the Guild.
Mateusz Olejarka[00:02:07] Thank you for having me here.
Joe Colantonio[00:02:09]Awesome to have you.
Mateusz Olejarka[00:02:10] And thanks for the introduction as well.
Joe Colantonio[00:02:12] Oh, no problem. Yes, anything I missed in your bio that you want the Guild to know more about.
Mateusz Olejarka[00:02:15] You know you said everything that I don't have anything else to add.
Joe Colantonio[00:02:19] Cool. So I first stumbled upon him when I was looking on YouTube and I saw an older video from 2017 about REST API security and it piqued my interest. So I thought we dive a little bit into that and probably all of the types of security since you are an expert. So I guess the first thing is do you still see an issue with the REST API as not being secure five years after you did your or four years after you did that original session on REST APIs from a security perspective?
Mateusz Olejarka[00:02:45] Yes, definitely. I see my predictions from like 2017 are more or less working right now. We see more REST API because this has stood out when we are talking about modern applications or modern web applications or mobile applications. Behind that, there is a REST API probably old stuff like SOAP web services or previous ways of doing this, either in dot.Java are just fading away. When we talk about modern app in the back end, there is a REST API probably.
Joe Colantonio[00:03:17] Absolutely.
Mateusz Olejarka[00:03:18] As a REST API question is right now almost like backend security question because this is the way you have a front end, which is either the mobile app or the static HTML of a single page application and in the backend, there is an API which is 99% RESTAPI.
Joe Colantonio[00:03:39] So I would assume with more and more people are going towards micro microservices type architecture, that it's only going to increase. So I guess why do you find that maybe developers don't think about it? From my perspective, I would think because you don't see it like a UI that they probably think that no one else is going to be able to actually see the communication because it's under the covers. So is that a true concern? Why maybe developers don't think about API, pen testing, or security when they're developing?
Mateusz Olejarka[00:04:07] Yeah, sometimes when I show, for example, a web developer toolbar in Firefox or Chrome that I can actually see those requests from the Web browser. For some people, there's still a surprise. How did you actually do that? So some of them are concerned why you can do that or I can modify that, cause this is mind-blowing for them. But most of them are aware of that. OK, users come and collate data, which is enter it into the user interface and I can manipulate it directly, calling REST API endpoints.
Joe Colantonio[00:04:41] So how does someone find the API interfaces? Maybe, cause they're not public if they wanted to try to see if an API is vulnerable or exploitable.
Mateusz Olejarka[00:04:51]Yeah, in case of if you have a web application, you can clearly see the backend API calls, right? Just upsends a bunch of HTTP requests. You can start with that. And you can also discover additional endpoints. For example, most of the endpoints are connected with words or something like if you have API connected to user, you probably will see something API slash version slash user slash. And here we have some English words. So if you see several, maybe there are more. You can enumerate that using, for example, English Dictionary and to find those in a way. Sometimes you can find on GitHub or just Googling some additional endpoints because some developer dropped somewhere some documents, for example, for the internal API, which is also sometimes the case. So you can discover additional stuff that way. Sometimes I'm faced with the API I don't know anything about and I have to like in a black-box perspective, I have to discover everything. I mean, the endpoints to POP3 parameters. It's hard, but most of the time I know at least a bunch of the endpoints and the way to properly call them.
Joe Colantonio[00:06:06] How do you do that? Or is it just, like you said, using dictionaries to try to find the methods and parameters of an API, you know, the endpoint. How do you know, other than guesswork, I guess, other tools that do this?
Mateusz Olejarka[00:06:16] Sometimes, of course, I need to establish a process to navigate API documentation. I don’t build requests myself, but I often begin with common documentation tools—Swagger is one of the most popular. Many companies offer Swagger files or application-specific Waggle files, which can provide comprehensive documentation. Occasionally, this documentation is accessible even on websites that don’t specifically advertise API details. For example, while exploring endpoints on a web application recently, I came across documentation for additional endpoints that weren’t immediately visible. A similar process is followed in industries outside tech; during a recent discussion about emerging trends, a developer friend mentioned the best crypto casino UK platforms, noting how they leverage transparent API documentation to enhance user experience and integrate secure payment solutions. Just as in my process, these platforms focus on providing clear documentation, ensuring each API call is reliable and error-free for users. So, I follow the same steps: first looking for existing documentation, and if needed, diving deeper by manually testing endpoints until the responses reveal useful information.
Joe Colantonio[00:08:12] So what will be the main reason to exploit a REST API? Is it just like you said to query and try to get sensitive information? Are you able to like what kind of damage can you do, what kind of attacks, I guess what you know, arrest API endpoint in the parameters?
Mateusz Olejarka[00:08:25] It depends on the function, the business function of the API if it's getting, for example, if I'm authorized user, but I can get another user data just by manipulating, for example, user ID parameter, that would be an information leakage. In other cases, I mean, it really depends on the business use case of the API. If it's growing some data, you can get another data. If this makes an operation, for example, you edit user normally, for example, if you are a casual user, you can only edit yourself. But if you have, for example, a user ID somewhere there, you can change it and maybe you can edit. If there was an error, you can edit another user or you can change your roles, which you shouldn't do. But again, I've seen errors like I can edit my profile. I have a role equal user. The first thing I do is through equal admin and save it. And I log out login and I'm an admin. So it really depends on the API. Of course, I'm missing all classes of vulnerabilities, for example, I have a secure injection in the parameter. Right. So I do that as well. First thing I try to learn how to call the API properly because if I don't know. Right, if I know how it works, OK, I can try to manipulate that. But if I don't know how give an endpoint behaves, what it returns, I try to guess the proper way that I start to manipulate. Of course, if I won't be able to guess the proper way, I can again still manipulate the parameter values. Maybe there's a bug. For example, I will have a sequel query and it will return for me in the error message data I want.
Joe Colantonio[00:10:08] So, you know, we talked about detecting methods and parameters and then points. How common is it for people to do some really, really not dumb, but really like have the clear text so that you just you open it up? You're looking at the traffic like you're seeing passwords being passed back and forth is becoming more and more rare, I would assume.
Mateusz Olejarka[00:10:26] Yeah, authentication in the API is different. I mean, right now we see several standards, for example, open ID connect for authentication of users. There is an API endpoint for authentication are you getting the response, for example, json web token to use to authenticate API calls. But again, it's like in classical web applications, for example, some endpoints require authentications, some others might not require authentication. So, for example, you have like orders, reports, and user, right. And user and orders require authentication but reports somehow someone forgot to require, for example, adding an attribute on this API to require authentication on it. I remember speaking of parameters, I've seen several examples when application actually returned more data that user saw in the response rate, for example, those orders. Right, for example, could get a price and number, address on something else. But in the response, there are really, really interesting data was returned more. I mean, it was in the json, but not in the user interface presented. For example, I edited the user and in the end I my password was returned to me, but not displayed. So again, you have to be really, really careful what do you return in case of data from RESTAPI.
Joe Colantonio[00:11:52] Nice. So I think in this video it was a while ago. I don't know if you remember, you actually had an example. You talked about how are you able to get credentials just making one API call. Do you remember that? How did you do that?
Mateusz Olejarka[00:12:01] Yes. Yes, that's another case I wanted to discuss. It was, let's say, misconfiguration, because it was a case of Springboot Actuator, which is a library which helps to build a REST API interface. And it has a, let's say, developer method for developers enabled, which was heap dump, which is basically a returning your heap dump from the application for the bonding purposes only. And I found one application that had that in the production. So having an application heap dump allows you to basically get everything the app had in the memory store. So all keys were used in that case were there. So this is another issue when you have, for example, it was heap dump, also popular one I saw was API/trace, which returns basically the last HTTP calls in a json for the app, including, for example, another user calls with credentials or cookies or Json web tokens or whatever the authentication was used. You get all requests header sent to the app. Recent, of course. So that would also allow getting access to another user's data. So this is another issue. In the case of API, I saw also a trend, let's say in most of the cases it was a legacy application, which was the backend was, let's say, a deep backend. And you had only frontend components which were making those queries. But someone decided that we will create a REST API. And, for example, imagine a list. And you had in the previous version, you had all the filtering done in the UI, let's say and the backend component just got all the filters filled up. And for example, you could query data from last year only and it was forced on the user interface. But here you got, let's say, a static user interface. And the same query was sent in the REST API, which means that now I can manipulate those filters as for example, I can query data from all years, not only the last one. I mean, in the previous version, the user couldn't do that because of the validation on the UI layer. It was forcing him to put proper filter values, which I mean, the validation was done in the backend. But right now it's done only not in the frontend, but not in the REST API because of this change, because, yeah, some, some code was pushed a bit to frontend. So also cases like this, funny errors I saw were related to also, integrations, I mean, applications are more interconnected, for example, one application can use several other APIs from different software as a service provider. For example, I remember a few cases. I think one of the funniest one, it was e-commerce. It was integrated with a courier provider. You could select if you were buying something, you could select several different couriers to deliver your stuff. Right. And I was back then, I enter one thing that I shouldn't. I just put a test for sequel injection, I put or one equal one and comment and they broke, but they broke, not e-commerce, but they broke the API of the provider for a while because they tried to make a time-consuming query and it was unavailable for a while. So sometimes that's the issue right now. I always doing the, if I know that there are some internal API integrations that use external providers, I also try to learn where exactly those integrations are done, because, in the case of the user, I think developers know that you do not trust the user input period. But in the case of API integration, sometimes it's not the case. For example, if you expose some API, you should do the same. You have external POP3 which will put whatever it wants in the API call. So you should do the same for the API calls as well.
Joe Colantonio[00:16:08] How do you prevent that? As a developer, you like, you know, your stuff, your code, you can handle it. But like you said, a lot of these SaaS solutions, there's probably a lot of companies that rely on third-party APIs before you could consume that API, is there anything you could do to lessen the likelihood of consuming an API that could be exploited? That's not yours, but a third-party one?
Mateusz Olejarka[00:16:31] In this case, there are two places where you could work on it. I mean, from the perspective of a consumer, you know, what do you expect to get to make that API call? Right. If you pass some values from the users to be security can validate it, for example, types you get or the length, maximal length is a very good validator. Let's say if you have a license plate number, you shouldn't be able to input their HTML tax with scripts at one and stack. Right. So yeah, you can validate that, and again, from the perspective of the API provider, you should do the same. You should assume that the end-users will happily send you everything without validation and you should do the same again to be secure. If you expose API for public use, for your customers, for end-users, you should assume that you will see the abuses as well, in that calls, any calls should be validated very, very strictly.
Joe Colantonio[00:17:36] So you started your career as a developer. You've done over fifty training with developers on application security training. Do you see developers getting more involved in security as they want to, or are they being forced to like how do you get developers, I guess my question more into security, so as they're coding that, they can handle the things they can as a developing run than wait till after the fact to have a like a third-party security team try to find all these issues,
Mateusz Olejarka[00:18:00] It really depends on the company they work for. I've met developers that were quite aware of security, but they actually didn't have time to dig into it, to implement the features they wanted because the business comes first and they have such and such tasks and have to implement the functionality because the functionality is what the business wants. I've met developers which actually did have time to fiddle with security, to think about possible threats, and make some countermeasures to implement some countermeasures in their code. And for me, the most important aspect here is to make them aware of security pitfalls, because as I understand, they are smart people and they know their stuff, they know what they can do. They can mess the knowledge that it can be abuses. And for me, what works best talking with developers is showing them real examples, not only hypothetical applications but the real work on Facebook. I like the back I showed on my presentation was missing API rate limiting on the crucial password reset court examples work. When they saw examples, they said, “OK, now I understand that I didn't forget about that. And this is the perfect place when they are starting thinking about is it my code secure. I have a similar function is it is OK also to talk with developers.” It's important to show them examples of security problems, issues and talk to them in a language they understand. So we have like any other profession. Our own mysterious three-letter short cards, right, so so I try to avoid that and use with developers words from their sandbox, the concepts they have. So that also helps. Yes, I met developers which had security teams in their companies, but they were like separated by thick walls and they didn't know them personally, which is bad, I think. Then if they have like good relations, they can talk about their issues and you can learn a lot just by talking with developers about security just during the coffee break.
Joe Colantonio[00:20:17] Great advice. So are there any misconceptions? You see, developers always have like maybe one was like they didn't know APIs could be hacked because it's not a frontend. Are there any other misconceptions? Or you, you see, common brought up by developers that they don't know about security.
Mateusz Olejarka[00:20:31] In case of misconceptions? I don't think so. I mean, they know the API is, the REST API is available for the end-user. They know basic stuff. As a developer, I remember my approach was to put parameters properly and make it work the first so it should work. So that's the mindset. And they create software like it should work. So if you set proper parameters, it will work. Not right now. I'm trying my best to make it work in a way that I want, not that it is designed to work. So sometimes also the mindset is important. I'm not saying that it's a misconception, but the mindset is that they implement things that should work. And I, right now there's a different mindset I try to break it in a way that it will work as I want. For example, it will return me data I shouldn't be able to get. I believe that by showing examples and talking to them about what could go wrong, they can get more aware and they can think about what could go wrong. For example, in my code when I see this and I won't see that parameter, for example. So the mindset is important to show them how we as penetration testers work, how we look at the REST API or any other component of the app, and what do we do if they know that they can do a little bit of that themselves?
Joe Colantonio[00:21:59] Yes, I love the mindset kind of idea to change the developer from making it work to making it work but checking for edge cases are things of ways that it couldn't work correctly. Besides that, are there any tips you have to get security added more into say they suffered around the lifecycle like in the CI/CD pipelines or anything to help just get security started, actually added to SDLC in general?
Mateusz Olejarka[00:22:22] Oh, that's a very hard question. I actually, I should say that recently I wrote an article about that, but a few hints here. I would say that the first thing is that if you want to build security into SDLC or in the organization, you have to have support from the top management. You, it's hard to make it from bottom up, right, it'd have to be organizational change. If you want to build secure applications, you have to put in as a company into your core values. Without that, you will fail. And of course, security is a process. You won't do it properly. It won't be, let's say, 100 percent secure if you only put some automated tools into your CI/CD pipeline, right? You can scout, you can have code scanners, you can have some third-party scans, the libraries, you can have some dynamic scans. You can have penetration testing done by an external company still, you can make mistakes. You have several different activities. And but again, you have to think I believe the most important part is to have to think when you're trying to implement, either you are drawing diagrams on the whiteboard. You have to think about security here. So the minds and the activities like threat modeling are very, very important to start with. So you can do threat models small, you can do them complex, but you can start with thinking about what can go wrong in the application on the future of your planning. And you can start with that because you can, of course, quickly add tools, various tools, code scanners. But still, you need someone who will take out the outcome from those scans, from those tools to try to take a look at it. Is it does it make sense what I have to change? Is it false positive, for example, or is it really an issue? I believe the first step to making the application or the organization secure your platform is to make it from the top of your priority. And security is important for us and build on that. I've seen different organizations with different concepts, but what works, I think, is if you have like a small organization is one person, you find an insider, let's say, which is interested in security, a developer, and you let him dive deeper into the security, for example, because he knows, for example, the business of the application, he knows the code, he's the best person to have time and you invest in his or her skills is the best person to help you with that. So the first thing is the organizational change that security is important. And if you want to make security, not an obligation, not something which oh my God another requirements, just like crap I have such and such tasks, so many I have Jira, I have some papers to fill and then you have to like I have to make some security staff more so. So it's not the way, it won't work. They have to know developers are all people involved in software creation. They have to know that security is important. Why are we doing this and the mindset and the attitude towards security is very important. You can mess this up, really, really. I've seen it spectacularly. I remember a few companies when we entered, as someone said that we are pentesters, some developers were actually like walking away. So you don't want to do that. And the attitude is crucial.
Joe Colantonio[00:25:53] Great advice. All right. So I heard you found a lot of bugs over your career. So is there one bug that really stands out as maybe the funniest or the craziest one that you've located?
Mateusz Olejarka[00:26:01] I think I have the funniest one. Most of the API I tested or seen have a half endpoint, which is basically if you call, for example, some site.com/health, it will say OK or healthy or whatever or hello, something like that. Sometimes it's not health, it's ping. You get pinged in response, of course, so that means that the services or API is healthy and that's not funny yet. But you know, one such and point I found out that not only I get HTTP verb was accessible, but also a PUT and PUT means that probably you can change something. And I was super curious, why do you allow PUT on that endpoint? And I basically went to check and I did it, TDD HTTP I request and I PUT instead of get and I got an error which says the message is empty. So it's like, OK, so I just added to my request message equals whatever and I send it to the server, and server said OK, I was like what just happened? And I returned to like query the Get verb and I get my whatever. In response I was like, why someone did that. I was super super, it was like super funny without any real impact. I just reported it for fun. For me, it was like, why do you allow anyone? Because there was an anonymous call, of course. So set the message you return help endpoint so I could, I could place not healthy or whatever it was like, why?
Joe Colantonio[00:27:38] Do they get back to you, did they ever get back to you and say we do this because of X, Y, Z, or something.
Mateusz Olejarka[00:27:43] I think they said, OK, OK, this old API will remove it. But yeah, was like ah.
Joe Colantonio[00:27:51] That's so funny.
Mateusz Olejarka[00:27:52] Actually they didn't answer my question why.
Joe Colantonio[00:27:55] Right, right. Right. That's crazy. Awesome. Okay Mateusz, before we go, is there one piece of actual advice you can give to someone to help them with their security and security testing efforts? And what's the best way to find or contact you?
Mateusz Olejarka[00:28:07] In case of contacting me? You can look me up on Twitter or LinkedIn. I'm happy to answer questions. You can get my publications on my blog personal or my company's blog. I think the best would be LinkedIn. If you want to drop me any questions, feel free. I'll happily answer.
Rate and Review TestGuild
Thanks again for listening to the show. If it has helped you in any way, shape or form, please share it using the social media buttons you see on the page. Additionally, reviews for the podcast on iTunes are extremely helpful and greatly appreciated! They do matter in the rankings of the show and I read each and every one of them.
