Common API security pitfalls by Philippe De Ryck

hi good evening everybody thanks for sticking around for my talk about common API security pitfalls before we get started I want to set the scene a bit what do we mean with an API what are we talking about well in general or what this talk is about it's gonna be about rep API so you have a browser who's gonna load an application from somewhere and essentially that application is going to access an API in the backend and it's gonna be fetching data from that API in this case it's gonna fetch some JSON data or send some JSON data and get potentially something in return after authenticating of course this is the web application example the same holds for mobile applications and native applications that use an API so essentially what we're going to cover here is going to be valid for all kinds of types of applications but I'm gonna focus on the website so some of the potential pitfalls will be related to web applications why API security-wise API security is so important well actually in the OS top-10 they're creating a new one for 2007 and in the first release candidate there was a separate issue or separate item for under protected api's and well it actually didn't make it into the second round or the second release candidate so it's removed now but what's important to know is or at least what I believe is that API s-- don't all of a sudden suffer from new kinds of vulnerabilities we see the same kind of problems that we've known for quite a while and we see them reappear in api's we see a lot of problems that were familiar with and they come back in the same form or in a different form causing all kinds of problems or security issues for your API X so we're going to talk about these things I have a set of pitfalls I want to go through and I want to offer you a look into the problem behind the scenes and how you can solve it first a quick word about myself I'm actually here to help you build more secure applications in my day job I give trainings on security on software security and web security so that's kind of what I do I also built an online course about web security which is the web security fundamentals course so if you're interested in that definitely check it out it's still running until the end of December and I'm organizing Segev live next year which is a week-long course on security taught by international experts next year we have the security manager for.net at Microsoft is going to teach a few lessons on net security so if you're working on net that's definitely something you wanna don't wanna miss and there's plenty of other topics there as well but back to AP ice and API Security I'm going to start with a very simple one normally I would ask this as a question but you can imagine in a room with a couple of hundred people it's not going to work well with people shouting answers from all the way in the back so I'm gonna give you the answer for free at first the question what's the most important security thing you can do for a VI HTTPS of course this is the baseline security a requirement for anything that you're building today and it's really really really important so I'm gonna underline it and the reason it's so important is because everything we're gonna talk about today actually builds on top of HTTPS if you don't have basic network layer security using TLS of course then actually all you're doing on top of that is gonna be vulnerable by default it's not that it doesn't matter that you're protecting against other vulnerabilities as well it means that if an attacker is close to the victim there will always be ways you can break your security that is currently in place so HTTPS is absolutely the baseline it used to be hard to deploy HTTPS it used to be a resource hungry used to be expensive today while all of those excuses are no longer valid so performance wise there is almost no overhead and if you use HTTPS to bootstrap it should be to the end over it is even less than a normal HTTP connection and let's encrypt isn't free and automated CA offering certificates for everybody so the main arguments for not using HTTPS or gone so you should be doing this few things if you need to do this free API it's actually quite useful to know that you can actually simply offer your api over HTTPS you're not a web application your api will be accessed from within another application directly so you don't need to support your redirect from HTTP to HTTPS of course if you have legacy applications depending on that don't disable that tomorrow otherwise you're gonna run into all kinds of trouble there and once you've done that the second important thing you should be doing is enabling strict Transport Security and strict Transport Security is a browser security mechanism that you can enable and you can tell the browser for the next period of time I don't want you to send any HTTP requests to my endpoint I want you to use HTTPS by default even if somebody types HTTP or tries to fetch an HTTP resource don't do it use HTTPS you can figure that with a header and that's all I'm gonna say about it yes configure that with the header shown below and you give it a max age and max age is in seconds so in this case it's for a year if your browser sees this for the next year he will never send you an HTTP request again you will use HTTPS by default that's a very very important thing to start with and to use as a baseline for security brings me to the first security pitfall of this presentation so essentially allowing your API to be accessed over HTTP is something that you shouldn't be doing that's gonna cause you problems so if you're still doing doing that phase it out and deploy HTTPS and enable HSTs as well I have 11 more security pitfalls so as you can imagine in 45 minutes it's gonna be quite a content packed presentation I hope you don't mind I know it's late and I'm holding you away from beer and fries apparently but try to bear with me you can imagine eleven issues I'm not going to go into each of these issues in a lot of detail I'm gonna sketch the context of the problem the root cause and I'm gonna sketch the solution that you can deploy or unable to prevent that kind of vulnerability if you have any more questions there's often references at the bottom of a slide so you can look it up or you can also come to me after the talk and we can we can discuss about the questions you have all right let's move on to the next issue I have an example this is a story from Facebook somebody found a vulnerability in Facebook api-related of course and he actually got quite a big bug bounty for that and the problem we found was that if you reset the password of an account on Facebook then facebook sends you a six digit code you have to enter that code to confirm your identity go listen to email or cell phone or whatever and then you can access your account again he discovered that there was a test version of Facebook accessible publicly really where there was no rate limit on the amounts of tries that you had for entering that code so he could simply brute force six digit code for any account and basic base using that he could take over the account of course Facebook quite was quite quick to fix that it was already fixed in the main Facebook version by the way just to show you that one of the pitfalls is allowing unlimited access to an API regardless of what kind of API are offering you should always limit the number of requests that no certain application or certain person or whatever can make to that API the obvious case is denial of service if your limit that then you're limiting the potential for denial of service attack but the second case is brute forcing certain things brute forcing authentication trying to enumerate a lot of resources extract a lot of information from an API even though it's legitimate access you probably don't want someone extracting gigabytes of information through your API there's a lot of strategies you can use there's no one solution for every application so you have a rate limiting based on connection properties for example IP addresses also per user account or per API key so Twitter does rate limiting based on API keys so every application has a different API key and based on that they can decide to limit your access to the API you can also do it per user account or even per region if you have a lot of spread out customers for example actually a funny thing is a lot of API is already offer rate limiting in another form they use it as a business driver to distinguish between subscriber models so you all know the subscriber models where you pay a little bit of money and get this amount of access per month and and so on of course that kind of rate limiting is in a much larger time window and it's not very useful to prevent these brute force or extraction attacks so set sensible time sensible limits on your rate limiting how do you do that practically in an API well actually um there is a status code for that you can use four to nine to many requests and essentially you can also include retry after header so you can inform the client that it should stay away for that amount of seconds and then it can try again because the limit will be lifted and it's very useful to handle in your client side part of the application where you can actually inform the user of the limit being imposed and the wait time that will be it will incur second security pitfall don't forget to rate limit your AP ice seems a bit may seem silly for your application but try to do this and get this right and it will save you a lot of trouble if something goes wrong anyway alright a bit related to rate limiting um is the next one again an example from a couple of months ago from t-mobile you may have heard about this using a phone number you could access account data on on their API essentially so they exposed a lot of information accessible by knowledge of the phone number and what's actually going on there is a problem we know as insecure direct object references so the phone number is essentially an identifier and they use it identifier to lookup account information by itself that there's nothing wrong with that you do that in your applications probably every day so it kind of makes sense to do it like that however the problem is they never checked whether if the person accessing that account information actually should be able to see that information there was authorization missing on that call and because of that you could simply access any account that you have the phone number off so you can imagine if there's no rate limit and you have a bug like this you're gonna run in trouble like team about it with this bug here insecure direct object reference it seems like like a soui problem to have like who would build an application that doesn't check whether someone is the owner of a certain resource and at first sight they seem trivial but I can I'm gonna show you an example this is from a tutorial I found in two minutes of googling well actually 30 seconds I think it's a building a RESTful API in ten minutes so ten minutes is quite short so you can imagine that and you're gonna skip a few steps and here they skipped authorization altogether so essentially you can see this is a function to get something by ID and it returns the object by ID if we deploy this in a real application if the user is not allowed to see all to do so you're in trouble so you can imagine a project starting out with a very simple proof of concept that does something like this and then it starts growing you add authentication of course afterwards you add an authentication check and you simply forget to add the authorization check as well and that's how these kind of vulnerabilities are easy to make this is reading information if you think about deleting or updating or writing information and you have the same vulnerability this may be quite problematic as well so these text slides contain some of the stuff I already mentioned it's for your reference later in case you don't remember all of it after too many beers this evening so use them a slicer online on my Twitter account so you can easily find them and look at them later tomorrow next week whenever you're doing this stuff so the real problem is that many api's do authentication checks but they forget due to the authorization checks to check who is actually accessing these information and doing that is the only proper defense against this kind of vulnerability so you should check it the owner of the resource there's a complimentary technique you can also use non predictable identifiers if you do that then it's hard to enumerate a large set of objects because you can't guess what the next identifier is gonna be so you can use a UID for that for example that's not gonna be predictable it's long enough to be not to have a large space of options and it makes this enumeration attacks very impractical don't use this is the only defense it's not going to be sufficient but it is a good complementary technique to use brings us to this conclusion so insecure direct object references are probably a very bad idea in your API and you should implement proper authorization there so authorization there's going to be a lot of issues related to authorization figuring out whether something is allowed or not and preventing unauthorized access so the next part is we have to check authorization but how do we know who is requesting access to this resource what to do with sessions which we shouldn't use in a restful api of course so how do we deal with that well let's take a trip down memory lane this represents web applications that we used to build 10 15 years ago so you have a server you have some clients and you have sessions stored on the server side this is how everybody built their own first PHP application or whatever of course things have changed a bit we started deploying more and more servers and as you all know session management when you do it like that it's kind of be painful if you want to spin off more more versions of your back-end if you have sticky servers as server-side sessions you're in trouble you need sticky sessions or you need session replication or something like that and that's gonna make your life difficult so what we decided to do instead is we put that information on the client and we have a stateless back-end which is awesome need more more power on the backend just spin up new services there stateless anyway nobody cares and you can scale although every every way you want of course it's a very small change if I do it on a picture I'm not drawing it's a small change in your architecture as well it's actually not that big of an impact but what we're doing here is reporting data on the client and storing data on the client is one thing but we're getting it back from the client and we're gonna use that to make authorization decisions so you can see where I'm going with this right so server-side sessions you had an object on the server the object remained on the server and all you share to the client was the identifier so the data in add object could never ever be touched by a malicious client there was no way to modify the data unless you control the server all you could do was steal an identifier or get an identifier but that's that's about it when you store data like that authorization it a user data a session data whatever on the client it's a whole different paradigm now all of a sudden a client can easily manipulate one parameter if you store the role of the user where the reason administrator are not on the client well the first thing an attacker can do is try to set and know - yes - true the false - true or the no - yes and see what happens and I gives you note there are applications actually give you administrator access when they see that flag so yes it happens in practice what should you do against this well the solution is again not too difficult but you need to make sure that it's in place and a solution is mandatory integrity checks should check the integrity of the data that you get back to make sure that nobody has been messing with the data and if you detect that somebody has been messing with the data you can already know that something fishy is going on and you can preemptively block them or send them to an harmless version of the site instead optionally you can also deploy confidentiality you can encrypt the data you store on a client and that seems a bit overkill for simple user related information but it's very useful if you store for example health care information on the client the kind of application of course if you store that on the client then you actually might want to consider to encrypt the data just to be sure that it cannot be stolen from the device bit for mishandling client side session data so essentially what we're doing there is we're storing data on the client I call this session data but we're gonna come back to that what that means in a bit and essentially trusting that it will be fine and that's not gonna be not gonna end well for you so you have to ensure integrity for one and if you want confidentiality as well that's all fine but how do we do that well you can start thinking about your your own crazy way of doing that now maybe it works maybe it doesn't if you want to be a bit more standards compliant you can use JSON web tokens or Java tokens there's plenty of other ways as well but I'm gonna only talk about JSON web tokens for this talk because I believe that many people actually use them I didn't expect to be able to see you with all the lights in my eyes but it's quite okay in this room so who here uses your tokens yes exactly that's why I'm going to talk about this thing for those who don't use chopped tokens and have no idea what I'm talking about the thing on the left the blob of data that's a job token it's actually basics for encoded and if you decode it you get the three parts on the right the interesting part is the purple one the payload in the payload you can store data claims about about anything essentially they call it claims and it is it's about a user in this case it can be about anything you see two other parts as well the red part we're not going to go into that at the moment but the blue part is essentially the signature of the payload so the signature generated by the server and that signature if the server will be able to check that when he gets a token back from the client and you'll know whether the payload has been tempered to it or not so the whole idea is that you create such a token you add a signature you send it to the client and then whenever it comes back you first verify whether it's still the same token whether it's fell it in in the integrity it's not violated and only then you rely on the data being stored in there and you can take it from there so keep in mind that even though you couldn't read what was in the token it's basic ste 4 encoded and base64 encoding is no encryption it's simply a transformation so anybody can decode that and see what's in there that's why potentially you need confidentiality is a matter for application the job specs are by default they generate signatures so almost every library out there offers functions to generate a signature of certain payload and attach it to the token creating the one we saw in a bit ago of course when a signature is fell out the token has not been manipulated so that's a very good thing one of the drawbacks with this approach is that many libraries offer decode functions that do not check the integrity of the token meaning that if you by accident use the wrong function you're getting the data but no integrity checking is happening so essentially your code looks fine your application works as expected but if somebody comes around and manipulates payload your application will not detect that and that's a problem and a second problem is that simply decoding instead of verifying the integrity is easier so there's gonna be people that do it wrong code snippets taken from one of the the most popular shot libraries for Java so the top example shows you how to verify the integrity and get the data out as you can see the second one only decodes but it's a lot easier so if you're in a hurry or if you simply find two code snippets and you have no idea what integrity checking means or signature checking then it's very tempting to use the second because hey it's simpler less lines of code less maintenance and easy to read if you do it the second way you're gonna be in trouble unfortunately I believe all in my opinion that function should not be called T code that should be bypass security or insecure T code or whatever just to give you a trigger like hey what am i doing there's fellow use for us if you want to do that on the client or you don't care about integrity then sure you can use it function but otherwise you should not be using that somebody starts to be scared it's okay to leave the fixture application I totally endorse that so job tokens whenever you use them you should check the integrity of their of the tokens very very very important all right so job tokens and signatures there are actually two ways of generating a signature for job token I hope I'm not surprising anybody but chances are that some people have no idea what I'm talking about let me give you an overview of the two ways the one we saw so far is signing with a shared secret so essentially what happens there is if you have the payload data and you send it to the library and out comes this very colorful to your token I'm not sure why this is the the logo of the job a library or charge token tingey but it's there so let's use it so what's happening here is you have a shared secret and you give that as input and with that input the server or the library generates signature and attaches it to the token and if you want to verify that token when you get it back from the client the same thing happens so you call library you give it the secret and the library will to regenerate that signature on the payload and compare it to the given signature and see you at a written matches the security properties of this setup mean that anybody who has that key will be able to verify signatures create but also generate signatures so that's it something to remember this key is supposed to be secret and it's the same key for both operations second mode of operation is using a public/private key pair and essentially what happens there is if you again want to generate a signature you use a private key as input so far it sounds the same however if you want to verify signature you can use the public key as input not need not can you have to use the public key as input very very big difference well private and public either the words kind of indicate the meaning a private key is supposed to be private it's something that only you or your application should know and the public key is something that everybody can know and the benefits of this scheme is that you can in the second one you can easily allow someone else to verify the integrity of your tokens without compromising your secret and the problem is that the default mode of operation is a left one because in a single location you can easily use your own shared secret and if you don't have to share with anyone else nobody cares just keep it to yourself and do whatever you need to do it's very easy to set it up very easy to work with however if you have that setup and you're not aware of the second one and you want to start sharing your tokens with other people it might be that you think that you have to share that secret and you start doing that and that exposes you to someone else generating c-e-o tokens that seem to be valid even though they are controlled by the attacker and again this happens in practice so one of the benefits of doing it like this the shared secret is for your within your own trust boundary and if you have to cross that you need to use the public private key pair so never ever share your shared secret anyone else not even your own client application if you share it with your clients so that it can also access the job token and verify the integrity then you're leaking that token if it's a web application anyone you can extract it same for a mobile application so even in that case use the public private key option and you'll be good to go this is by the way the public private key option is how Open ID Connect uses Java tokens so if you log in with Google social login on the website it's gonna use Open ID Connect it's going to issue a job token and it's going to be signed to the private key of Google and the application you're logging in to should verify it with the public key of Google and that's essentially why these things work quite well so depending on the scenario and each of these schemes has a very good use case so make sure that you're using the right one and you're not mistakenly sharing your secret with someone else I'm very good so far all right so we have identity information now we have a job token coming in to the API that sounds sounds about right so back to my very simplistic drawing of that application essentially what happens is we get this information to our API awesome of course in a real system you're probably not gonna have this one block between I have a lot of different blocks and often these different blocks work just like this so one call comes in to the to the big Gateway API and then it starts doing all kinds of things on internal systems and even if you don't have separate servers for this think about your monolithic web application from maybe today or a couple of years ago whatever all of these systems work in very similar way you have a gateway you have a facade where things come in and you authorize it and then stuff happens in the system and the real problem here is that you're not propagating identity information so these internal services have no idea what they're doing and for whom they're doing it they simply know that there's a call coming from the Gateway to do something so essentially what you should be doing is you should be making sure that all of these services have the proper information to make authorization decisions that they have the proper information to make and a useful audit trail this the services on the right they should be able to log that they're doing a certain action for a certain user and never be able to do that then you have meaningful audit logs where you can actually trace back what happened in case of an incident and if you only have that on your entry points then you're gonna be in a lot of trouble figuring out what exactly happened as we see a lot of common data breach examples that we see today in the news one example of where this really ties together is open ID connect I mentioned this before they use the jot token this is an example from one of the explanations of how open ID Connect works and essentially you see a lot of interesting things in this example so you see identity information about the user this token could have been issued by Google for example when you log in with your Google account they could have sent a drop token containing all of this information about your user account contains an expiration date things like that contains two roles which is useful for authorization decisions and it's also very very cool and often unknown is that the ACR property that you see there refers to the level of authentication used by the user so in this case it indicates that the user logged in with two-factor authentication and that information allows one of your internal services that maybe wants to perform a very sensitive operation to determine how the user authenticated and if the user used a strong mechanism such as two-factor and it can decide to do this operation and if the user simply log in with a username and a password or was logged in from a mobile device the application can decide to request additional information or additional authentication before doing performing that sensitive operation very very useful very powerful and ties in nicely with OpenID connect so propagating identity information is very important thing it's something that we see being not done wrong but missing in a lot of applications even traditional applications that don't use different services internally and that's something that really really needs to be there all right I'm about halfway through so that's good timewise we're doing fine so we have time for a little poll the next topic is going to be how we transport authorization information from the client to the server to the API who here is using cookies to do it come on don't be afraid it's okay it's a web application you can use cookies okay so ten people apparently who here is using the authorization header okay a bit more who here is not sending any authorization information at all all right so most of you are actually using the authorization header um that's kind of expected the next topic I don't have a strong opinion about the next topic I'm gonna lay out both systems I'm gonna lay out the advantages and disadvantages and then you can make up your mind about which one may be better they both have problems let's let's call it like that so first cookies cookies have been around for a while and they're an absolute mess this is this is firstly well-known but they are very compatible with the web so if you're running in a browser if your application is running in a browser then cookies will be handled automatically by the processor you don't have to do a thing for that which is awesome cookies will be present on all requests including a request generated by the Dom so if you have an image tag fetching an image and that there's a cookie for that domain the cookie will be present on the call to fetch that image same for JavaScript CSS files things like that and even cool if you use modern things like a service and defense or WebSockets or course cookies are very compatible with that because the browser attaches them automatically of course as you probably all know from now or from the past cookies are a bit difficult to get secure so you have cookie security flags like HP only and secure that you need to enable if your framework supports that you have cookie prefixes nowadays so you can add a prefix to the name of the cookie and that's going to enable additional security behavior in the browser but again you need to be able to modify the name of the cookie which is something that not a lot of frameworks actually allow you to do and of course if you use cookies you have to deal with cross-site request forgery or C Cerf which I'm going to talk about in a bit also maybe the most important disadvantage cookies are a nightmare to support in non web applications if you have a mobile application you need to figure out how the set-cookie header works and the cookie header that's going to be quite painful and not fun to deal with that's cookies custom headers like the authorization header they are actually quite straightforward to use so you simply add the header and you're done but the browser doesn't do it automatically so you need to do it your application will need to actually take care of that itself and that means fetching the value that needs to be sent first from a response storing it somewhere and attaching it to the header I have a lot of content on how to do that on the client and what that advantages and disadvantages are but I'm not gonna go into that here that's something for the discussion afterwards if you want the second problem is that the browser doesn't attach this header automatically to requests coming from Dom elements so what we see a lot is applications wanting to enforce access control on JavaScript files on CSS files on images but it's simply not possible because there's no header there so you need to use cookies anyway as an alternative mechanism which makes it messy again and if you use things like service and defense or WebSockets then things get a bit more difficult with the authorization header as well and if you really look at what's going on surprising this is actually surprisingly difficult because you have to decide where you store this information on the client-side then you have to attach it to outdoor requests and you're very likely to mess that up no offense the good news though is there's no C surf if you use the authorization header so we're good on that regard also if you have a non web application like a mobile application or a native application this mechanism is also quite easy to use I may have offended you when I said that you might mess it up sending the request I'm gonna give you one example it's it's an angular example of how easy it is to actually screw this up this is again from a tutorial um this is how most applications in angular this is an angle or one example attach the token to the authorization header so essentially what's happening here is you have fetched token from local storage and then you add a header and you add a pair value and yet a token and that's it you're done this is an interceptor this will happen on every outgoing request made from it in angular application sounds good right well drawback with this is if it works perfectly fine if you use your own API as a back-end but the moment you start using a third party API running on a different origin this piece of code will attach the token to that outgoing requests as well so all of a sudden if you fetch anything from within your angular application from another origin essentially you're starting to leak your authorization token or your whatever token in this case on those requests as well so you actually need to check where the request is going whether you want to attach that to the outgoing request and that's one example of how these things are a bit more trickier than they seemed at first sight so don't minimize the impact of the transport mechanism sure cookies have a lot of disadvantages and I'm not advocating the use of cookies um but on the other side if you do it yourself with authorization header make sure that you do it securely make sure that you know what's happening there and that you figure out whether you are vulnerable in that regard so next up is cross-site request forgery if you well most of you may want to take a three-minute nap here because it doesn't apply at all if you use the authorization header so it's only valid if you use cookies so let me give you a very quick overview of what it is and I'll tell you when to wake up if you want to run a DOS out there for a moment so what is see Cerf let me first give you a traditional example of cross-site request forgery in normal map application so I have a quick scenario of to run you through it we have one application that you want to visit and after your logon you get a cookie and with with your session information essentially what happens is when you make another call the browser will automatically attach the cookie to an outgoing request that's how the server knows who we are and how it can fetch our messages now what happens in a cross-site request forgery attack is that another site in this case with funny cat pictures does that call for you so in this case it's gonna ask the backend to post a message in your name and the browser is very helpful when it comes to cookies browsers like I have a cookie for that let me attach it to the request and the server does has no idea in a sea surfer tackiest no idea this is coming from here no idea that is this default behavior and so out on the web and he simply processes it as if it was the real application asking for that and that's the essentially the the essence of cross-site request forgery and this is or this used to be a big problem in traditional applications because a lot of applications did not protect against this out of the box many to nowadays so that's a good thing and that's definitely a real vulnerability it's actually so real that criminals use it to reconfigure your home router and change the NS settings so essentially they make the call from a linear browser they make the call to the router and ask router to change the DNS settings course they have to guess the password but it's probably gonna be admin admin anyway so they make the call change the NS settings from then on they can control which sites you get to visit which may be problematic in this case they used it I'm not sure they have used it in the past for stealing banking information and things like that so it does have a serious impact it exists because the browser handles cookies liberally so essentially every outgoing request through the main browser slaps the cookie on it if he has one and that is kind of a problem because requests may be unintentional many api's are essentially unaware of this problem again note if you don't use cookies that this is not a problem so what one of the problems here is that a Dom element such as a form can easily trigger a post request to a different origin and send you some information and then it depends on how your API is built what's gonna happen with that maybe it processes form submitted data some api's are very liberal in the content type they accept and then you're gonna be in trouble again if you have put an delete methods those are a different story I'm coming gonna come to that in in the next issue how do you defend against C surf well in a traditional application you use hidden form token so the idea of hidden form focus is that you hide a token in the form and you check when the forms midotaur that the token was there or not and if it's there then the application considers this to be a valid request you can imagine that form tokens and api s-- probably don't mix too well you're kind of right about that so in an api you can use an alternative mechanism using transparent tokens well let me show you how it works essentially you have the same scenario as before instead of getting one cookie after we login you get two cookies and of course the two cookies are sent by the browser as well but what also happens is that the client-side application in this case let's say it's an angular application that the angular application has to copy the value of the cookie ABC here to a header called X as X as a X xsrf token essentially what a server now does it's verifies whether these two values match of course you should use something else than ABC and something random which is a bit longer but bear with me so essentially when this match the server knows it is a legitimate call because only this application could have read the cookie that was set for that application of course don't set a fee-only flag on that see surf cookie eater what happens if the attacker comes along he tries to do the same thing he sends the message the browser attaches the cookies of course but the server sees that something is wrong because the server sees that there's no additional header containing the cookie because this context comes from any site on Io it's not able to read that that value so it not will not be able to add the header and that's how you defend against Caesar this kind of behavior is enabled by angular by default for example so angular looks for this X xsrf cookie and when it finds it this cookie name it automatically copies it to this header on every outgoing request to the application so that's a very useful way of defending against these kind of things but of course on the web it's never quite simple so we need to talk about something else cross-origin resource sharing so C surf used to be a big problem in traditional web applications because you could easily well web applications depend on form submissions and you could easily fake them from another website an API is it depends on how you have built the API which mechanism is kind of relevant so let me walk you through it so essentially this kind of cross-origin requests have always been there but the power that's order the kind of requests that they can generate are very limited you can use an image for a get that's very easy you can use a form but you only have two or three condom types you can choose from all the other content types are unavailable you cannot set custom headers from a form those things are unavailable so if you have an API supporting traditional HTTP requests then you definitely need to worry about C surf these things matter for you if you have a JSON API that only accepts things from application press slash JSON as a content type then C surf will not matter because a form will never be able to generate such a request very important and why doesn't it matter because once you start sending non-traditional requests things that could never have been sent from HTML then you fall under the protection of course cross-origin resource sharing and course is actually a security policy in the browser that pre allows it's meant to allow cross-origin communication without running into these boundaries of things not being allowed and I'm going to talk about course in in the next topic in a bit more depth so what you need to remember here is well 99% of the room if you don't use cookies don't care about don't worry about Caesar and you're done if you do use cookies you need to check how your API is accessible and what kind of things you accept and if you accept things that can generate will be generated from we didn't HTML page then you're probably I kind of need to deploy some Caesar defenses on your API all right 11 minutes and three issues we should be fine cross-origin resource sharing course let me first give you an example of the basic setup for course and then we're going to talk about a couple of pitfalls or things that can go wrong so the idea behind course is that you again you have a browser and you have a server and you load the page from one run website that page is going to do an xhr request to a different website in this case well you see the code here simply constructing it's sending setting a URL and sending the request that's all that happens essentially that is gonna trigger a request to the backend in this case you see that the two headers well there's actually a lot more headers but two relevant headers has been added the origin header and a cookie header the cookie header is here because you have told the browser to use credentials remember when I said that cookies are compatible with course well credentials in this sense means cookies even though you're using the authorization header and the second thing that's gonna happen is the browser is gonna add this origin header because it's a cross origin request the server if he wants to allow this kind of behavior should tell the browser hey man I know that this context is trying to access me I'm gonna send you permission so that you can actually allow that context to access the response that's essentially what's going on there and this header tells the browser that oh by the way I knew that you used credentials for that and I'm fully aware that's allowed that's essentially well in a very brief nutshell what course is about why this example well actually if you look at the endpoints that are calling this is God's request API key and what a lot of applications are doing nowadays is they use temporary keys to access an API and you add that key with authorization header and the long lift token which can remain valid for a long periods a month is stored in a cookie and as a so cookie or something like that and using that cookie they fetch API keys from the backend and if your back end is misconfigured if you have a problem with your course configuration then anyone can request an API key from that back-end tell the browser to use credentials the browser will send this call and give any context here access to that response containing that API key and that is a huge problem and that's a problem that a researcher actually observed and wrote a very interesting blog post about and gave a very interesting presentation of at the conference earlier this year I'm gonna run through four common misconfigurations in web applications that allow this kind of behavior and it essentially exposes them to all kinds of attacks so this is the culprit here checking the origin header whether this one is allowed to access our application if you build this yourself then well you may have the had the idea to use the start sweet or unsweet methods to compare this to a whitelist of allowed origins hey if this this one starts at all if starts with our value then it should be fine right well it depends depends on how you have defined your whitelist but these kind of methods allow bypass attacks so for example if you check for it ends with dub-dub-dub the example that come somebody could generate a URL that matches that filter even though it's not one of yours example it starts with if you simply add that and then add dot evil.com behind it then the start sweet is going to match and you are in trouble so that's one way to bypass these course filters the second way is the null origin so a lot of applications actually allow no as a fellow origin but no can be generated by simply send boxing the piece of code so an attacker can easily trigger an origin header it does not fail you know so if you allow that again you're in trouble if you only check the domain and not the origin so if you check dub-dub-dub with example comm but forget the HTTP then somebody can trigger an attack on the network which launches a request from HTTP double dot the example outcome and again you will allow that allowing anyone to access your API and the worst offenders are those that simply reflect back the value from the origin header essentially they have a wide open course policy by default and this sounds absolutely crazy like who would do that who would simply allow anyone to access anything well again I google for this and I found I'm not sure what it does but I found a system that encourages people to configure it like this and essentially it says you extract the origin from the incoming origin header and you attach it again in the access control allow origin header and by the way you settle our credentials slide to true just in case and if you do it like this essentially your API is wide open for anyone to request everything they want which is probably not what you intended so the almost final security pitfall in secure skunk in secure course configurations are a real thing and should be worried about us check your course policies it's not only the implementation details I mentioned here but also allowing too much access allowing essentially all methods for all origins it's probably not what you want so take the time to narrow this down I know it's a pain to configure but it's going to be rooted in the end to more five minutes I think I'm gonna make it we'll see how it goes I have actually one issue which I split into two different pitfalls the issue is input validation should this be accepted by your API maybe it depends looks looks fishy right well you're probably guessing where this is going to this is gonna lead to sequel injection so essentially one of the things that you should be doing is you should be doing input validation input validation is a really important first line of defense so essentially what we're doing there is we're validating untrusted data before we use it things that you should absolutely be doing even though input validation has its limitations that's the last one what it should be doing is you should only accept content types that you expect I mentioned this with accepting form data well if you're a JSON API you shouldn't be accepting anything that is not application flash jacent just reject it validate data against their types if you expect a number as input an identifier check whether it's actually a number don't allow anything else and this sound very very simple and very straightforward but this is something that's often not done resulting in all kinds of vulnerabilities also sensible length restrictions based on the content for one but also strict upper limit if you expect a long piece of text make sure that nobody gives you a few megabytes of text because probably your system is not going to handle that in a graceful way so a lack of input validation is the second second to last security pitfall make sure that you have input validation in place on to the last but input validation also has its limitations it targets the symptoms of a problem but it is never going to be able to read out a problem to fix the problem for you think about the example I gave earlier its sequel injection validating your input is not gonna be enough to prevent the sequel injection attack the only defense is using parametric queries but variable binding and that's gonna make sure that the root cause of the problem is addressed because input validation starts failing the moment you have complex enough input the moment you have to allow well even something as silly as the name of a user it's gonna be a lot of trouble if you want to put a theta in a sequel query directly so essentially the only way to do that is with proper with proper secure coding practices and not with input validation if you wanna anon example of this look at Google for XSS filter is Asian cheat sheets and you have a huge list of ways to evade cross-site scripting filters because it's simply too hard to do that at input time and a final word about this sometimes it's not even the api's responsibility and cross-site scripting is a perfect example in a modern application the API simply gives out theta chastened data the API has no idea where it's going to be used is it in a mobile application is it in a native application then who cares about cross-site scripting if it's in a web application and of course you care about it but here it's a responsibility of the front end the front end is going to inject that data into the template or into the application and there you should have the proper XSS defenses that's by the way what angular does out-of-the-box because with this kind of application angular isn't one responsible for doing that it has the right information to do that and it will do that audit works for you and it brings me to the last security pitfall don't rely on input validation alone make no mistake input validation is absolutely very very useful and you should deploy it as a first line of defense but not as the only defense and you should not depend on input validation alone I have one minute and a half left I'm not going to give you an overview of everything recovered it's it's a long list it would be too small to report on this screen you actually could read it but in general it would be too small to read so I have one important message to wrap up everything I set here we're building application question everything think about what you're doing think about how it differs from what you used to do something simple as moving session data from one place to another can have a huge impact on your application we also think about the validity of data think about integrity think about if you understand what you're doing and if you don't then you need to find both help online training of course or anything else and that's my final slide I can help you I can explain you how to do it but essentially it's up to you if your guys are building the applications we use that millions of other people use so essentially it's up to you to build secure applications if you want more info you can follow me on Twitter and the last and most important thing is if you do something with security please share this with other people come to def works and give a talk on how you secure your API with my input from this talk for example but also share our meetups on within your company this is so so important so you motivate motivate other people to take security seriously as well that's it that's it for me thanks for being here thanks for staying most of you at least and if you have any questions I'll be happy to answer them afterwards offline here Thanks [Music]

Channel: Devoxx

Views: 17,438

Keywords: DV17, Devoxx

Id: YQzU8xEBiPg

Length: 50min 19sec (3019 seconds)

Published: Fri Nov 10 2017