Security Is Key: The Vulnerabilities Of API Security

hi my name is Joe uh I'm going to talk about this the security and looking at of apis and looking at how we can look at vulnerabilities within apis so first of all who am I um as a picture of myself if with my hair if it didn't get attacked by the rain this morning um I I work as a threat intelligence Analyst at a company called cacks I've also worked within UK policing and the cyber crime unit and I also uh just recently graduated from with a degree in computer science from the University of York I've done things like for Intel pen testing security research and I like researching things like TR actors things that are

com on and blockchain security as I seemen to talk about probably too much um so what is an API well again there's a nice definition there by IBM which if you really want to read I think it's always nice to start with the definition I'm not going to read it but it the most important bit I've put in bold there which is that it acts as an intermediary layer to process data transfer between systems so it acts as this intermediary stage between our systems that we're trying to operate with and so why are they so important well if we look back at when as Google nicely told me in 200000 when apis were invented by

Salesforce um since then they've basically become an absolute Staple in development and Technology 90% of developers in 2020 were using apis as part of their projects 70% of developers are expected to use more apis in 2023 than they were in 2022 and 40% of companies now have over 250 50 internal apis as part of their tooling repertoire which goes to show how important these are as a sort of part within this ecosystem so I'm pretty sure everyone knows what an API is I thought I put the slide in anyway not padding I promise um core components of an API so you got a client client makes a request then our API acting as that intermediary layer reports that to our

server our server responds and then the API replies right to us as the client now that's nice and simple but we're missing something from this basic model that's authentication so API keys are what forms that authentication layer for us in apis now there's obviously lots of different ways API Keys as we know them as a token are probably one of the most common ways that we've seen um and it's important to realize that compared to the normal username and password sort of system of authentication API Keys as a token provide both identi ification and authentication so not only does it authenticate us with this service but it also identifies us with this service posing it actually as a double layer

within that sort of threat model effectively acting as the username and the password in most senses as long as your API doesn't also Implement a username if we're just using the normal token model so let's have a look at why API security and the current landscape of API security so why is it important well as apis become more connected as part of this infrastructure in the te sort of the technological world is important that again they're built in this secure manner now 94% of people salt security do an excellent report on API Trends and I could come up with my own numbers but their numbers are excellent and in their report they found that 94% of people said that security

problems were happening in apis that's a very large number and given when we look at how security reports are being reported it's important that to note that also that number to admit hey we've had our apis compromised is a really big and quite scary number they also had sensitive data exposure which is not good either we'll look into sort of some of those vulnerabilities and why they're why there they cause such effects later but again not nearly a third of that is it's not great and when we got 17% sing data breaches which are then getting propagated through marketplaces and then your data being sold that again poses almost another level of threat so why why is a threat actor would I

look to Target apis now I think there's three main reasons when we look at this first one it's a great external endpoint around access point quite commonly because of the way apis are we need them as these external end points where people can connect to it from an external entity to interact potentially with the system now often if we're looking at sort of external end points within systems that you may be managing the security of those is quite locked down you might have one specific purpose for it or one specific usage we can lock it down to really specific things we can out all the extra things but this the problem with apis is because of their

larger scope they're expecting users to input things there potentially you're you're exposing that now to user input and only an intended user input rather than the normal extend it's usually maybe there's not expected for tons of users to be putting things to it but users are meant to be putting maybe tons of different information and that's expected and there's also lots of scope for potentially what it's be interacting with internally as well and the other thing is this threat of zombie apis and this is becoming more and more of an issue as apis now start to become almost dormant we're having developers build apis and then they become part of an infrastructure and then developer leaves

the company and now the API is still there 10 years later and this zombie is now living in our Network nobody can really it's difficult to maintain they might not be a practive documentation and as a threat actor that's a perfect start for me an API that might not be maintained that I can hit with all my attacks and maybe one of them gets through and maybe they don't even know they've still got it open if it's not been properly managed in that sense so this is why you might want to Target an API how do we do it so let's begin to look at the vulnerabilities of API security so how can these sort of apis

be targeted in the wild now I think it's always important when we look at things like vulnerabilities CU they are so broad to break them into categories and in this sense I'm breaking into almost what it affects and for me I think from having looked at this these are the three categories that I think probably most importantly affect apis so the first we have is a tax on code second being a tax on infrastructure and the third being a tax on developers now I'm not saying this is a complete list but like when we look at the sort of apis that are being seen and being targ today by threat because I feel like this kind of encompasses that

