BSidesGVL 2020 - Jeff Clare - "API Security in Depth"

so good afternoon everyone mom I'm here today talk to you a bit about API security in depth we're gonna go through kind of some of the ins and outs of API security what that means to you know someone's just getting into the as well as we'll talk some more about some common API scenarios that might increase the amount of vulnerabilities you have and as well start talking about how this all ties into sort of a proactive security campaign including using a wasp as a resource so Who am I so I'm from a company called checkmarks we're based out of Israel I am a sales engineer covering all of Canada so I'm actually north of you guys right

now I'm in Toronto just north so if you hear my Canadian accent you are more than welcome to laugh at me that is okay it is actually very cold up here it's probably 15 degrees Celsius I think that's about 60 compared to you guys so we're a little chilly a little unseasonable cool but I'm hoping everyone else's have a great day you're watching this outside on a patio with a beer or something that would be great I've spent 17 years before pre-sales in a Berry's deaf roles I started off small FinTech in Toronto as a junior developer using a language called progress which you don't hear about too often anymore and then I sort of worked my way through

that company for 17 or 16 and a half years actually there you know making my way up to a system and integration architect before I decided to come over to the dark side with sales so I have spent some time at micro focus and Hewlett Packard Enterprise more of the performance testing functional testing lifecycle management site but I joined checkmarks just over a year and a half ago I have always you know as Deb you kind of have a strong belief in security awareness and always learning more but it's always a good tool so that's who I am I do want to remind everyone before we get going because we're running out of time the raffle closes at four o'clock

so if you would like to get a Yeti cooler I can personally stand to buy those products they're actually really fantastic it's the only one that survived two kids and a wife who is clumsy I would make you I would give you a moment to just go and register for that now you've probably got about 13 minutes left to go so drop your name in and hope for the best you can't play you can't win if you don't play so we're gonna start at a really high level I'm gonna take it right from there all the way down to sort of seeing the the vulnerabilities in action we'll talk about some examples and some sort of

best practices and ways to detect them and why we think there are a new threat landscape when it comes to api's and and how the OWASP API security project will kind of come into all that so for everybody who's new API stands for application programming interface pretty common stuff everyone usually knows what it is that you guys pretty nice short form for it to find out what that means we kind of have to go back to the holy grail which is always Wikipedia it's either that or a gardener slide in most of my presentation so I got my checkbox here an API is an interface or communication protocol between a client and a server I think that's really the

important part there and the follow-on to that is why and it's really there to simplify the building of client-side software it's really taken off in the last few years and that's sort of you know kind of why this this project has come about I'd I'm sure most of you have seen a change in the industry recently probably in a short term even as a little more than four or five years ago probably more than that if you're kind of right in the you know finger of the pulse but really that's where you know more api's is kind of where we're going that's really sort of the universal standard we're using now to let machines talk to machines to let people talk to

mission people and do all the work that we used to do with sort of a more packaged clients a client application like a web browser or something so you know who uses everybody but who uses api's and that's pretty much everybody I mean I can throw all my little buzzwords up here in a sort of a spaghetti of acronyms if you have any more you want to throw them up there let me know put it in the FISC or chat no I'll add it to the slide but you know microservices mobile the Internet of Things you know b2b serverless cloud and and even the spa's your single page applications all these are heavy consumers of API so and that's really

again I'm just I like to put the comic up here it's everyone has something to read but really the whole point of this is that most of modern applications are very well versed in api's and the usage of them is pretty much a core functionality so when I talk about API security what I'm really talking about here is the secure of modern applications and that's really what we'll be talking about today so you might be asking what that means and what do I mean by modern application what did it used to be and we'll go through this in a couple slides but I just wanted to kind of level set where we are here today with API security and how we're

moving forward with that and how it's different from from a lot of the things you've done before you know we really did spend a lot of time and most of us have a general handle on what an injection attack is and as a you know we all have a lot of training at least when it comes to sort of the old or not really I wouldn't call a legacy but a less modern application with less api's but the landscapes changed and really we need to be on board and we need to have sort of a separate area to deal with that because the risks and vulnerabilities can be similar but they're really not the same and it

