The Hacker Mind Podcast: Hacking APIs

APIs are vital in our mobile digital world, but the consequences of API security flaws have yet to be seen. So how hard is it to hack APIs? Not very hard.

In this episode, Jason Kent from Cequence Security talks about his experience hacking a garage door opener API, the tools he uses such as Burp, ZAP, and APK tool, and why we need to be paying more attention to the OWASP API Security Top 10.

The Hacker Mind is available on all podcast platforms.

[Heads Up: This transcription was autogenerated, so there may be errors.]

‍

Vamosi: Hey, if you're like me you probably have a few 100 apps on your mobile device. Now, consider that your mobile probably has less overall memory than say your laptop. So how can you have all those powerful apps on your mobile with less overall memory? Simple for mobile apps, necessarily, processing the data locally, they're basically just exchanging that data back and forth with the server for the cloud, via Application Programming Interface or API API's themselves are not new applications and data centers have been using API's for years to exchange data among themselves internally, what's different. What's on your mobile than our external API's and in the past few years there's been an explosion of external API data. What we're really talking about is data formatted into discrete fields, such as your name, your location, your last request for an Uber, and these external API's aren't just on your mobile devices. They're on all your devices,

[Peloton commercial]

During the pandemic sales of the Home Fitness cycle peloton grew massively, given its popularity, it's natural that security researchers would want to take a look. And in May of 2021 Researchers disclosed that the Peloton API authentication was broken. With that an attacker couldn't necessarily intercept the data, but they could query the peloton API to get user data that they weren't supposed to. In other words, Peloton suffered from an API vulnerability that could potentially lead to a massive data breach. Here's Eric Wilde and his guests, Francoise Lascelles on Getting API's to Work podcast discussing the Peloton vulnerability. 

Wilde: Now, for me the storyline was interesting right so when it was reported I think in late January, it was completely open right like this is right no authentication at all because well we didn't tell anybody about it. And then they reacted, actually, relatively quickly, within a couple days, closed, but they closed it so that now you had to be a registered Peloton user. So, you know, now you had to be one of the privileged millions who can freely create a Peloton account so even though it was authenticated then that was not super helpful I guess. Yeah. 

Lascelles: Yeah, and this, this is a huge lesson in API security right hackers are also users.

Vamosi: So, if a hacker wanted to, they could register as a peloton user, and then with a few tools, obtain all the user IDs, instructor IDs, group memberships and whether or not somebody was in a studio. This information by itself might not seem very problematic. But the peloton API also contains your location, your workout stats, your gender, and even your birthday. Okay, that's starting to get very personal.

This raises a serious question. How many apps today are vulnerable to leaking API information, how might future API based data breaches work. For that, I called upon an expert.

Kent: I’m Jason Kent, hacker in residence here at Cequence Security.

Vamosi: The work that Jason does for sequence has in the word sequence but with a capital C at the beginning, is helping his clients see where their security needs to improve. I play an adversarial role with our clients.

Kent: So, if they're not being attacked I attack them and if they are being attacked I break down how it's happening and how we can stop it. That kind of makes Jason a one person red team. I don't know maybe purple team a bit, I played kind of both sides of the fence but yeah definitely do a lot of adversarial inspection of, you know, any kind of traffic endpoints that I find that our customers. 

Vamosi: To be fair, API's are also used in web applications, which you access through your web browser. And we've had our fair share of security concerns with those. In fact, to keep track of all the potential web application vulnerabilities, the Open Web Application Security Project or OWASP publishes a list of the top 10 web application security risks. Fortunately, one by one, we've been knocking each one of the flaws, further down the list. Well, it turns out that OAuth also publishes a list of the top API security risks. But how many developers in the heat of the moment trying to get their app into the App Store are even aware of the API top 10 list. 

Kent: I was recently commenting on the peloton, and I thought well how boring is that, you know like that. I mean I got all the data out and I could see anybody's data and stuff but the attack was so boring that I bet they didn't think it was gonna work when I hit Go. And that's kind of how it is with API's, when it doesn't when something is broken something out of that API top 10 Isn't there, it just all comes flying out.