and there will be lots of other things that fit within different categories or maybe in two categories but so sort of just to help generalize the way we should look at potentially look at API vulnerabilities this is the way I've decided to do it so we'll start with the tax on code and I've decided to coin these the broken Brothers I think that's probably the best way to look at um API code attacks and this is basically these four vulnerability types called which is broken object level Au authorization broken user authentication broken object property level authorization and broken function level authorization so while these all sound very similar and don't get me wrong they are um they also

occupy the top four of the five on the oosp top 10 API security list in 202 in 2020 2022 I think it was 2023 um but also in 2019 as well like these are seriously some of the most important things I think so when we look at attack on code these are the ones we should be going to so what do they what are they so broken object level authorization is this a Target is targeted through manipulating request parameters so for example ID numbers are probably one of the most famous ones API takes an ID number for an account what stops me changing my ID what if the ID of zero is the admin how

can I change that can I access no information and does it respond with that information not checking how authenticated I am to see that now that also comes under idore which is a much broader sort of vulnerability category but it's kind of also in a similar m in the API sense but the idea that we can manipulate those IDs and potentially gain new information and this this kind of comes in apis due to this this problem of client client State tracking is really difficult because as an API I have tons of clients connected me all the time they've got a token and that's really useful but how do I track the state of them what are they doing have

they changed their authorization becomes quite hard because we've not got this constant connection of authorization that I can use to track that state then we have broken authentication probably the most simple of the lot it's just the inherent exploitation of these authentication mechanisms put in place to allow us to access the API now this happens again with passwords and all these other things as well but in apis again because we sometimes have this singular token we're not required to find identification and put authentication because if we can get that token we can get both so we can compromise tokens through fuzzing we can do it through side effect analysis and basically assume permissions we weren't

allowed to G we then have broken object property level authorization Cy not going to say that one later um It's a combination of two vulnerabilities which I think is the best way to explain it it kind of got combined a few years ago and it's the combination of excessive information exposure and mass assignment now you can kind of Imagine This vulnerability as almost like the Opposites of each other now as the same thing either my API exposes a lot more information than it's necessary or allows to process a lot more information than is necessary so this is quite common for example say I want just a specific number maybe just the length of a number of items in

the database sometimes it might be the case that actually the whole database is returned as part of that query and the length parameters at the bottom and on the client side goes let me get the length out of that Json object if I look at it I can see the entire database is in there as well now it sounds like silly but I've I've seen this happen the other R Al process more information the API says oh you can put these two parameters in but if you start fuzzing parameters and it actually takes other ones they just didn't tell you this security through obscurity potentially and start allowing me to actually forcefully process more information than

it required and again the fourth one is the broken function level authorization similar to the first one the uh object level authorization but in this time we're not changing IDs but we're actually almost finding other end points on the API so for example again because of this difficulty sometimes in implementing a proper authentication checks sometimes too difficult it's easier Maybe just to have a user endpoint and an admin endpoint and we'll tell the users to go to user and we'll tell the admins to go to admins cool nobody will know about that second one until you start fuzzing end points and suddenly you're getting a response that you didn't expect now if the end point

is is found by that point if there's no extra authentication and levels on top of that it can be trival because again we're relying on that obscurity security through obscurity problem again so then we move to the attacks on infrastructure now now again I realize some of these are sort of attacks on code as well but what the massive impact is actually on the servers itself mostly so we have the two that I think are most prevalent which is we have denial service attacks and we have forgery attacks as well as like a host of other ones as well but these are the two that I think really stand out as the most important and the key thing about this

is we're trying to abuse the server behind the API so the API can still function normally but if we can get maybe access or abuse against that server behind it what else can we do so I'm sure everyone knows about denial service now like know distribute denial service tax and all that sort of stuff can affect apis as they can you can send thousands of requests just at an API and try and shut it down by hogging all of its bandwidth that's that's possible but they also have their own specific like API relevant dos tack which is known as unrestricted resource consumption so the simple attack methodology send request to API go to Step One um the idea is

that we can use up all the resources it has available now that might be in potentially it CPU processing power it's memory if I'm telling it to store data potentially can I fill up its entire storage devices by filling it with files and filling it with information getting it to process more than it should so it's no longer just hitting the mpoint can I fill up the bandwidth of the endpoint can I actually make the server behind it fall over because it can no longer process the requests I'm putting through the API so exhausting those resources allows denal of service then we have forgery attacks so again the whole point of the fory attack is we're trying to again assume or