really needs its own space and it really needs its own light shining on it to give you the clarity you need because you can't extrapolate this out from the old wasta top ten so we're gonna talk about how it's all different how an API based app can work in today's world versus how it used to work when sort of a web browser client-server application we'll talk about why I think they deserve their own attention and why they're different and the threat landscape of it is different than a sort of a non API less modern application we're gonna talk about the new OWASP API security project that sort of hit late last year early this year before the

pandemics and killer Hornets and geez everything else that's kind of gone on this year and we'll talk about that and you know I really really hope by the end of it I can convince at least a couple of you two to join up and help and help contribute great and that's really what you know OWASP is great for it's great for getting all this all together to sort of standardize these vulnerabilities and and if you're interested in this and this is something that that tickles your knowledge then we'd be happy to have you no I don't have some information for you at the end about how to how to sign up for that and then the end of the presentation after

we kind of go through all of that we're going to talk about the actual top ten we're gonna go through each of the items in the list and we're gonna talk about what they are why they're so prevalent and maybe some examples here and there as we go you know as appropriate okay so how are a pee eyes based apps different and really this is this is the the key differentiator here when you're talking about sort of an API modern app and and the way it used to be there's there's a lot of differences but really it comes down to you know the clients devices are becoming more varied and stronger I want and when I say varied I

mean it's no longer just a computer with a internet explorer or a Chrome or Firefox that's running an application and all the work is being done somewhere else and then just served up to you that's not really the world we live in anymore a lot of more that changes from moving the information and the logic from the server to the client so really the server is really more nothing more than a data proxy where it grabs the information gives it back to you but how its rendered to the device you were on is up to the device you are on and that's really sort of a way to allow us to be stronger to give us more

functionality to give us more flexibility by moving all that around and by using these API calls any device can talk to any other device right so let's talk about what a traditional application in the modern application was sort of something well what they do similar first and really you know it starts off with a web browser or in the case of a modern application maybe another device a mobile device an IOT you know wherever you could probably get you know doom running on a toaster so I assume we could get that running on you get an application running on my toaster - so when it comes down to it generally speaking the client or the user will

interact with the application and the application will interact with them and that's that's basically the same across the board and and from the other side the server interacts with the database and the database we turn something to the server so those those two parts are basically the same and the difference comes in to what we do with that and where the work is done and as I mentioned earlier we're talking about shifting from the back end to the front end and that's really the key to parenteral so in a traditional occupation application the client would make a request to the server the server would do some work and it would return a fully each fully realized HTML page that the

user could then use and perform work or play their game or whatever they're doing you know whatever the applications supposed to do it was basically all controlled by the backend server told them exactly what to do and pushed it to the front end the difference now of course is in a modern application through API calls we're actually doing a lot of the work on the front end so instead of just doing a get of what you need you make multiple stateless get calls to grab the information and then the server will grab that from the database and send it back raw to the modern application and that modern application does its work and that's really the big difference

here is where the work is being done so the data comes back in a raw form whether it's a JSON in this case and then it is parsed and displayed appropriately to the user and and really there's a lot of advantages here right there's uh there's a less abstraction layers the the client and the server and the database you usually speak the same JSON language so that's you know it just it makes it easier so there's a lot of things about that that it's really great to happen it's one of the reasons it's really taken off but when I say something is good for me that doesn't mean it's also not good for bad actors

or people who are trying to poke holes or people who are trying to do things maliciously and that's that's the other problem is that while it's great for us and it's great to help us write these scaling applications that do all sorts of wonderful things it also makes it just a bit easier in some ways for for bad actors to get in there and make trouble right and so then we I'm just sort of covering all this year I don't want to talk to each one of these slides but you know generally speaking like I said it's a proxy for data some of it you know it's the clients are now going to consume more data and we'll talk

about that as we sort of get it into the top ten of the API security Oh wasps because the data is just being sent across you can send anything you want but then filter out what you want to see and sometimes this is great and sometimes this causes problems and that's sort of what we'll be talking about here and as well more parameters are being sent and every request that would have been sent in a traditional app and finally you know one of the things that people don't usually think about is that the API is expose a lot of the underlying implementation of the app and what I mean by that is the ability to see the API calls back and forth it

