BOLA, IDOR, MA, BFLA: Welcome to the OWASP API Top 10

Thanks awesome guys great stuff let it be here on a Saturday Saturday morning and yes I didn't talk about api's an API security here so excellent it's going to get started a little bit more about myself I've been in security now for about 15 years now I always say that I got my start with wind nuke 95 and I know that starts dead it's starting to age me a little bit but those were fun times with some early operating systems originally from Pennsylvania but in Salt Lake City since 2001 so easily over half my life and now live in Lehigh I've traveled significantly for work and cover now most of the southwest areas security solutions and those in those regions in

those cities but most of the time most Saturday's most weekend nights and weeknights you'll see me on a soccer field or at least carpooling soccer kids around the valley so it's um I always ask my real job but let's go ahead let's get into it I'm excited to really highlight here some of the new things that we're seeing with api's and a new really a new attack surface that more and more enterprises are leveraging and it's really been a good a good you know change of pace I've spent ten years in application security specifically dealing with web application firewalls application attacks securing login pages and dealing with the ever-increasing attack surface that we have with

credential stuffing and account takeover and you know breaches with you know and in that sense right so secure login pages and things has been something I've been doing a lot with lately but you know ap eyes are causing a change in how applications are secured should be secured and how we're you know businesses are really implementing web pages going forward and so when you think about traditional application security the solutions out there that most of us are familiar with we're Leafs are pretty common in industry or like a laughs so Web Application Firewall well you're gonna have something to Palo Alto which is like next-generation firewall um things like that that are looking to secure

applications from the common attacks that we have the OWASP foundation for a couple years now has been releasing their top ten of applications security attacks and we're and those are pretty well familiar but they don't cover the change that we see with api's the attack vectors have faced API driven websites are different than the attack vectors that would come against a traditional web application and so they give a little bit of history on api's and kind of how we got here is when you think back to what was one on the very first really large popular e-commerce sites that we had an eBay and I don't shop too much on eBay anymore but you know we go

back to the beginnings of eBay you would sit there now you have this auction site you're you're watching your bid to see if someone was gonna outbid you in that in that last 60 seconds or 30 seconds of a bid and eBay needed a way that they could communicate that real-time auction those bid numbers as they changed quickly you know rapidly and they couldn't refresh the entire webpage and expect that that bid or your screen to have the new information right away and so eBay came out with really the first Web API where the API would just request and it will just update the price what the bid what the new bid on that webpage and then wouldn't reload

all of the HTML and process the entire page and now we can continue to see that today on a pop a popular example for me is on our is on the ESPN sites where if you're following a play-by-play of a basketball game or a football score ESPN is not refreshing the entire page all the time it's just that simple play-by-play information that the API is processing and so those are the differences that's how we see what applications moving now we're getting away from you know the traditional website where it's a massive request you have a large web web server that is processing that and feeding that out each time to where now it's more real

time data and it's just the data that's important to the web page you know and we kind of refer these leaking or refer these of single page applications another good example is Netflix where you can almost endlessly scroll and then Netflix will display the new recommendations whenever that comes into your field of view and so to do this right now we're moving on till we refer to as a microarchitecture with AP is where each API microservice will just reply to that specific API call that's being requested so this could just be the authentication page to your application it could just be the real-time game score it Netflix's world that could just be you know the top 10

recommendations it could be your action movie movie recommendations but each microservice handles a different part of the webpage so this allows to have faster real-time responses to the content that the users are looking for are expecting to see in the in their browser window in their application and it also obviously that allows the service and a micro service world to expand more rapidly if a certain aspect of the Paige is busier than the other then that microservice can expand or shrink in your cloud availability set to cope for the load of just that particular aspect of your webpage and you're not duplicating the entire site they handle just a small aspect of your webpage so

that's what's bringing us up to date here with api's and so now when we look at the different architectures the different requirements around API security the OWASP foundation came together and created a specific top 10 list of vulnerabilities that we see specifically on API endpoints in API applications and so when we look at these we see here's some clean distinctions between the traditional vulnerabilities on the application security we do see a few holdovers and down here at the bottom around 7 to 10 those we've seen before in the past and are common across applications and we'll speak to that but the top six here are very unique and we'll get into some of the uniqueness of these but ultimately

it comes down to the fact that we're getting away from what we refer to in the industry as signature protection or attack signatures in a Web Application Firewall space and one thing I became very familiar with and the beginning of my career was a concept of a tax signature and the common example that will be if I'm running a web server an Apache web server and the Apache web server has a vulnerability then anybody running that version of Apache is going to can potentially be vulnerable and so an attacker can create a common attack string if you will that would exploit the Apache vulnerability from a security solution perspective I would just need to write a specific

signature that looked for that attack string I could push it across my solutions I could create it once and you know then an all intensive purposes that attack would be mitigated from an attacker perspective it was also pretty easy he could craft that specific attack string blasted out across the internet anybody running that version of Apache or that version of the web server could potentially be vulnerable and I would have my attack and I could attack anybody running that string and I'm successful in the API world these api is one or more customized there's no such thing as a common API implementation every business every website is going to have some type of an implementation