Vamosi: Given our current digital environment, just how powerful our API's in terms of external data exchanges, and how are they different from web applications. And if they're so critical these days. Then why haven't we been paying more attention to securing APIs. I mean, how hard is it even to hack an API. Apparently, it's not very hard at all.

[Music]

Welcome to the hacker mind in the original podcast from for all secure, it's about challenging our expectations about the people who hack for a living. I'm Robert Vamosi, and in this episode I'm discussing the importance of API's in our digital world, the consequences of misconfigurations within API's and how you, yes, you can even start hacking API's in your spare time.

{Music]

So, for this episode I probably need to set the landscape API as an example of where I think I understand something, but then I come to find out there's a lot more to it. There's always a lot more, right. So, at a very high level, we do use an application on a mobile device that connects to the internet and sends some data to the server. The server then retrieves it and interprets it and performs the necessary operations on that data. That's at the back, the app on your mobile device then interprets that data and presents it on the screen. Again, at a very high level. That's what an API does a shorter definition API's are where you define and perform operations on information that is shared with another computer or system, we kind of discussed this as north south or east west traffic API is used inside data centers and that's what's known as east west traffic north south traffic then is data coming in and going back out. And that's what's grown in the last few years, and grown by a lot.

When you open a browser, you're working with a web application on a server somewhere, both web applications and the mobile app actually talk to the same API, that's where it gets confusing. It's like having a shared kitchen with two restaurants, mobile apps, or just rendering API data without all the bells and whistles that you might find with web applications. So, your high level takeaway. Perhaps we could say that mobile apps are different from web applications, and that they primarily use API's.

Kent:  it's a little bit of a borrowed term right inside of software there are API's that you call, you know, in the libraries and stuff to move things around, and we've moved it out into the application space as kind of a way to go get data, a way to communicate between two systems. So it's typically computer to computer communication. Some of that manifests by user input, but usually it's just simple. I make a request for some data on some endpoint on a web server and it sends me the data back. Usually this communication happens in some kind of data language like XML or JSON or something like that as the transfer. 

Vamosi: An API when you get down to it, is just structured data, kind of like XML, kind of like JavaScript Object Notation or better known as JSON. Think of it this way. It's like filling out a Google Doc, and all the data that you enter into the blank input spaces becomes the API traffic going back and forth, only it's a little more complicated, especially if you've got multiple data exchanges.

Kent: Realistically, what it is. I've got my mobile application, and in order for me to get my information out of my bank I log in, That logins, gonna happen over those API channels, and then it's not going to send me code like it would in a web application where it'll send me the page to render it actually is already rendered in the mobile app, all we're doing is filling out discrete data fields. So account balance and, you know, Do you want to transfer that kind of stuff. It simplifies communication. 

Vamosi: Okay, even with this technical definition API's may still be a little hard to conceptualize. So, maybe a concrete real world example is needed. 

Kent: I like to use Uber as the example when I talk about this right. When I say I want a car, it's got to communicate to the map services, it's got to communicate to my credit card services, you know, so there's this traffic that's going all around happening from their servers, right and then displaying back to me. So all of this communication is happening at high speed. We don't want to play with moving JavaScript around or sending HTML to render. What we want is just the data to be as quick as possible. 

Vamosi: Imagine that you've arranged your life so that you could be online to get the tickets to a concert, the moment they first go on sale, or better yet, a pre-sale. The day before the general public gets access. So, there you are at your laptop, logged into the ticket website, waiting, waiting, and then the countdown clock reaches zero, your adrenaline fires up your mouse hand tenses into position. The screen lights up. But the seats you want keep disappearing insanely fast. And then, just as suddenly within a matter of seconds. It's all over. The concert is completely sold out. Wait, what just happened? 

Kent: If you look at anybody who's selling PS 5s, selling tennis shoes ,or any of those, you know, hot stock drop items where there's only a few available and stuff, everybody complains about the bots. Right, well the bots are doing everything on the API layer, they don't go through a website anymore.  You know, if you've instrumented your website to keep the bots out by putting up a waiting room, you're only keeping out your customers, the bots are hitting you on your mobile app for sure. That's how they're going to be doing. We have lots of customers that do hot stock drops and, you know, we see the API's light up all the cart creation and people logging in, it just goes crazy right before the drop. None of it happens on the web.