is a lot easier with an API to understand what the calls are and to make educated guesses about other api's that are inside the same system and by doing that is sort of gives you a little more clarity into how the implementation of the app works but it also exposes the risk of it to a greater extent because now with some clever guessing or some intuitiveness or some general patterns you follow you can really kind of get into the api's and understand all the entry points that you can use to formulate an attack and this one is the other big one the user state is now actually usually maintained by the client and not by the server the

service really does live in a sort of a stateless world and authenticates again as needed if you're doing it right so when we talk about authentication and authorization later on you're gonna see what I mean by having broken authorization or authentication you can open all your api's up to a lot of problems because the user state is actually being maintained on the client side as well so knowing who the user is and where they are as well as their authentication back in an authorization back into the server is really some of the things that we really have to worry about now and making sure that all the attack surfaces are covered so when I talk about API based apps I'm talking

about of course the the REST API write representational state transfer you know just for more acronyms it standardizes generic it has predictable entry points and actually one of those entry points can be used for multiple purposes so there's a lot of value out of using that but it comes with just like any other tool it comes with its own baggage so it's good for us again good for attackers so that's one of the reasons api's have been taking off but really what about DevOps knapsack ops if you're a dev sack ops guy I'm thinking I'm not telling you anything crazy here but you know api's changed all the time you know whether you're using a CI CD process

kubernetes docker or any sort of cloud provider it really doesn't take much to spin up a few new api's for testing or for even for the production and and really that's what the problem comes into because you could change it so fast the documentation which is already usually pretty poor it's going to be even farther behind trying to play catch-up and that's really where you start seeing some of the problems with shadow api's or undocumented api those or deprecated API is that are still accessible and still access data right easy and fast but you know how fast is it it's too fast right we don't we don't want to worry about your shadow API is about things that

aren't documented but still can do crazy things or old exposed api's that have technically been deprecated but nobody's seen it and nobody's cleaned it up and it still has access to business logic it really becomes really hard to keep track of them all and to pay attention to all the bits that come in and out so you know a coordinated plan of attack is the best course of action for this it's not all bad news it's not all doom and gloom there are some great news that comes out of being an API based app as compared to a more traditional app and really the big ones about SQL injections with an increasing use of frameworks with object

relational mapping it's not as big a deal I mean yet I would never be that person that says that SQL injections are not gonna be a problem for API calls that is ridiculous but when it comes down to it it's not a bigger threat as it is on a traditional app there's a lot of things that are covering off on injection attacks that you know especially you know using the ORM s and most frameworks have something in place that kind of can take care of this and so we see that they're not as prevalent they're still there of course but they're not as prevalent as they used to be when we talk about cross-site request

forgeries most people now are switching to using auth headers instead of cookies so you know again not something we can forget about but something that's become less of a concern as we've moved forward path manipulations now most of you using cloud-based storage it has a different problem it's really less relevant again it happens but it's really less severe when it goes off and generally any classic IT security issue they're disappearing with more SAS type tools and products and that's just the nature of the beast as we move forward so you know great news out of that at least you know it's not all good and bad news it's it's kind of a nice mix in you really

just have to weigh the pros and the cons against it all to come up with the policy that's best for you so with that you know people you know I would say developers have a lot of training comparatively speaking to when I started in this industry back in the late 90s about security risks and security postures and does any secure applications I think we've done a fairly good job of keeping our our community in abled and educated on the processes and and the solutions to some of these but you know now we're getting this gap where you know we have this traditional security coverage we have these traditional security vulnerabilities and we're a better handle of understanding them and they

come up less often you'll still see the occasional SQL injection obviously any the Hoss top ten are still top ten for a reason but you know I find the exposure compared to even five ten years ago was way greater than it was before I think we're really all coming around to this and that's great to hear but you know a wasp does not really have anything when it comes to api's I mean it's mentioned in the top ten in little bits and you can infer a bit out but you know I I I'm of the belief that you know more and more issues are really relevant to an API centric application as compared to the the needs of like a

