5 Best Practices for Securing Your APIs

all right my name is I'm Jenna fawn I'm the co-founder and CEO of FX Labs FX Labs provides API vulnerability scanning and we help customers essentially protect their applications from attacks targeting the API layer so if you look at api's today there's no question that API is Drive almost any kind of application it's the visible backbone where all the data and the requests get processed and as a result of that it exposes a very large surface area for attacks and that's pretty much evident in all the the latest hacks that we've been reading about in the news and the challenge with securing your API is and we've seen that with a lot of companies is that they fail to have API security coverage to begin with in many cases they'll use some dynamic application security scanning solution or external pen testing efforts and these efforts really don't have enough coverage into the API layer which has an ever increasing number of attack categories so the result is a lot of companies of all sizes have API is leaking data and the vast majority of these API attacks are due to business logic and access control vulnerabilities as opposed to the more widely known vulnerabilities like SQL injection and cross-site scripting right so if we look at the API security categories you know the more widely known ones like the injection attacks SQL cross-site scripting and denial of service they are the ones that stem from coding errors there there are the technical security vulnerabilities but believe it or not they're not the ones that are causing the vast majority of attacks the vast majority of attacks are happening because of business logic and access control flaws that I'll be talking more about in this presentation so let's first talk about the more commonly known API vulnerabilities so with distributed denial-of-service an attacker is trying to overload your api service a lot of api gateways have the rate limiting feature to sort of reduce the number of requests that can come into your application but there are different ways that hackers now are doing denial of service they're doing it with much less number of requests so they're sending in big fat requests and seeing if your code is allowing your application to return thousands of mill or millions of results in one request right the other main type of attack is the injection attacks right so these are the SQL code injections and so on and so forth and in in that scenario an attacker is basically sending a malicious code and seeing if your application is going to process it with the objective of you know tampering with extracting your data so I'll first start with the first best practice on the denial of service attack and it really boils down to pagination and implementing proper pagination in your application and without proper pagination you know a simple search could return millions of hits causing the network to be overburdened and many different types of pagination that you can implement offset pagination is one of the more popular ones and the good news is that most SQL databases support the you know the limit and offset as part of their SQL select syntax and so you know in the case of offset pagination if a client wants to make a request on the first page it would have like a limit equals 20 and then on the second page it would have a limit and then an offset as well so most important thing there's different types of pagination like you know key said and seek pagination but most important thing is to have an upper limit to the number of results that can be returned within your application in order to prevent such a vulnerability now we'll talk about SQL injection and cross-site scripting right so input validation helps you with the prevention of cross-site scripting and using prepared statements in your SQL queries helps you with you know preventing SQL injections right so it's very important that you use prepared statements in your SQL queries parameterize queries and stored procedures as much as possible also not to concatenate any other kind of input data as part of the SQL queries other than the bound parameters and for cross-site scripting the input validation has to happen on the server side because what ends up happening is that the JavaScript input validation that is performed on the client can be bypassed by an by a hacker if javascript is disabled or if there's a web proxy and of course encoding all your input data before sending the response back to the browser so now I'll talk about the the more serious API vulnerabilities that have contributed to the vast majority of API attacks so I'll talk about role-based and attribute based access controls first so with role based access controls is all about the amount of permissions that rules have to your API endpoints and the idea is that if a role has excess amount of permissions that leaves an opportunity for a hacker to use that role in order to extract data and with attribute based access controls it's all about who gets access to that API resource and the assumption is that any application has a bunch of API resources and it should be that only the owner of that API resource who is able to make any kind of action on that resource whether it's viewing updating deleting and no other logged end user or authenticated users should be able to manipulate that API resource business logic flaws are more using perfectly legitimate business kind of workflows in a malicious way so that's pretty much what it boils down to so with our back you know we're pretty much already defined what our back is but the limitations of our back or the the dangers of our back when it's not properly tested is regressions are going to be introduced and these regressions will be you know introduced in the levels of permissions that these rules have and it will create an opportunity to have a privileged escalation vulnerability where a role or a user or a bunch of users have access permissions and that can result in a whole bunch of you know API attack vulnerabilities so the most common example for our bag is the google class case so last year Google+ introduced an update to their platform in November 2018 and as part of that update they made an update to one of their API endpoints which is the people get API endpoint which was originally designed to let third-party developers access basic information about users but as part of that update they introduced a regression a bug and that bug actually instead of allowing third party developers to view basic information they now were able to view the all the sensitive data of private profiles or profiles that are marked as not public and you know the bug was quickly identified and closed within three days but during that three-day period hackers were able to extract you know the account records of more than 52 million users and the problem with these kinds of attacks is that traditional security scanning solutions will not be able to catch these issues because you know the hackers use completely legitimate API requests to view the sensitive information of private profiles because the API endpoint allowed them to do that so as a best practice to prevent privilege escalation kind of vulnerabilities to have a continuous assessment of all your API endpoints / features and how they map to the various rules so that assessment needs to continue to happen on a continuous basis it's not you don't do it in the beginning or the end you have to continuously do it just to make sure that no regressions are being introduced and you need to discover track and fix our back issues as early as possible in the development cycle and you can use an API security scanning solution like the one we provide to automate that entire process actually based access control is basically about applying a bunch of policies to control access and with attribute based access controls there's different types of attributes so an object attribute describes whatever you trying to access like an API resource and an action attribute describes the whatever you're trying whatever action you're attempting to do like read update delete and just like our back it's very very susceptible to regressions because it's extremely hard to actually keep track of all these policies that are controlled controlling access to your API resources and as you're introducing new API endpoints changing API endpoints and features there's going to be a high tendency that you'll be able you're going to introduce changes in which it's gonna allow hackers to have unauthorized access to your API resources so an example in the ABAC scenario is a city a few years ago had a hack and the the hacker actually used parameter tampering but the underlying root cause of what actually ended up resulting in that API hack was an a back validation that was missing that allowed the hacker to access the accounts or the API resources of other users right so what they're what the hacker was trying to do is identify and try to guess various account numbers and they obviously automated that process so that they can guess account numbers like thousands of times thousands of times at a time and and and in that case it was made even easier for them because the account numbers had predictable patterns so they were incremental but but it boils down to you know even if you actually guessed an account number or API resource ID you shouldn't be able to actually read that API resource and in that in the city bank case they were actually able to view the account details by just guessing the account numbers or the actual API resource ID so again just like with our back you need to have continuous assessment of you know both your object and action attributes and for all your API endpoints make sure that you have the proper access controls and again discover track and fix the a back issues as early as possible in the development cycle and our solution form FX labs can automate that process for you business logic vulnerabilities are all about using a legitimate business workflow in a malicious way and it's all about you know the input the the input that triggers the sequence of actions in a predictive business works alright so a use case here is the an online auction and what happened in this case is a hacker was trying to outbid others in a in an online auction and to do so whenever a bid starts happening on an item that they wanted that they would actually perform a brute-force attack to lock out that user from their accounts so that way anybody who tries to actually bid higher is actually kind of forced out of the entire application because they're kind of locked out of their system and the fix here is easy because you know obviously the application itself should not have provided the user names or the full email addresses of the people performing the bidding and also obviously the the lock out was kind of cool we messed up and you can have a different account lockout mechanism right that's more productive but this is a typical example where the hacker used you know a typical business workflow it couldn't have been really detected early on in the process because it's not an actual security vulnerability but it's it's somebody manipulating how how your application was designed and and using it to in a malicious way essentially so again to prevent the business logic flaws you know you need to have continuous audits of your api's and just follow the you know the least amount of information exposed as a general rule and again you know just discover track and fix you know the business logic vulnerabilities which is something we can also automate so I'll just end with you know the slide about FX labs so you know if a lot of companies are not even aware that their API are leaking data so unless you're actually doing the kind of testing around your access controls to make sure that your roles are don't have access permissions that your API endpoints are not allowing unauthorized access to their resources that there's really no way to know whether or not your API is are leaking data and that's something that our solution can provide so we can introspect your API is from your API documentation provide the full security coverage across more than 20 different security categories including the traditional ones like SQL injection and videos but we specialize in the access control categories that we talked about and then you can continuously run the scans and plug them into your CI CD workflow we automate the bug filing and closing for you and then to rumi to accelerate the remediation we also show sample code fixes for any vulnerabilities and this you know the actual timeline to fix an issue so that you can continuously be compliant with PCI and all's been various standards so I'll just end it over here and pass it on to tribes [Applause]

Channel: Nordic APIs

Views: 17,952

Rating: 4.858407 out of 5

Keywords:

Id: 6wRuKgjbBVU

Length: 15min 42sec (942 seconds)

Published: Tue May 28 2019