Vamosi: This really was not an attack, not in the classic sense so Jason has seen a lot of bots use the site's data in the API's. In other words, as a human, patiently waiting on the web application on my browser, I didn't stand a chance.

[Music}

Vamosi: I think part of the problem here is that people often have really great ideas, but in isolation. they say, Hey, maybe there should be an app for that. And then someone else says, Yeah, let's build one, but they're really focused on convenience, and maybe they even use some sort of app kit or framework to get started. So they really don't get to the security part, if ever.

Kent: In general, yeah they've shot this out there and said, Look how much easier. Look how much faster. And every time we do that, I swear. Every time we do, we end up with security problems. And we're really living in that world right now. You know you're seeing guy breaches in the news, aside from ransomware which you know is happening in a different way, but when you see your data breaches pure data exfiltrated out and you're seeing it happen on the API layer just simply because the security is not harder. It's just you gotta pay more attention to. 

Vamosi: So it's this lack of somebody who knows security, and I'm sure the internet connected toothbrushes are in that same category, along with all the other Internet of Things products.

Kent: You know I'm imagining that everything is you know, Amazon, Azure. And I think Google Cloud now have, Like, you can fire up in IoT, you know the endpoint version of their product. They make it easy for you to make an IoT device, and then have a back end service that it can work against which those frameworks tend to make things better, but they're still reliant on you're going to write code. 

Vamosi: Sure, there are a lot of shortcuts, occasional errors, developers, after all, are merely human

Kent: And you're going to do things to make it easier for yourself. And, you know, I've often said, There's no more persistent code than temporary debug code. You know, you're, you're going to make changes to make it easier for yourself and they're going to persist and cause you problems.

Vamosi:  So that's what API is, it's structured data that's just in time created in exchange with another system, so we could perform an operation, such as display the availability of Ubers in your area or the specific Uber that you have hailed. So this is important data and data that could lead to data breaches more and more, all the sounds familiar, like we've dealt with this a decade ago, 

Kent: Didn't we? Yeah. And in fact, I'm often lately quoted as saying, we're looking at web app security in about the 2009 timeframe. So all of the things that were happening around 2009 on the web is now happening on a tax.

Vamosi: One of the classic examples of where API creation often goes awry, is with the Internet of Things. Let's make some toothbrushes connect to the internet. Well, we should, because, as a toothbrush maker. I know about bristles, and I know about grips, but I don't know, computer security.

Kent: That really surface itself when I started looking at the stuff I plug into my house, right. I really wanted to understand, you know, are all these new things secure. And what I found out was not the case. Security is really an afterthought and especially when you're talking about these communications that no one really understands right this API communication can't see it. And so they kind of ignore the security features that need to be there, feeling that it's obfuscated enough, it'll be easier to just overlook. 

Vamosi: So a couple years ago Jason started looking around his house for things that could connect to the internet, specifically things that require that he install an app. He settled on his new Chamberlain garage door opener 

Kent:  Yeah, a Chamberlain. So I, I bought this while I bought a box to plug into my garage door opener but I put a new garage door opener up and one of the things they offered was you could put a box on there that would control whether it goes up and down, and it hooks to your you know your internet connection. And basically you get an app on your phone you push open the door, it opens the door, you know this is a company that makes a machine that ticks my door up because I'm too lazy to get out of my car when it's raining. 

Vamosi: So a lot of companies are very good at the things that they do. So you make a garage door opener, and you've been doing it for over 50 years. But do you know computer security best practices? Probably not. 

Kent: You know that kind of company probably doesn't have a real deep security research team associated with them, there's probably not a lot of folks around interested in that and so I thought well this, you know what does somebody who's just entering this IoT game. What are they up to and what are they doing inside of here.

Vamosi: So we've seen this movie before. In fact, we already know how it's going to end. But I'll let Jason tell it. 

Kent: I sat down in my driveway and I hooked my phone up to my computer, using an intercept proxy.