traditional application and really that's the gap here so you know you can go to Austin I always like to say a wasp is one of those you know it's one of those great ways to help you develop secure code plus it also looks like a geocities page and that's always important right you really want to see someone who's in charge of Internet security have a page straight from the late 90s that's fantastic I would recommend checking about you know there's a lot to do there there's a lot of information there a lot of ways you can help build more secure applications daily by just following their guidelines and actually I I see a lot in my day to

day job of enterprises and businesses all basically saying we're just gonna adopt a wasp from here on it that's that's our top ten those are the ones we're gonna filter on that's that's a good basis for a security program so you're all very aware of the OWASP top ten there was a twenty seventeen was the last issue there was a twenty thirteen there's a mobile one now but again without the API that was really sort of the you know it's not really just another point inside the OWASP top 10 it's really kind of something that needs to be fleshed out and expanded upon and that's what we do with the OWASP API security project and that's that was

spearheaded by two people a rezulin who's up from check marks with me he is our head of R&D a great guy and a non-jew Canady from traceable both of them work very hard on this together and you know the process was actually fairly simple you know they would start by getting something from everybody else they would analyze what what results we had they put a call out for data and got very very little but then they put a color for comments and got a lot of great information about what people were encountering in the field so maybe it was more secondhand or anecdotal knowledge but it really sort of dressed up what we were looking for

and that's really what are you seeing in the field one of the biggest challenge is someone who's using an API and a daily basis is actually going to do and see and that's really how we help build the list and move forward with it and so you know we talk about our planned project this is sort of the future eyes roadmap as well as sort of you know the present state of the API security project that is available on Olas we're gonna start with the top ten because the top ten is the flashy part and everyone likes it so that's completed I believe we're at version 1.0 now you know we've also released an API security cheat

sheet I would really recommend if you have any interest in this or you think you might have some vulnerabilities to give this a read lots of great information it'll go way more in depth than I'll ever pay I'll ever do in 45 minutes each of the entries in the top ten are completely laid out with examples and some tips and tricks to help remediate definitely worth a read and then from there just like any other place we need to come up with our own application so in this case we came up with the completely ridiculous API project that would be crappy and really like web code like Java vulnerable project it's really - sort of a learning

tool it's a way for us to use intentionally vulnerable app - and we can see all the injections and all the errors and all the API problems that come in in action and I I use that as a good tool to learn it's always nice to see it and you know there's a difference been seeing a video or working on some sample code versus seeing a real project that's up and running and I will say as of this moment the cheat sheets done the completely ridiculous API project is still ongoing I believe they're still looking for volunteers if you're interested in that I'll post a link at the end so let's talk about olaf's the

API security we'll look at the top ten so here they are and you're gonna notice as you go through you're gonna see some things that are that are similar if you're familiar with the OAuth top ten there's you know insufficient logging monitoring most attacks start there or are not answered in a timely manner because of insufficient logging and monitoring it's the same an API is as it is for for traditional applications you can see injection is here at number eight so there's a lot of things that still can be the same but really each one of these is API specific and that's that's the important part here we're not going to talk about this from a traditional

application we're going to talk about how each of these things affect API security and and some common mistakes and some common misconfigurations that can cause them to happen and and some of the consequences I got a couple of nice examples of what would happen in the real life if one of these has been violated so let's start with API one that would be bola bola is broken object level authorization there's no need to Google that acronym we invented it well I didn't invent it the API Security Project invented it but basically what it boils down to here is its assets that are you know like documents that are inside your database they belong to a

certain user and they have authorization to view those user so in this case if user one says give me a document number 1,000 and he is the owner you can see here you can see that no problem it comes right back it does the right level authorization and that user now has a copy of their document but if they ask for another document and they also get it back then you probably have some broken object level authorization and really that's about understanding the credentials that are coming in as you're being authorized to view each of these documents so why is it common it's common because the attack surface is so much wider you know it's not just one or

two points coming in as we talked about earlier API see one of the advantages of API is is one entry point can do a million different things so by chaining together a bunch of API calls you're really opening up the attack surface and so understanding all the interactions between those attack surfaces is what's causing some of the problem here all right so you can see whether it comes through ABC or whether it comes to H then skips a then goes to B then goes to C as a part of an API call B has to understand that it didn't come from a all the time right it's it has to be reauthorized every single time you go in