pretend to be something we're not and in apis that manifests as server side request for TR or ssrf the idea of this is that and this this does require a little caveat but is possible if the if the attacker is able to find an endpoint which takes and then requests a URL which is not that uncommon that's where then we can start to fall prone to that so we can send a URL to this API and it resp it requests the API sorry requests the URL we sent it now that inherently sounds pretty it's not it's not a genuine threat initially but then when we start to look at what that can be used to do

so the common one and one of the most s of prevalent ones and the reason this can be an issue is internal services and numeration so you have an API running in your network that allows me to interact with your systems as a as as an external party now say that has that ability to request URLs and maybe it enriches that URL with some of your data okay what stops me requesting internal IP addresses it's inside your network have you stopped it from accessing your own network can I map your internal Network and start to see oh okay you have this thing running here and you have this thing running here and actually I request Port 3306 oh I get my SQL or I

think that's the right number that was off the top of my head I really hope that was right um but then start to map that internal Network because you basically almost given like a Looking Glass into your network now how can I map the inside of it then you get the information disclosure if it's actually giving me websites or data files potentially inside of there that I can request by doing enough fuzzing maybe I can start to expose that data expose things like passwords and all these sorts of sensitive information that you might not want to expose and also the security mechanism bypass being able to say like I'm going to bypass all these things and firewalls and I'm not allowed

to access this I'm not allowed to do this but if I use through your API suddenly that becomes a lot easier because you've almost let it do that and the final one which again is I think less common but is becoming more of a problem is becoming a malicious proxy so we're looking at quite commonly now at services on sort of darket forums things like that looking to sell proxy services to other th actors to use they don't want to set up their own proxy Pay Me a Tenor I'll give you an IP address you got a proxy sorted so if your API can allow me to make requests and I want to do a Dos attack why don't I just do it

through your API I'm safe you conducted the Dos attack you are my proxy and it's all coming from your network I'm good I didn't do anything your API and that and that's where that issue can start to arise understanding how you can basically be abused by these threat actors making you a malicious proxy now this is the one which I think it needs probably the most Nuance to it and when I say attacks on developers I'm not saying you know the rubber mallet method no you know I'm not not that sort of attack on the developers now normally we look at products of developers as being vulnerable and the target these sort of attacks but is it possible for a

threat actor to actually Target the developer themselves and not the developer isn't vulnerable but can I make them vulnerable or have they done something that I can exploit that might leave them vulnerable and they didn't realize it's not technically a vulnerability in that sense there's not something inherently wrong but by like exploiting in quotes and finding those mistakes that might be left in the development process is it possible to attack the developer or where did I leave my keys so I'm going to use a case study now of a sort of issue this is a sample issue I found um a year ago um basically this sort of thing so this is a case study about the API development platform

Postman so what is Postman this is a public API Network it's effectively a platform that allows users to both build and share apis with others in the community now of people I'm sure have built apis here and it's great but sometimes it's nice to pull from potentially public repositories and what what Postman allows to do is for example I can search I've got on the left there not that you can read that um you can search for like Twitter as it is or probably X now that screenshot probably old and dated um but I can search for that and Twitter has their own API made by Twitter developers and it shows me exactly how to integrate

with that which is a great resource as a Dev because now I can start to build those third parties in there simply and I'm not having to imp imp my own methods which again might leave me vulnerable if I start to try and sort of botch a job together when somebody's done a really good one and they've published it together but that also means that normal developers can share their apis and so it's done through this network and almost like a repository style sort of community so what did I find so I was trying to work out how the telegram API worked and I couldn't for the life me work out how to do it and I

remembered Postman had this searching so I went and I was like cool let's see if anyone else has implemented a tegram API and they had the only problem was they'd also just given it to everybody else um the bot token was there and the chat ID was there with those two pieces of information you click send you send a message to their telegram Channel every piece of information they needed for that API was in there now why well because within if I'm building these apis and testing them I might need to put that information because I can actually run these directly from Postman and so this information might be there for testing the problem we found was some of

these developers didn't realize how public what they're developing was or if they did they might not have realized how many people could look at it so other examples now telegram API okay I can send a message Google ool keys though that's not as ideal um there was quite a few of these um just searching things like Gmail would return lots of things where people have implemented how do I send an email through an API and they've left in the variables their API key and their oowolf key and suddenly oh dear and then you look what oowolf provides and now suddenly there's a lot more I've got access to again because of that identification and authentication if it