Vamosi: Intercept proxy, that's where you deliberately hijack the data before it reaches the Internet. In this case, Jason had the data go from his phone to his laptop, and then to the internet. While on the laptop, but tools such as burp captured it, analyzing the traffic there, Jason was able to manipulate the traffic before it reached the server. 

Kent: I opened the door and I closed the door so I use the service the way you're supposed to. And then I started looking at the transaction underlying API communication was very simple, simple device ID. I'm requesting this device to open. Right. And so there was a device ID JSON element. And there was a door position element one or zero. And they did a good job and that one was open and zero was closed. 

Vamosi: So the API had two JSON elements, one element to identify which device you're talking to its unique ID, and the other element to tell the device what to do. Open the door, or close the door. It's not rocket science. And yet, a few of you are probably saying, well, what's the worst you can possibly do with just those two elements right. Well, it turns out a lot. 

Kent: I started calling friends of mine. I said, Do you have one of these things, and I got lucky that a friend of mine in San Francisco had one. He's quite computer savvy so I said hookup intercept proxy and tell me what your device ID is. He told me. The next request was his device ID, and I requested the door go open, and he's like you opened it, and, and, you know, there was, I figured out that I plugged my house into this thing that now anyone can come in.

Vamosi: So just make it clear, this isn't the fob that you put in the visor of your car. This is an app that you download and install on your mobile device. 

Kent: My children are older, and they all have phones and cars. I can send them a simple invite string. They install the app and they can open and close the door. If I had somebody delivering a package while I was out of town I could invite them to come in. And so I, it is a very convenient thing, I'm sure that convenience was well overlooked from the security implications of, you know, You can open my garage and grab my chainsaw and do whatever it is that you want to do.

Vamosi: Once the problem is found. Often the work of the hacker is not done. Sometimes reporting the vulnerability back to the company. Of course, Jason reached out to Chamberlain, the company that makes the garage door opener he was using. Fortunately, they were able to work with him on it. 

Kent: Yeah, they have. So I secured it very quickly. They saw right away that it needed to be done. You know I could easily write a script that opens every one of those Viber doors right. That would have been. I mean the shenanigans level is pretty high, and I would have enjoyed that. But I didn't want to, I wanted it to be secure and I don't want people to know that it's not secure so I impressed upon them that I wanted to fix it. 

Vamosi: Yeah, that seems simple enough, call them up and tell them the problem, and they start to fix it. Only that isn't what usually happens. 

Kent: Having said that, have you ever tried to call a random company and tell them their product isn't secure. It's not an easy thing to do and there is no one answering that call, or there isn't anyone on the line, when you try to get ahold of someone and finally save the day.

Vamosi: As we said a garage door company is not known for its computer prowess, and yet more and more of these IoT devices are just, well, we'll add this feature and we'll make it so it's more convenient, but then they have no clue about the necessary computer security behind those statements, and more often, they don't even have an abuse line for you to report it, if there is a problem.

Kent: Right. I actually fund two talks, out of this thing. I spoke at several besides and I even keynote at the RSA in Abu Dhabi about being curious and taking things apart, but I also started a talk on how to be ready for researcher to call, because there was no way, you know there wasn't an abuse that Chamberlain garage doors, calm or anything that I could report to. And in fact, they're part of a multinational conglomerate, the people that I ended up talking to were from the parent company, and it's not called Chamberlain right like it's a completely different thing. 

Vamosi: Right, so a lot of these companies are actually divisions of other companies. Your hacker, you don't have the time to map out every Birger and acquisition. You just want an abuse contact, so you can give them your proof of concept and get the problem fixed. How hard is that?

Kent:  So I started speaking to organizations that build IoT products to start doing things like, you know, just stick a couple of lines in your server that have headers in them that say if you find a security problem, tell us here, because that's where the researchers are going to see it. And create humans.txt files like robots.txt files. There's plenty of different ways to approach this but you have to have some way for the researcher to tell you, hey, I can turn the hot water heater up so high that it'll explode. But you gotta be able to have that come in.