there right the other problem that comes along this why it's so common is because there's not really any solution that can solve this problem this is really it's left its baked into the design it's really hard to fix like you have to understand this rate of you know you can you can fix it you for sure there's work involved but really if the earlier you get to this problem the easier it is when you have a more universal object level authorization pattern it's much easier to deal with the ins and outs of this so the I don't know if you're gonna get this one but we got this a few times when we were talking about it people are

asking why isn't it I door and I door would stand for insecure direct object reference and yeah it's close its I actually think it's I doors more about direct object references and trying to avoid them whether it's a deep link or a static link to a an asset or an object you know it's a good phrase it I would say it's not accurate or it's not indicative enough of the actual real problem the problem here is not direct the problem here is the API right so I usually would recommend not to be too directed or use direct links too often it's you know it can be a little troublesome but sometimes that has to be

called for that's less of the problem here than it is for the API so I like to term I door but I don't like the fact that it's sort of implying that the object reference should be indirect for every single ID and really what would happen if you everyone ask their developers you know to implement some indirect mechanism on every single place that receives an ID you probably have a mutiny so you know I don't think the phrase is fine but I don't think I think it draws attention to the wrong piece here and that's really where bullet came from right and I will say I do like this Ebola is a South American throwing

weapon and I think that's important to say because it's always nice to have an acronym that actually means something else as well too so what could happen I mean let's take an example we'll take Verizon as an example so daily be ended up grabbing a whole bunch of Verizon's monthly contracts about two million of them based on one really really small mistake and really what had happened was by pinging these api's by checking and trying to grab objects that they were not entitled to Daly found out that anything between 1 13 sorry 1 billion or 1 million and 1.999 million you could technically grab all their contract information without having to have authorization and so it

gives 2 million different customers have been exposed just because of a very simple configuration mistake when it came to their authentication and authorization so that's a great example about the real-world consequences of this right I mean I think you can all imagine it from your point of view about what would you not want someone to access if you know you didn't have the right level of object authorization on it so then we'll go on to number two and number two is a broken authentication and really this is a lot of this boils down to a little bit of a misconception a lot of people use OAuth as authentication and really OAuth is meant for authorization so some of this kind

of comes down when we're using it for authentication and authorization you know if we look at this API call here we can see there's two main ways that broken off like the authentication happens one is going to be a lack of protection and the other is going to be a miss implementation so if we look at this API structure and we understand we have three fields that we kind of probably want to protect whether it's their password credentials or whether we've forgotten our password or whether it's our mobile login so I would expect those three to have some sort of extra protection as well as just general rate-limiting we'll talk about that n/a for that's a couple away from now but

rate-limiting is also something that comes into play here but you know when I talk about X protection I just mean where's the account lockout mechanism where's the CAPTCHA you know is is there any protection from credential stuffing is this going to become an Oracle password checker for you if you just load up a bunch of passwords and check over and over again so without these extra protection without these rate limiting you kind of get these broken authentication error message not error messages sorry I broke an authentication problems and some of this can just be exposed normally and some of it can be very very dangerous and some of it's also miss employment ation right how

many people are using JWT did you know that the algorithm for JWT can be set to none that's troubling you know it's it's really not any protection at all and that's really a miss implementation that's great for you know your staging environments rollout environments but it's really not something you've won in production as well you know the service doesn't validate the OAuth provider your passwords are stored without salt etc etc just general Mis implementation that's really what causes a lot of broken authentication errors right so so why is it so common well it's common because the endpoints are exposed to anyone by design right that with it is designed to do that we are encouraging

people to do that because it exposed to everyone so that everyone can use it right and again we you know there's some misconceptions OAuth is not tenth ocation you really shouldn't be using API keys for users authentications right as well there's multiple authentication flows in most modern apps right whether it's IOT mobile a legacy login some sort of deep link lots of ways to get authentication here and and you know checking all of those things is hard and sometimes something slips through ok onto number three so number three is our excessive data exposure and this problem really boils down to what we talked about earlier with that we've moved the work on the data has moved to the front