identifies and authenticates me on multiple Services you've got an almost like pseudo supply chain problem now it's got its own supply chain which let's not more think about that now it's only 10 in the morning um but then what was more interesting and this is what sold me on it was that actually one of the most popular terms I found was my workspace like testing environment and inside of this example this these were all from again you can't read those because the resolution is not right but inside of all of those were that was one repository or workspace and inside of that was that Salesforce Linkin and Dropbox all three with all the keys that

would be needed to send that message all just left there in plain text now this is what I mean by vulnerabilities to developers I'm not attacking a developer but if the developer going to leave themselves exposed knowingly or unknowingly there's where my issue Falls so we contacted Postman I reach we reached out to them as my company scks in October 20122 and I'd like to say they were extremely receptive and Cooperative in helping us with this issue very quickly they realized this was a problem and that people shouldn't be incidentally or on purpose sometimes just cuz they're not I don't know there's a well nobody's going to see this it's just my key who's searching

them the other thing also to bear in mind as well that was a slight issue just to go back to some of these is that because these are publicly searchable some of these were indexed by Google which means you could also search on Google for Gmail API site equals Postman or site Postman suddenly now I can search it that way as well which also is not great but yeah we reached out to them and they were really useful in providing us feedback since this um I'd like to point out that they have basically the prevalence of this sort of stuff has massively reduced um they basically have a new thing called The Secret scanner and that has helped to

massively reduce the prevalence where Works spaces are being left vulnerable and I just again leave this here but a thanks to them because they were very cooperative and very nice and again thanks for helping to protect API developers basically so what can we take away from this as a sort of ho and this more this case study I suppose well there's two we have lots of these platforms that we use to develop things as as a developer or trying to help build these and they have tons of these potentially for development mechanisms that make it so useful and easy and effective to develop lots of them also have these services to help you kiss stay secure now the

problem is there is always this Triad of sometimes making something more secure makes it a lot harder maybe less easy or simple and that's not always the case but it's important that we do utilize these tools and protection mechanisms because without them that's where then these attacks on developers begin to show themselves the second is also just more about that communication is around that responsible communication now I was 20 I think at the time 21 and I we sent an email and I was like this is going to be scary but it wasn't and it's important that we realize that with this responsible and understanding between researchers and these big companies real changes can be made impacts on the whole

security Community can be made when we approach these things in the correct way so I'm wrapping up now which is good because I'm not overrun at all I just underestimated how long this talk was going to take me so um but the let's have a look at some of the conclusions we can take away more generally about API security and again there was three categories so I think I'm going to boil this down to three points my title is really the the answer it is a pun but you know the security is key it is absolutely vital when we're developing these apis no matter who you think's going to use it or how public it

might be even if it's just internal there's nothing to say when you if you leave the company someone else oh this would be really useful to put externally you don't know so it's important that first of all all users and of all technical backgrounds are aware of the threats posed to apis now that's important because everyone in lots of people in this room I'm sure understand everything I've just talked about with broken object function authorization and all these long words but if I make it really complicated apis can be used by anyone normal people just be like I'll use this and I feel like in the sort of wider security Community things like username and password words

password authentication we've got into the public Consciousness now that you look after your passwords and your username that's okay I don't know if we're the same way with API keys yet and I'm not saying we are or we ar but I don't know if we will because the public con me speaking to my dad I don't know if he knows the word API key if I gave him an API key would he know to look after it he barely knows to look after his own password sorry Dad um but no no he does because I tell him very regularly but it's in it's important to make sure that we are treating those API keys in that way and that's why it's

important to ensure that they are generated and stored securely because then we can prevent this unwanted impersonation and The Unwanted authoriz authentication as well because that's the problem not only can I impersonate you but I also can do everything you think you can do and that third and final point is kind of coming on to that attacks on developers if it's built security is built in from those initial stages doesn't matter if you're deving an API with a single endpoint that only you use and there's a single key doesn't matter who's to say in 5 years time that doesn't become a core API because we found a bit of bootstrap code and we can use that it's important that no matter

the size or the scale of those sort of API projects the security is there throughout whether that be through the platforms you use and using those security mechanisms or just in building in good practice and understanding that's there yeah that's all it for me um has anybody got any questions is there a microphone have I got to do have I got one sorry okay um you discussed uh object level uh authorization and also you know property even property level authorization did you ever find an API that properly implemented that and or can you you know is there a framework an approach or something because we have some old for authentication and nothing for authorization I think the when it comes