Vamosi: And it's not just cute gadgets in our home. It's true with whole industries as well, such as automotive. A few years ago at DEF CON, Marc Rogers now at Okta and Kevin Mahaffey from Lookout Mobile demonstrated how they could hack the Tesla Model S, they did so by hacking the onboard infotainment system, but by using Tesla's own legitimate API.

Rogers: It’s the car or vehicle equivalent of stored procedures. The car has a bunch of commands in the gateway that it will let you send commands to and that it will then relay through the canvas, and anything that's not part of that, you can't send through potentially means that malicious traffic cannot get through the gateway. Now, that doesn't say that the gateway can't be compromised. We did not go that deep into an analyzing it and we certainly saw signs that there are security issues that we'd like to look at, but as a basic design what it means is, unlike with a certain other vehicle when the infotainment system gets compromised, you cannot immediately send canned frames, but do bad things to look up. 

Mahaffey: And again, that's huge. I don't think you can say the same thing about many other cars out there. The fact that there is this strong isolation is extremely important. So, now we can control a number of things, basically anything that the API does. And now the question is, so there's no way as far as we can tell to inject cannon frames onto the vehicle network but we can use the legitimate API. 

Rogers: The question is can we abuse the legitimate API, here's the things we can do. What do you want to try? So again we set up our SSH server. And of course the one we want to try so if you've got to do a remote cyber attack against a car. Also thinking that it's gonna be the most catastrophic one right. So we found a combination of IP that would allow us to basically tell the car to shut off key parts of itself to shut off the power rails to switch off the, the screen is to in fact, shut the computer down, and we tried that. 

Kent: When Mark Rogers did his hack it was on the fact that the Tesla was looking for a specific Wi Fi access point and he just spoofed it and then could communicate over the API's on it. So, when you look at how people are building things, these small data exchanges are really how it's working and makes it work very quickly. But once you break into it, it becomes a real problem.

Vamosi: Another industry that could be directly affected is financial services, with all the mobile banking applications that are becoming more common today. 

Kent: I actually have banks that are experiencing problems with, you know, well we want people to be able to sign up for a new account, and we want people to put in loan applications, well what happens when a bank that normally processes 50 loan applications a day is getting 5000. You know, and they're coming from 50 of them are legit right and 40 950 of them are from offshore coming from proxy networks, all that kind of stuff. Those API's are getting attacked it's as much as anything else. And the way it's happening isn't by intercept proxies is by tearing apart the apps like I was talking about. Most banking applications have pin certs and they're a lot harder to look at.

Vamosi: Certificate pinning forces your client app to validate the server's certificate against the known copy. It's a way of making sure that the party that is receiving and sending your data is the party that you want, not some proxy or forgery. Certain pinning should be mandatory API best practice, but alas, it is often not.

Kent: You know, you've got to have some pretty good phone foo in order to write code to make it that it'll bypass that certain, but I can go look at the app and just tear it apart and seed it, and

Vamosi: so how do you tear apart an app and see what's going on inside. How do you start to hack. Jason uses burp and zap. 

Kent: Yeah, so I'm personally a Burp Suite guy. I'm also ZAP guy. I do more in Burp than I do in ZAP. But ZAP has a lot of stuff that I really like. But, I already have a burp license so all I did was in Burb, you can tell it to listen on a specific interface, or you can tell it to listen on all interfaces. And that's all I did is I turned on all interfaces, and then in my mobile phone and your wireless settings. There's a place to put in a proxy. And I just put in my laptop's IP address, right, and a port to listen on all interfaces. It picks up all the traffic in their particular case and what I find is often the case is the certificate wasn't pin so I didn't have to do any tricks. I could see the communication wide open. It let Burp terminate their services, I had the CA installed on my phone so I in essence would send the packet encrypted verb would then decrypt the packet, and let me look at it and then it would send it encrypted again with the server. And so being able to peer into the middle there, let me see all of the data exchange.

Vamosi: So looking at his packet captures that's how Jason was able to manipulate the garage door.

Kent: Yep, I was able to see all the data exchanged going back and forth, because I ripped open the middle bits there, and I could eventually say alright this is the big pieces of data that I need to manipulate in order to make the door open or closed. 