instead of the back end right and really that's that's the problem here so you can see here we we make we have a mobile out the voice we have Bob's profile that's obviously a minion dating app and we make a call and we get that user's profile we know this guy's user 717 so we get some data back so you can see on the the actual screen we're only showing the name and the role in the hobby but if you look at the actual JSON that gets returned you can see there's some more information that that maybe shouldn't be there in this case specifically the address is coming through so the fetch for this user is giving data that while

not being rendered to the screen and not being displayed to the screen is being suppressed it is still viewable if anybody is watching and you know there's something to be said for maybe personal information should be secured and shouldn't come across and and some of this you know we'll talk about some of the reasons some of it's a future proofing reason some of it's more you know just not thinking about who's gonna be consuming this data or trusting I play a lot of video games so I'll tell you right now I learned a long time ago we don't ever trust the client ever everything should be done server-side anything that the client can do should

only be able to do what the data is provided and I find you know watching cheaters and video games and and you know anything that's offload to the client always causes so I've had this drilled in my head since the time I was about 15 years old but you know it's really something to kind of consider that you're giving the client data but you cannot be responsible for what that client does with that data right so again filtering sensitive data on the client site is always a bad idea so why is it common because we we encourage everyone to do this generically and that's really the big big problem here and and by problem I mean it's also a benefit you know if

you're using a generic function as a to JSON and you're just dumping it out there you know if you're not thinking about who's the consumer then you're not thinking about who's seeing that data because it really doesn't take a lot of work to see the actual packets coming back and forth instead of looking at in the application that's very easy to do and it's very easy to understand what you could what kind of trouble you can cause with that and for an example does anyone know what three fun is so I know virtual this this works much better in person but but three fun is let's keep this safe for work three fun is an

application for like tinder if you think to people is way too boring for you that's really you know maybe we'll just leave it at that that's no three is no longer a crowd let's just leave it there so what had happened is Alex Lomas had done some testing and as they pulled back user profile not only were they getting the the things that they would expect maybe their their gender or you know a photo or you know what they're looking for what they were actually sending across was latitudes and longitudes and their orientation and a lot of more personal information that was never being displayed but was being passed across and again some of that's

future proofing some of that's you know if I give you all the data now if I need to add a field later I'm done right there's not much to be done there but without considering the target audience you can get into a lot of trouble and I think the best part about this is Alex took all the data that he pulled back out and map the GPS coordinates and I will present this without any comment whatsoever I'll give you a second okay I don't know I'll get them from Canada so I don't know we're in the white house that actually is but I think we can all make some jokes there right I think we're good okay number four number

four is going to be lack of resources and rate-limiting we talked about this a bit earlier and so I won't spend a lot of time I think I think we intuitively understand what this means and really that's you know if there's something exposed it needs to have a limit it needs to be defined you can't just throw something up and hope for the best right whether it comes to the number of files strings the frequency of requests all these things need to be considered because if you don't do that you're basically setting yourself up for denial service attacks or you know credential stuffing and really if you don't have a rate limit on something that's doing

credential stuff and you've really just done a password Oracle right where you know I give them all the data to check all of these credentials that I've accumulated over and over and over again to give me my hits as quick as possible writes the other thing I see a lot when it comes to API is is if the token that you're getting back and forth is a small enough number and you don't have rate limiting it actually doesn't take too long to make enough API calls to go through the whole run up number six six carat or six digits is not that it's not enough so if your brute forcing it you could definitely send in a whole

heap loaded data coming in and verify you know this token what other data is at work against give me everything you got so there's a lot of great attacks that come out of this and it's all based on just limiting how often someone can access the resource are limiting how often they can make the request okay and up to five what have we done we're doing good here so five is a broken function level authorization and this is really the brother or sister maybe the sibling of the first one again Billa is going to be a new acronym don't look it up I don't know what it is if it's something else ahead of time I do like saying bit

flow though so in this case you know if we take a look at our API layer we can see you know most of them follow a similar structure there's a public API anybody can access it there's an internal API for your devs or your internal users and then there's the admin API that does all the work for maintaining the API is maintaining the users maintaining the application so you know that's fine and a min makes to the admits totally legit I need to delete this user that's great the problem comes if a regular user can also make that call and you know it doesn't have to be malicious but it seems likely if someone's making a call