specific to their needs and to their development to their DevOps practices and their developers how they coded their API so there isn't a necessarily a common last signature that I can just blast out and that everything would then work there has to be a level of reconnaissance that an attacker does to discover these vulnerabilities to profile the api's and so that entails us well a different type of security we can't just put an API endpoint behind a wife an application firewall and expect all of those signatures to take effect or to have you know the type of security that we're used to oftentimes api's as well we can assume that these api's are going to be accessed through a browser

so things like browser security as well does it necessarily apply in my experience as soon as you know one of my customers put an API endpoint behind an application firewall I quickly saw that nearly you know 20 to 30 percent of the security policies or features apply they would lose 70% of the value that a wife could do because bot detection you know browser telemetry you know the things that a wife would do to run and run inside the browser to detect and identify the attacker can't happen because the API is either it's a business you know it's a machine than machine communication or it's a native mobile application where we can't run those things inside a browser because

the browser doesn't exist and so you lose those protections and the top six here that we see broke an object level authorization broken authentication all the way down here to mass assignment these are things that are not going to be covered with those traditional solutions and so let's look at why that is well dive into a little bit deeper the fun things here so the first one the most common one being a broken object level authorization attack I'm going to highlight two specific attacks and where this will affect is some very large customers and really what it boils down to is once I am authenticated as a legitimate user what does that authorization what does

my authentication allow me to do in an often case is what we're going to see here is that allows me then to access data of another user so there's I'm authenticated and the API is doing the authentication check but it's not checking what I'm authorized to see whether or not I have permissions to see this data I'm not any cated to the system and once I'm authenticated I can get whatever I want and this is a very difficult from a DevOps perspective because you have to do this check basically on every request that the authenticated user is making so when we look here here's one example this is from last July as when one was detected

but specifically was disclosed around November where an attacker once he was authenticated to you know the Verizon basically customer portal here he was able to access that or just enumerate all the contract IDs as part of that API request and returned roughly 2 million contracts or account account agreements here from the Verizon system here and pretty obviously pretty significant and really wasn't that difficult here so well the main thing here is we'll get into how somebody like this can get this information the steps an attacker would do if he wants to begin to attack some of these api's that wasn't that difficult from his perspective and in an attacker one of their first things they

will do is they will go through any type of a user creation process and get a valid account and from that perspective ones they have a valid account that get some more information and they can begin to see what that what their authentication gives and what their account permissions allow them to do in this case he was able to return multiple agreements another scenario here and this was a little bit older a little bit about two years ago now in 2018 but this was when the United States Postal Service first pushed out their you know track your package they referred to as their informed visibility system this is a terrible rollout gave out tons of this

wasn't the only vulnerability that was detected against this application when it was first released but in this case here is very simple the fall out any user logged in to the system to use an API to see account details for other users and so very simple here and as you as we can see or as we will see when we get into this this isn't it this isn't a situation where we're looking at I'll come back to the screen here this isn't a situation where we're looking at a traditional attack signature there is no there's no malicious content here from a traditional perspective that would say the attack request is incorrect or as bad it's not malformed it's a valid API

request everything there's no parameters that were inserted here but it's down to the actual value level of the parameters that is the mistake here and so this would easily bypass any type of application firewall rule you know there's other solutions out there that are you know doing some black listing and white listing of [Music] of traffic of API requests but there's nothing wrong here in the request you have to compare the actual value that it's in the cookie or is in the token against what is been requested and so is the user ID here that is in the request does that match the user ID that's in the response and if it doesn't and that's something that we have to look at

and so it's that of an actual parameter value level of how we would have to compare multiple values in the request and in the response from security perspective and so very difficult difficult one to to remediate okay so the next one we have here was on a two broken authentication broken authentication can really highlight any type of credential stuffing or I can't take over issue here against any type of API login endpoint I see my time something to go a little bit faster here but what we have here is you know basically Java web Java web tokens are becoming more and more popular if not the one of the main ways that API is handle the authentication to

where it's not necessarily super secure there's there's definitely vulnerabilities out there and how that is handled you know it's not difficult for an attacker to decrypt or to open up what's inside that token and look for a sensitive data or vulnerabilities as to how they could then break an authentication of the one thing as well is oftentimes businesses will have their standard form based authentication in their traditional application and then they're going to have multiple possibly multiple API endpoints at hand authentication and so as businesses move away from you know one form of authentication to another there is multiple ways no or multiple doors malware authentication takes place and so the API endpoints may not always follow

the same visibility or may not be integrated into additional security solutions like the traditional login pages are in the beginning so be aware that now this is a good one here excessive data exposure I don't know if it's any attack is good but I'm plenty of good examples of how this happens and when we think of data exposure right away we think of you know a database breach where somebody exel traded millions of rows from a database through a traditional maybe application sequel injection they got inside the business whatever it is but in the API world this really has a different connotation so different meaning it's not about getting data from the database but it's about