Vamosi: Burp requires you to have a license, Zap which stands for Zed attack proxy is open source. It's a web application security scanner, most people may not have heard of that. 

Kent: Yeah, so OWASP project guy named Simon Bennett was the leader on it, I think he's still the leader on his change jobs but he got hired at Mozilla. A few years ago they hired him to write, zap, in essence, with their hiring framework to automatically test their software. And so it's had a lot of fun behind it, it's had a lot of development behind it. It's a great product, with tons of features that I really like. You can get a free version of burp, and, and use it. Either one is fine but they're very like, it's like knowing Python versus Perl. You're doing the same things but man it's a different language. And that's kind of how it works so you kind of learn one and stick to it. They would be one of the two tools, there'll be one of the things I'd say start with. 

Vamosi: With Burp, there are specific tools that Jason uses, such as repeater and intruder. 

Kent: I do a lot of stuff in Repeater and Intruder. Repeater just lets me replay, and I can manipulate things and replay and manipulate and replay, and then Intruder lets you iterate. So, if I wanted to use Burp and triggered open every garage door it would have been pretty easy to just say this is what I want you to change, and start counting up through the numbers. 

Vamosi: There's also a third tool that Jason uses. This one is designed for Android apps. 

Kent: There's another tool out there called APK tool. And if you're having trouble intercepting and because they pin their certs or any of the other weird things they can do to make it so that bourbons app don't work, the APK tool will let you download the Android application for whatever you're looking at, and it'll tear it apart and I'll give you the API endpoints. So from there you can start testing, Android apps are based on Java iOS apps are based on C, so is their equivalent technology for analyzing iOS apps, there is. It's just harder to break.  It's a lot easier to do stuff on Android if they have an iPhone app and an Android app, I'd rather go there.  It just lays out a lot easier. You know the APK file is in essence a big XML file. So it just lays out a lot easier to pull stuff out of it. You now see compiled code so you have to do a little bit of decompilation in order to see it. I don't have that kind of food so I lean on the easy one. 

Vamosi: That said, there are some fun and games to be had with the backend.

Kent: However, on the back end, the developers are starting to do more with frameworks around API's so self documenting frameworks, and I'll let you in on a little bit of research I'm doing those frameworks, auto publish the documentation for API's. We're starting to see attacks against those endpoints. 

Vamosi: So it's a configuration issue, someone gives you a framework, and if you don't understand it, someone who does, then could find where you are vulnerable.

Kent: What I mean by that is if you have an API that say slash v one slash authentication.

There's probably a slash v one slash Doc's and in there is a manifest of all of your API endpoints, all of the security associated with them, etc. If you're into API's and you're self publishing Doc's, please stop doing that, there are scanners now that are reading those docs and then attacking you after that.

Vamosi: Fortunately, the state of API security is getting better. Jason spoke at RSA Abu Dhabi, in 2016. Since then, the subject of API security is gaining traction at conferences, it's becoming a track that is something more and more people are interested in. 

Kent: If I put API in the title of the talk I usually get it accepted anymore. And it's usually a well attended talk, and that kind of goes across the board doesn't matter what it is, developer conferences, you know, pure security conferences where it's like net security focus. If you're going to be talking about API's somebody has this problem they're probably somebody in the organization standing there screaming, and they want to learn how do I convince my boss to pay attention to this or how do I get the dev teams to stop whatever. And so, it's becoming a thing. 

Vamosi: OWASP also produces the API security top 10 list. These are the common weaknesses that are seen out in the real world, the 10 ranked by severity and prevalence. 

Kent: It's pretty accurate. The first two are definitely the right first two. There's broken object level authorization and broken authentication, the first object level authorization that's when I'm logged in, and I look at your profile and can edit your profile. I'm not authorized to do that but it's broken, so I can't. Authentication is, you know whether or not I'm authenticated on to the service. And I've been finding through a bunch of research that I've been doing lately that a lot of people have figured out how to do authentication, in a way that you can just undo it.

Vamosi: I was previously working at an identity company. Authentication of vital aspects of identity management is a lot like encryption, and it's probably something that you don't want to write yourself in house, get some expert, contact an organization such as Id Pro for references or for resources. But then again, as with encryption, you still find people who just for whatever reason, manage to roll their own until it breaks.