to an in mini API it's it's at least partially malicious right and that and that boils down to you know in this case we're talking about functions and not objects and I think that's the difference between the Billa and the bola if we're going to use those acronyms so again it's like a sibling but it's similar but different right this is a function so whoever has access to this function should have the right credentials on the right authorization so as compared to an object instead of grabbing something it's performing something I guess that's probably the big difference and why is it common well it's common because function level authorization can be tricky lots always to implement it rounded code

level configuration API gateways the list goes on you know at any time you have some confusion about ways to implement it and you don't have a standard sometimes they slipped through right and as well it's easier it's easier to detect it in an API because the endpoints are more predictable you know when we look at a sort of a traditional app you can sort of see the you know to get the user profile is this string but to post to delete it user you're doing a post with a bunch of different parameters it's a lot harder to guess that right you could you might be able take a stab at it you might be able to figure it out I mean sometimes

an action equals delete and a user ID is a user ID I mean it might work but when you look at an API I'm getting a user and I'm deleting a user right it's very very predictable it's very easy to guess and that's really something you know it's the the curse that comes along with it you know you get that phenomenal cosmic power but you also expose the methodology behind the implementation of that app as well and a lot of easy guesses without the right security can get you into a lot of trouble okay six-six is mass assignment and this one I would say is probably the the sibling or the cousin of the exposure problem so

the data coming across has everything you need even though you're suppressing all the fields to be displayed in the application I only want to display my name and my hobbies and where I where I live or a photo but we give them all the data that's filtered out and then someone can see it this is the opposite so in this case you know all of your data set values are pushed back towards you want this to the server to save right so really this is about putting data excuse me sorry this is putting data where you know this should only be safe values and this really happens where you know you can see here in nodejs you can see it in

rails you know by assigning it like that it could contain sensitive data that you shouldn't have access to right so legit request would be you know post new users things Bob and here's his pass through one through six if someone understood the rules and understood all of the fields that were going through and there was no checking on those as they were being committed back I mean it would be up to the user to set their rule to be admin and obviously we don't want the users to set administration rules with their own roles but if you're not checking and you're just assuming the data coming back is going to be clean you could get

shocked by finding out that someone's got admin access because they just pulled themselves they would right and again this boils down to it being easier to discuss sorry easier to find right this is just a get method it's it's easier to instead of guessing the properties I get method will likely return me the data I want so if we go back right if we do a get here of this user we would probably get Bob in his password maybe nice password it bailed me at but his role might be there so that I know that role and then I know I just need to take that role suppress it add it to the commit and see if that

commits grabs it if you're not doing checking now I'm in a minute easy as that if we're looking for another example I kind of like this one you know if I put a video into my API my API is storing videos I can see I have a clip and I'm putting it up there by using that I can understand the name of the video files but when I pull that video file back I can see that I have an ID I've got the name of the clip and I also have conversion parameters and you know if you take a look at the minus V and your codec you can see that there's obviously some sort of command line CLI

going on behind the scenes to help convert this video over to you if you're not checking that field it's very easy to make a put statement that sets the conversion parameters you can see here I put the minus V codec and I might have just slept in a little extra for them and you know again this one's probably fairly harmless because I don't think Windows is a big product and it probably will never catch on and it's probably more of a probably great so there could be no harm done from there but you know nothing grates nothing Goods ever on windows anyway so you know that's the kind of thing you need to make sure you have

validation against those if you're committing something back every field has to be checked right as usual do not trust the user the user will always try to do something even if it's unintentional the next ones number seven and this is really more of a bucket right this is all the things that I think are important we think are important but are not big enough to be their own sort of issue on the top ten you know whether it's a weak encryption or unnecessarily exposed HTTP methods a lot of the stuff is pretty simple stuff and a lot of it comes down to being misconfigured oh sorry right so you know having all these things here again it's

a kind of a bucket but really all of these are important they're just not important enough or they're not as widespread enough to be their own entry number eight injection so I think the first question I get every time I ask this question or I talk about this is why is it number eight now instead of number one cuz when you look at the Olas top ten I think everybody knows that we probably all have a tattooed on our arms SQL injections are the worst they're number one and that's true but as we talked about earlier SQL injections are just a piece of the injection puzzle if you actually look at the top ten three of those are actually