to the sort of like are there apis that implemented correctly the answer is absolutely yes lots of these things when it comes to you know just changing an ID and it sounds really simple when you explain it which is why sometimes when you read through that I'm like you know the function level one just go to SL admin and you log in now that sounds like security 101 but almost because we've taken it to almost a new medium it feels like it's not as prevalent anymore so yeah there's totally out examples where these exist when it comes to Frameworks I'm not going to pull Frameworks off the top of my head I haven't got one on the top of my head

and I don't want to make one up for you but there are lots of great resources for looking at developing API security the top 10 list is a great one to go and look at them they give examples of why the where it's being attacked what's happening and the impact for you and looking at those and then taking Approach at your code and Analysis of your code when you're developing those apis or even just having it in that contextual moment of developing developing knowing that that's a thing people might do helps protect you because you're no longer just developing going well let's see what happens and then you have to do everything reactively if you can do it with a bit

of contextual knowledge we can help build that proactive security I'm already feeling defended anyone

else hi thank you nice for the nice information yeah uh so if you you just said about uh in the development cycle and the developers are developing the apis about the main contextual business logic vulnerabilities which is the top five so how can we provide

that see that's a really great question and I thought they might the mic did pick up but you're absolutely right because the this separation of the idea of we have developers and we have security people that almost builds this big segregated wall and Against The Silo our teams now because two reasons a it means our security people go I don't need to worry about the code that's fine they'll do that for me and your developers go I don't need to worry about security I'll develop it they'll find that for me building that siloed approach is absolutely going to lead to problems because then you have to communicate and honestly that's probably the hardest part ironically with apis um so actually

building security awareness and helping developers realize that by I say building in that security it's not the responsibility of some security bu it probably is as well but understanding that all of us have that part to play Within that security landscape and life cycle helps massively benefit the of wider scope would be my answer to that and I think while it's hard to do that I think making that realization and helping developers almost empowering them to believe that they understand these things and helping give them that training to make them feel they can do that is absolutely where you where you need that and that's not to say that you don't need security people giving that

objective view because I've written Kobe look at your ass perfect I wrote that and someone else looks itly laugh at me right but having that inherent understanding of security while you're developing is such a brilliant piece of context for developing really very interesting how transparent should product providers be of the apis they are delivering to their customers that's a great question you put me on the spot there I think it's important and that doesn't mean I think they should there's there's always the argument around like code open I'm not going to go into that because that's a whole talk in itself and no I've got four minutes I think but what I think is important is when it comes that

transparency issue understanding potentially not only when I send data what's happening and it almost again like looking at those three like those the three stages of what I'm I what am I sending what's it processing what am I getting back and sometimes as a user then I can understand why you're processing it in that way what's being processed how is it being processed and by producing proper documentation like some of these platforms like Postman allow you to do in a really effective way to be fair you can start to as a user go I now know exactly why I'm doing that how that's working and why why I'm sending all this information and that transparency as a user allows you to

build your security posture because when you're using these apis they are a third party they kind of build into that security landscape you've got to worry about and if they're not transparent it's just I send data I get back data this is the Black Box you can't manage that risk and that secure Security in there so it's important that there is a level of transparency to the point where you can manage the risk and actually build it into your threat model but again to the extent that that goes I think that's more dependent on your own personal risk model if you want full transparency of all code all endpoints all processing at all times absolutely

that's part of your risk model but I would say that's almost again it comes back to what's your personal threat and risk model as part of the project you're developing one last question a quick one um I mean nowadays graph is been adopted so what [Music] compare has it own pits so how gra land yeah um when it comes to all the different models again I'm I'm not going to try and come up with an answer on the spot right now because I think it is important to bring in the context of what you're doing if you looking again and building that almost it's the importance of risk modeling or threat modeling I suppose when you're building these things rather

than just being a piece of code that works and so if you're looking at that threat model or that risk model going okay why why would we use rest why would we use G why would we use any of any why would we use this model over that model comes as part of that again building the developers and empowering them with that security knowledge allowing them to understand why one might be better than the other in a security sense now there's obviously practical terms as well but it comes into sort of doing that Balancing Act yes one may be more practical than the other but because of that practicality we might be compromised on something

else so I think it's again looking at how you can balance those two things so while I'm not going to say one is better than the other because I don't think there's an easy way to do that when you come into the context of a project you're building something understanding and then actually applying that sort of rigorous not only from a practicality point of view but from a security point of view understanding of why you're doing it is absolutely vital am I good am I done I think that's it thanks you so much everyone