exposing sensitive data where it wasn't required and this is an example now the OWASP gave which isn't good there's plenty of dating apps out there and this was a case where just through a simple request you know even if I turned in this example even if I turned my privacy settings on meaning that I don't want my location to be shared in the application all that privacy setting did was remove those fields from the user interface from the application it did not prevent this server the server from responding with that data so in this case here I simply would you know if I put my privacy settings on okay great my data's not shared well that's not the case if we actually

look at what is included in the response my latitude and longitude is still there even if I wanted to hide my photo I don't want to share my photo that's ok either because the actual URI the URL to my photo is included in the response still so it's it's just hidden in the interface it's not you know preventing that data from being returned and so you can kind of refer to this as client-side filtering which is not actually preventing my data from being exfiltrated and so this is an example of what in the API world excessive data exposure means and from an attacker perspective if I wanted to take this a step further and just you know continue

to friend people find their location we even saw here during this attack you know they were able to get down to and say hey there's even people using this application you know supposedly in the White House now somebody could be spoofing this location or whatever but you get the idea all right so in this scenario so from a remediation perspective you also want to have something that is investigating the response data in AP is we can see the difference here from a traditional perspective the traditional security tools like a waffe are only inspecting on the request and not in perspective the response we look at a API security you have to look at the response as well

as what you're sending out resources and rate-limiting this is another one here so we have things like you know this isn't about networking where I came into the API space I had to kind of change my thinking a little bit where you know in the you know you you think about the network requesting or limiting the requests coming from the network side from an IP side here again this is more about the response how much data am I trying to return from these microservices you will see very commonly we have you know a page size we're only gonna return 250 items remember these microservices are usually a lot smaller implementations a lot smaller servers where it could be very you know it's

very possible to overload those so you're not going to cause a lot blood looking to take down an entire website you're just looking to cause the micro service to return too much data to where it can't handle processing all of the data that's being returned so we have to do checks here on exactly you know what the page size value should be and then get notice here it's a completely legitimate request the attack here is that I'm increasing this value to a size where the Micra service can't handle it I'm going to crash it the other thing here broken function level authorization now what we're talking about is changing you know the actual method calls so the

post now I'm supposed to this API endpoint expects maybe a post to be received from an attacker perspective what if I change that to delete what if I change from a you know post to a put is there checking involved there that the server will either as well process an incorrect method call to that endpoint and this is very common I see this is a first-level from an attacker perspective as you're looking through the API endpoints what what can they look in the access what next is mass assignment can I change you know the my permission level by including additional fields alright so maybe I'm a syndicated as a user I'm gonna go through create my

user account I now have just a basic user account and now I want to elevate my privileges on the API you know can I do that and this is a very common see this a lot as well you know gave his admin equals true change my role to administrator all trying to find elevated privileges is that then gives them access to additional additional endpoints or additional permissions to request data this was an example that I saw here just recently where during the registration process you know they can detect here in the beginning I'm trying to register in my email the response is nope email is not verified that's an incorrect email we changed that so the attacker just saw

that response and said oh well I wonder if in my response I tell it that it's verified he did that came back and now the email is verified so this is an example here of doing that massive Simon that's not so much from the roles but we can still get through here basically what you can do is include the parameter or insert additional parameters that aren't in the standard request that we see but just modified a little bit anding it we want security miss configuration not now we're getting to some of the ones are from the traditional Oh watch top ten but here this is simply when we can cause an error or in the response

you're basically leaking data that helps the helps the attacker understand what the process is or understand what you know services are running and then they can maybe craft specific attacks against that we still have injection attacks here and what's interesting and what I've seen is that just because the traditional application has you know like all your traditional applications are behind a wife you know the sequel injection and the cross-site scripting attacks aren't as prevalent but how about your API endpoints because you know those are created maybe ad hoc maybe they're in different environments they're created more you know frequently there's rapid development in the API space so those API endpoints aren't behind this traditional security

solutions that we have leaves them available for these injection attacks and maybe you know from a cross-site script perspective you're inserting something that then has takes a hold on on the website side as well I've seen it as well so it's like you know the websites more secure but the API endpoint that's on that website is not and so I can access that and have almost like a side load into the website now improper asset management and the last ones here as I'm warning at them are all about the traditional approaches we still see these a lot but basically you know the api's are definitely a newer space security teams don't have the same amount of visibility or just haven't

been provided that in the business and so for the security team to discover and identify these api's is more difficult and so you need something outside of just you know good document and practices to discover and identify your API thanks Gabe and how you know how big that grows the other thing I've noticed and I'm sure we've seen this as well as api's have versions so you'll push out a new version of your API one two three four there was a time I was working you know integrating with Salesforce I think at that time the era one version like 38 or 39 of their API but the version I needed was version 27 because that's when I was compatible

with the solution I was deploying and I could go back and just change the version number in the URI and get back to version 27 and that's what we see here as well so improper asset management you're promoting these API and the old ones are not getting deeper and so you still have exposure to those api's that haven't been updated so I'm going to pause there answering the questions that might be out there

no worries so good

well well guys I hope that was good I want to give time to rotate on to the next one my time is about up you can find me out there on slack and anywhere else and I'll answer any questions you have appreciate your time and look forward to the rest of the conference