dealing with injection errors right whether it's injection whether it's XML external entities excuse me or whether it's a insecurity serialization there's lots of there's lots of injections here but they're all big enough to have their own category on the OWASP top 10 but sort of let's say I said C serialization right yeah okay so I did say to say okay so those three are there they're big enough to be their own groups when it comes to injection an SQL injection is really the big one but the reason it drops to eight is because SQL injections are not as big a deal anymore and not that they're not dangerous and not that they're not something to deal

with and you know I will fight tooth and nail this is the hell I'm gonna die on if you tell me that generally speaking SQL injections are fine but from an API point of view they are really not that as big a deal as they used to be right we talked about object relational mapping or ORM you know it's it's not as big a deal as it used to be right increasing use of SQL ORM s it really limits the exposure to it so it really drops the the threat level of injection errors in a good way I think I think that's something we all can learn from and then we sort of roll those all into sort of injection errors

that are still something we need to concern about but it's not as important as a broken object level authorization right api 9 improper assets management this is again these are probably the most important things I can tell you but they are conversely also the most boring things you will ever do in your entire life documentation and taking care of risky api's right so when we talk about a lack of documentation we're talking about shadow api's right we know this is there's a process in version zero that never got deprecated you know exports all users and do we have any documentation on it probably not looks like it's legacy so how do we not deal with that how did we understand that

that goes there and and we don't even know if someone's gonna use it to attack because we don't have any documentation on it and as well you know exposing risky api's instead of going through the API gateway if you find say a beta API that was set up at one point for testing we set up one point for deployment it was set up for a bunch of reasons that aren't production and it still interfaces with business logic you just opened up a door you've got a risky API that doesn't have the same checks in place that everything else does so why is this such a big issue it's an issue and we talked about some of this as

we're building towards the end here it's because the CID CD is because of cloud is because of kubernetes it's you know you can deliver so quickly now and not document and I know that's sort of the agile mindset know not that there's no documentation but a documentation as you go you know you could scale up so many API so quickly that you'll never be able to keep track of them all if you're not doing proper documentation know whether you're keeping this swagger or you know I don't really care too much about the tool because to me the best tool here is the one you're using it doesn't matter how cumbersome it is if it works and

you're getting documentation you're getting value out of it that's the right tool to use but you got to do something right then API hosted I've been forgotten we were talking about that with a sort of more deprecated or risky exposed api's right it gives you the ability to poke your way into the application without having to go through the same checks and balances that you would have as part of them route the live application and as well we have environments that have weird names that we're sort of spun up for a moment and that just never brought back down there's a qa3 old app.com banana or whatever right oh we all put crazy names on things and then finally we got one

last left one to go and this is the same as the one from API assert from the OWASP top ten boil blades again very boring but very important it's really understanding that every major incident that breaks out is never stopped in time due to insufficient logging and monitoring it doesn't matter if you're logging an attack has happened there's hack a login has happened repeatedly thousands of times a second if nobody's raising alarm about it so yeah you might be able to go back and see it but you know the lack of that monitoring and any sort of timely response is really what gives them the go-ahead to get what they need done whether they've got time to

take that because no one's reading the logs whether they don't have the proper alerting mechanisms or whether there is a breach they don't collect enough data actually understand what was taken all of this stuff sort of law comes into this big envelope of insufficient logging and monitoring but it is so key for both during an event and after the event in diagnosing it all right so we only got a couple minutes left so I'll just want to blow through a couple of these quickly if there is questions I can definitely take them in the discord afterwards I don't want you guys to miss the the draw and the final closing remarks and track one but there is a

mailing list you know if you want some discussion points if you want to join in the conversation if you want to get lots of great tips and tricks and some documentation and you know some strategies I would recommend joining this you know scan the code or go to the site and as well we'd love to have you contribute I know that this is not a check mark projects this is more of an API but it's something I'm pretty passionate about you know just generally security and also about API is from my development background so we'd love to have you come along and join us if you think you've got something to contribute or if you just want to follow along with

us we'd be happy to have you over on github