Kent: I spend a lot of time looking at traffic going against API's and the traffic that comes out of them. And I alluded to this earlier, there's, there's so much information that comes out of these things, like I said I was looking at this forum group and I just simply deleted the authentication header and I was authenticated and just deleting off. OWASP top 10 came out in December of 19. So we're not looking at a real long run with this thing. And we're seeing that it's very basic stuff. So what can be done about this. 

Vamosi: We have the OWASP Top 10. We seem to know how to prevent this from happening. And yet it continues. It seems that we should be able to stop insecure apps at the App Store, you know, before the user installs that. I mean, we've all heard about the walled garden, and how great it is. Apple supposedly won't let apps onto its app store unless it passes rigorous testing. Apparently API's are not among the tests conducted, or at least what's currently being done is not strong enough of a barrier. Shouldn't the App Store's be doing more. 

Kent: I would like for them to do more. I would like for them to come up with a way to say alright you got to meet this spec. And really, I'm one of those guys that constantly says, you know compliance isn't security, but security will lead to compliance, but if there's only one thing that's driving you to make decisions and that's compliance then please bring it. We really need something that says, All right, your API should have at least this minimum mark its standards typically only set a minimum baseline, you really need to go beyond them to consider yourself secure. So yeah, Let's see some API standards. If not, best practices, enforced by the app stores. 

Vamosi: Jason's seen a fair amount of stuff that probably shouldn't have passed. 

Kent: We see TMI and API's all the time. They're constantly sending back these asset JSON objects that have nothing to do with anything. And, you know, what we want people to do is look at what traffic that they're having going in and coming out. What should that traffic look like and what should the person next to you be able to do with it. 

Vamosi: That's where the API top 10 security risks come into play. So what are they coming in. 

Number one is broken object level authorization. Object Identifiers provide access control therefore object level authentication checks should be considered at every function and accesses data sources.

Coming in at number two, broken user authentication. This is what broke for the Peloton and allowed virtually anyone to access the data until they patched it. Whenever you're compromising the system's ability to identify the client or user, you're compromising the API security overall.

Number three, excessive data exposure.  This is the TMI that Jason has seen in the while. Unfortunately developers still tend to expose all of the object properties without considering their individual sensitivity. 

Number four, the lack of resources and rate limiting API sometimes do not impose restrictions on the size or number of resources that can be requested by the client or user. This can lead to a denial service attack or otherwise allow a brute force attack on authentication.

Coming in number five is broken function level authorization. Without sufficiently complex access control policies attackers can gain access to other users resources and or administrative functions.

Number six, mouse assignment binding client provided data to data models without proper properties filtering can allow attackers to modify object properties, they're not supposed to.

Number seven, security Miss configuration, insecure default configurations can lead to verbose error messages containing sensitive information. 

Number eight, injection. Here the attackers malicious data can trick an interpreter into executing an intended commands or accessing data without proper authorization.

Number nine. Proper assets management API's tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important.

And finally number ten Insufficient logging and monitoring coupled with missing or ineffective integration with Incident Response allows attackers to further attack systems. That's the OAuth API top 10 list. 

Kent: If you can nail down a few of those things, authentication, being able to bypass that authentication, being able to look at someone else's profile etc. Then we start getting to the point where the top 10 For OWASP API security will move, right, we did it with the web security top 10 There's, there's also one web security. You know there are items that have fallen off of that because now you don't see CSRF.

Vamosi: That's a great point. Cross site request forgery, where an attack forces, the user to execute unwanted actions on a web application in which the currently authenticated have largely diminished in part because of the attention of the OAuth top 10 for web applications. Maybe we can get the app store's to do a little bit more around API security. Hopefully by us talking more about the need for API security, we can start to make some of these flaws diminish in number as well.

I'd like to thank Jason cat from sequence for taking the time to talk about API security. You can also find his work on dark reading, and threat post.

The hacker mind podcast is brought to you every two weeks or so free, buy for all secure for the hacker mind, I remain just another programming data exchange, Robert Vamosi.