How to Secure API Servers Tutorial – Crash Course on Server Security

Key Takeaways

learn key concepts for keeping API servers secure from cores to air handling to rate limiting and more Anthony arugu from apis SEC Labs created this course he has worked in security for over 20 [Music] years hi I'm anth Liss and this is the securing API servers course by APC University I'll be your host throughout the course telling you some ways to better secure your API servers from what we've seen in the field this course could be for you if you are in or interested in development Operations Security or any combination of those three the course has broke it up into six sections each one we go into as much detail as possible with scenarios and why you need to care these are chosen based on how often we see them and how well they're understood and how much value you can get out of of paying attention to these specific security configurations so if this sounds like a course that might be for you you can get some information out of it that can help you secure your API server then let's go ahead and get started we've got six different ones you don't have to do them in any specific order and we do have a certificate at the end if you want to display it on on your LinkedIn page or resume see you online hi I'm anthus for apis labs in this video we will cover cores also o known as cross origin resource sharing it's one of the most common vulnerabilities we find and not often well understood course is just a set of suggestions for how browsers are allowed to serve content those suggestions come from where the content is provided it's on your API server that's going to say how people are allowed to use that content and it's the browsers that have to respect it course will Define what is allowed to be called where so the what can be endp points and methods things like post and G and you know things of that nature and where can be called from so your UI that is intended to call an API is going to be allowed by that API but then if somebody else tries to point to your API because you don't know that you can block that because it's not on the allowed list and you can do that for individual endpoints and some endpoints you might allow very free and open access to as long as you know that that's not going to be protected or it can be misused of course is a pretty basic security configuration for a web server it can feel like it gets in the way sometimes especially when you're doing development your Local Host is not allowed to communicate with an API like you you have a you're developing a new UI and you want to communicate with the production API which is pretty common scenario if that production API doesn't allow you to use it from Local Host and you're going to get these cores errors and just feel like it's in the way those restrictions are good for when you don't want people to impersonate you you don't want people to use your branding or your intal property or for them to set up different scenarios where unsuspecting users think that J are going to your site that they're going to a different one using the data for your site and your API through theirs and Kors can help you protect you against this stuff well it's key to understand is that Kors is not going to protect you from direct attacks I drew up this quick little diagram to show you that if a malicious system is going to talk directly to your API it can ignore course because course sits in the browser and it's for or it sends signals to the browser and the browser has to respect it so if somebody's directly attacking your API they they're not going to respect anything that it says that you can or can't do with their content it's only the browsers that are going to respect this at all and that's why this is specifically for the scenarios of your unsuspecting users going to a milous site or mixed use site and using your API or your content in a way that you wouldn't normally approve of so how do we get into this situation I kind of alluded to it before but I've been in this situation many times where you're creating something new you have a new product a new API you run into the course error and it's usually the a low origin error you go search stack Overflow or something for how do I get past this error very common you just copy and paste an error and one of the first things that comes up one of the most common responses in search engines is to just okay for something like nodejs Express to install this little thing called cores the very first example is to just allow everything if you do that you automatically get past the air you probably forget about it and the thing makes it all the way into Pro production and the these protections are never put back in place so if you're running into this issue because of a security scanner or a security audit of some sort this is likely the root cause and understanding this root cause could help you understand how to prevent it in the future it can help to show things in a couple different ways so here's something I cooked up in order to show one of the common misuses of a site that Kors can help you with let's assume everything in the blue server is something that is protected and expected and everything in the red server is something malicious if you end up going to a malicious site which is why the whole screen is red it points to an API such is one that you want to protect if that API has the access control allow origin header as a wild card this star which I show over the servers then that server is going to allow that transaction happen so in the same scenario the API server now has a Access Control allow origin of blue.com so it's specifying that only blue.com is allowed to access this API or anything on the server so when a user ends up going to the malicious site and it tries to make a call to the API on blue.com it's blocked because the browser is not going to allow them to make that request from red.com here's a slightly different scenario where the roles are reversed for whatever reason you have content on red.com that is embedded in the site for blue.com there's a number of reasons this could happen whether the site is compromised or there's ways that were easy to inject content a lot of older content Management Systems would allow this and didn't really check for it and it's been abused heavily so for whatever reason your users are going to your site and there is a bad element within that site that is pointing them to a militia server if you don't set the cross origin resource policy then it's going to allow this so if you set the cross origin resource policy to same site then when your user goes to your site and it reaches that content that's trying to go to the malicious site it's not going to get there it's going to be blocked at the browser based on your header that you set for the cross origin resource policy this is what you want here's a solution to the same framework that we did the stock overflow issue with but in this resolution by applying this Library called hel instead of the other one called cores this one will automatically apply a lot of security configurations for you to the best standards and it will get you past most of the basic thing it does include course it goes beyond that a little bit and I would recommend ex starting with this if you have an expressjs application and it will save you some headaches in the future and plug up a lot of common holes that you may have created on behalf of apis SEC University I'd like to thank you for joining us on this video if there's another other topic that you'd like to see let us know in our Discord forums I hope this has helped somebody plug up some security holes or have a better understanding of cors in general see you [Music] online hi I'm Anthony otz and in this video we're going to be talking about error disclosure where you can also think about it as air handling with a security mindset an air disclosure is when you have too much information in your airor messages that are sent to a user's machine it doesn't necessarily have to show up in a UI but anything that's sent to a browser that a malicious actor can take and use to better understand what your system is in order to attack it is going to be called an error disclosure now handling errors is necessary as a developer and you want to intentionally error and error out actually pretty often and early so that things that are done maliciously don't work but when you do that error you want to make sure that you're not giving away information that's going to make it easier to attack your system this means that you're going to want to have separate air messages for your developers to debug what's going on with the system then you're going to send to your customers here's a good example of a bad air message from a user interface perspective we have a bad error message and that it gives away too much information if you tell somebody that there's an invalid email address when they are typing in emails then they know that when they get a the right email address are going to get a different error they can enumerate the users or the email addresses that are allowed this is a little different than what I'm talking about with error disclosure this is actually going to be more commonly seen inside of your JavaScript console for your browser or if you're attacking from a development standpoint like using Postman or you know just your own little nodejs scripts then the air below is what is going to be seen by somebody who's consuming the API now interesting enough is these actually both came from the same interface so one is the interface of the UI I put in some SQL injection code and it's just going to never send it back the API so they did some decent protection here making sure that there's only a valid email address that's going to get sent to the API from a UI but if I'm writing something to the API I don't have to respect anything that the UI said when you're coding for the API you need to keep in mind people could bypass the UI not everybody's going to use that UI especially if they're going to be attacking your business logic or trying to get at your data they're going to go directly to the API and in this case it's not doing the same thing it's it's not very it's not nearly as good about handling the SQL injection information no it didn't allow it to go through but what it returned starts giving me information as to building a picture of what's behind the interface and in this case it told me that it's at least running spring framework which means that it's running Java and I can start to understand the code stack and probably some things that are associated with that because we know that certain EOS systems have common components and you know this is the type of thing that you would not want to display to somebody as an aor message because this isn't going to help any legitimate users this is only going to help somebody who's thinking about it maliciously and trying to attack your system it's good to understand how this typically happens it's actually pretty simple a common development practice is to do try and catch blocks in a try and catch block you can catch the error and print it out and I've got two examples here very common ones so in Python you got a try accept and in no. JS you have the try in both cases it's very common to just print the error out or return the error and even if you don't explicitly do the try accept and then send it back a lot of systems will do this by default if you have an uncaught error it will by default take the exception and send it back so at least when you are intentionally doing it like this you have more control where you don't have to print it out you don't have to send it back to the user you could log it instead and that is probably a better option just so that it doesn't go back to the users so TR catch block good thing to do gives you control over what succeeds and what doesn't and you know catches a lot of things that are unexpected but probably not a good idea to send the the exception error back to whoever is consuming the API because it's going to help more than just your your development people trying to debug it so as an example of why it's not a good idea to put your technology information in your air messages here we have a cve specifically for that spring framework that we found earlier you know this is the kind of thing that a malicious person is going to do once they understand your TCH stack they're going to go look for common vulnerabilities for that Tex stack and and then also like I said before trying to build out what other Technologies are probably in that ecosystem and then look for the vulnerabilities within those and that brings us to the general concept of everything that you're doing you want to try to think of how can it be used maliciously so here's another live example that I grabed just using my own little framework with node.js it's an example of a generic error message so this is directly against the API I tried doing the same SQL injection code for postgress and it comes back and just says you know something's wrong you you might want to check the email ID it'll do this no matter what I put in and that's a good thing and so this was for a forgot password and it's not telling me if it was in the database not in the database it just hey there's an error if I was attacking this site this isn't going to help me at all and so this is more like the example of what you want to achieve something a little more fun and maybe not as applicable to an API is the brand approach I've been seeing this a little more in the past few years and I really enjoy it this is github's 404 err something to note is that GitHub will give you this error even if the page exists but you're not allowed access to it which I like because if you don't have access to it you don't need to know if it exists or not so there's no reason for them to give you that information they are treating it from a security mindset that if you don't need to know they're just going to tell you it doesn't exist but they do it with some style you have the the octocat with a Star Wars them it's pretty fun so as a quick summary some things that you definitely want to do is you want to error early that's going to keep malicious attacks from prog pring too far because it's going to hit something early on fail send an error hopefully a generic error that is going to keep them from getting any deeper or understanding the system better you want to make sure that you include useful information for your developers and your support team but that information should remain not visible to your customers you might end up with an ID that ties them together and that's fine what you definitely do not want to do is bypass eror if you have a try catch block with an exception you generally will want to stop on that exception unless it's a known one and anything else you should stop execution you don't want to expose development information to your customers doesn't help them it helps people who are attacking your system hopefully you found some useful information here maybe some things to think about as you're developing or understanding how to correct something that already exists there's a lot of opportunities for exceptions to make it through the cracks whenever they're found hopefully these guidelines help you a little bit on not providing too much information for attackers we are going to continue with the security series we've got a number of other videos planned and I look forward to bringing those to you see you onl [Music] hi I'm Anthony OTS the head of apis labs in this video we'll be talking about server information leaks this is part of our larger series on server configuration security a server information leak is anything that advertises your technology stack to random individuals online or your customers it will do this through headers sent to any client that makes a request to the API or anything else that goes to the server sometimes this can also come from appliances or caching or your cloud provider anything that sends headers and these headers are going to be beneficial for somebody to attack you by understanding what technology stack you are on here's an example we can look at together I have Chrome opened up with Dev tools in the bottom half and in Dev tools I'm in network and then headers because headers is mostly what we're going to be looking at and with network opened up you can see all of the different requests when you go to a web page when you go to a web page it will do separate queries for its data all of its API calls its images and all that kind of stuff so you can start browsing through these and then you can see where it went what it sent what kind of response headers it got and these ones look like it's going to Google ads I don't know why it says server Cafe but these server response headers are what we're going to be looking at a lot and especially ones that point to a technology that we can understand you're not going to see a lot of really interesting ones on things that are hit so often that they have to be cached although I'm not familiar with what this is I'm going to take this and I'm going to look it up so we'll say web server oh there you go it's a Google web server all right so this is exactly what an attacking person is going to do they're going to find clues in these headers and they're going to go look them up and see if it's going to get the mini closer to attacking the site I find that I get more interesting things if I have an account somewhere and go ahead and sign in now that I'm logged in we're going to find some things that are less cachable they have to go to server they have to go through an API and that's more the kind of stuff I'm looking for now here I start to see different things like here's a interesting server I've never heard of called uvicorn I did look this up before recording the video just to show you how this process would go go ahead and look it up here and we find out quickly this is an opsource python web server so now I have something that I have the source code for if I'm really Savvy I might find my own issues inside the source code or I might just find things inside the source code that I can exploit even though they aren't security issues of themselves the better that you understand the variables the parameters the schema of something the more successfully you can attack it you have the source code that's not that significant on its own but then now that I know something specific about the server I'm going to look up the cve so I'll say cve and we'll get a list of cves so if you're not familiar with cves they are known vulnerabilities so we can use that server tag to not only find the source code but now I'm looking up specific vulnerabilities for that server and the more unique that server is it's not like a is or even expressjs which definitely has its own vulnerabilities the more unique it is the more interesting it is to try to attack because it's not trafficked as much it's not known as much and giv as much attention being able to find cves on something that is fairly significant and you can expect people to automatically pick up whatever they can learn from the known vulnerabilities and try to apply it to your site that gives off that server tag that says it's running that just to illustrate it as a slide so we went from what we had in Dev tools we had the server tag which doesn't do your customers any good there's no reason they need to know what server it's on and they're probably not opening up Dev tools anyways from that we able to get source code and known vulnerabilities without walking through the entire process I have found many other ones here's one with engine X now engine X has 168 known vulnerabilities so it's a little more there's more options there to try and probably less likely that individual options are going to work but there's a lot of stuff there to mess around with engine X is a much more popular server it's used even as a proxy or a cache that is not as big of a finding as the one that we found before that was a more obscure python server but these exist everywhere you're going to find that people don't protect this and web servers will often just do this by default they're going to advertise not only what server they are but they're going to sometimes tell you what version and that gets even more dangerous so in the format of a quick checklist guide when you are looking to analyze your headers for server information leaks you want to use a client that is going to access your API if you have a user interface that is the API and everything can be done like I showed in Chrome that's fine or you can use something like no JS it's natural ability to fetch API calls and call different methods if you have that skill set that's great or something like Postman will work as well anything that's going to show the headers and almost everything will if you know where to look and one of the key things is making sure that you get past the things that are cached so a lot of these caching engines they might also show up as showing their technology header but it's not nearly as significant what's going to be more significant is when an attacker knows that they've reached a server they're no longer in Cash Land and have to break out of there somehow they're going to want to get into directly talking to a server usually through an API want to know that their responses are actually getting processed on the server it's actually hitting SQL it's hitting data stores and returning a response now they've got something that's worth trying to fuzz and inject and see what they can get back so the headers that are going to let them know that are the server anything that says powered by or anything that says version any of these type of headers are going to be something you simply want to remove the way to deal with this is going to be different per web server so I looked up a few like I said I've never heard of this UV corn maybe that's just me being out of the loop on some recent stuff I looked up how to remove the header for it and it has a regular option on how to do it just when you start it up it has a server header option I think every server I've ever seen that has these headers has a way to turn them off very easily because it's not uncommon for people to want to remove this this has been an issue for a long time engine X the other example I showed has a line that you to put in its conf file just for turning off server token in Express or nodejs you can either run helmet which handles a lot of basic stuff for you or you can specifically remove headers from your requests with the remove header function I know that I and other popular web servers are going to be different all of them are pretty easy to look up there's nothing I tried looking up that was difficult to find just type in your web server that you're trying to remove the powered by header and it's going to lead you in the right direction on behalf of apisi labs and apis University thank you for joining us on this video and I'll see you in the next [Music] one hi I'm Anthony ESS head of apis labs and in this video we're going to be talking about cookie security and how do you keep your customers safe from having their data harvested through cookies cookies are storing data on a customer's computer insecure cookies are ones that are created that don't restrict the access to anybody who might want to read that data when a cookie is created it has certain security settings that can be created such as the secure option the HTTP only option and then restricting what sites are allowed to read the cookie here's an example I've opened up where I've logged in I found some requests that have cookies that are sending the cookies there are some that are sending some back but I wanted to show when you log in and it's keeping information on your machine how much information that is so here I've got a cookie that is sent to the server from my machine and there's quite a bit here something to keep in mind is the cookie is pretty cumulative it's going to keep as much information there as is sent from the server and the server can add new key value pairs to that cookie and it's just going to add on and then there's time to live and a couple other factors but the reason I want to show how much information is here is to show how easy it can be to access this and that you want to protect it from being accessed by anybody that is going to use it maliciously here you can see I've taken that data I posted it in and I started to parse it now this stuff is stored in key value Pairs and so one of the easiest ways to start understanding it is to parse it by its delimiters which is a semicolon and you can start to see these key value pairs take place where you have a key equals and then a value some of these are just stored as booleans or things that are easy to recognize like a number then you've got these unique identifiers there's some things in here that look like they're probably base 64 encoded Bas 64 encoding is fairly easy to decode if it's got no salt on it and salt is an extra password that you put in to encrypt with it and makes it a little more difficult to decrypt it or decode it it's different encryption a lot of these ones with the equals equals might be Bas 64 encoded the reason I want to show this is because it's fairly easy to grab this information parse it out understand what different things there are here I've got a delimiter under delimiter so we've got the key value pair that's already broken out but then within it you can see that I've got some pipe delimited stuff and under that I've got a session number so a session number might be something that is valuable for someone to try to put in their cookie have it send to the server and then see if that works in order to get them P some checks here's another example of a cookie that is set as well as how the cookie is set from the response header so here we have the set cookie and you can see it's got the session ID inside of it and then it has these tags which are going to be very important we're going to discuss is the secure and the HTTP only so these are some of the most important ones to do it is possible to also Define the location that is allowed to request the cookie such as in the path but secure and HTTP only are the main things that we want to look for so this is saying set cookie and this information is going to get appended to the cookie that is stored for this site and it's going to send that back on the next time I come in and that's how it's going to recognize me without requiring a login again so cookie data initially will come from a server and be put onto a client machine through the response header set cookie and then when you go back to a site or something requests it the cookie data is going to be sent back through a response header called cookie cookie data is pretty easy to access on a machine and you can go through and analyze it and pick it apart and try to decide things from it and for that reason I both encourage people to not put anything into a cookie that you don't need to be there and also look at the cookies that you do have and try to make sense on if they belong there or not so when you're looking at the cookie data you're first going to break it into its Fields by delimiter and then try to find things that you think are interesting things it's a session or user ID or role anything that you might want to set or somebody is going to have an incentive to try to alter or feed in a different value you can also sort the the different fields by their data type your unique IDs are only going to be useful as unique IDs so you're not going to guess these easily you're going to need another unique ID to try to plug into this value or take the one that you see and plug it in somewhere else and see what you can get from that but you're not likely to Brute Force unique IDs you're going to have to keep lists of them to manipulate them at all numeric IDs on the other hand you can generally try to increase or decrease and and see if you get different results booleans obviously there's only a couple values that you can use for Boolean so it doesn't hurt to try changing them and when I say try changing them you can actually edit the cookie and then go back to the same website and it's going to send that new cookie value to the website and you're going to be able to see if you get a different response based on your change so it's the same as changing field data when you're sending to an API endpoint but in this case you're changing the data on your machine to often it's just accepted as this is only data that has been sent from the server so nobody's messed with it so you might actually be more successful in messing with cookie data than with API endpoint data it should be treated the same it still should be untrusted input so for that reason it's good to try to mess with it in these ways next on the list we've got encoded data and what I mean on this is generally the base 64 encode data sometimes it's URL encoded but you can URL decode or Bas 64 decode and then you're going to try values based on what you find and then re-encode it based on what you find based on whatever it was encoded with you might change a value re URL encode it or you might do a basic4 decode and see that oh this is a Json string let me change some of these values and then basic4 encode it back and put it in the cookie these are the cookie problems we're solving for cookie forging is the previous thing that I was showing where you can take the data from the cookie parse it all out decide what to change you change something and send it back to the server and see what response you get if you're able to access something that you weren't intended to or impersonate a user or something of that sort then the server is trusting the cookie data and they should be treating it as just like they would user input data that's going to get exploited worth mentioning here that that's how all headers should be treated because attackers can use any header put in any value for any header and those all need to be treated as untrusted the next one is data harvesting from a different site if you have the HTTP only flag on your cookie it's going to keep the cookie from being read from JavaScript it's still going to go on these request and response headers that I was showing in the examples but it's going to keep somebody from being able to write JavaScript harvest the cookies that way and that is the most likely way that somebody's going to be able to easily harvest the cookies without being in the middle of your transaction data harvesting through cross- site scripting requires a separate vulnerability where you actually have a cross- site scripting issue somebody's able to use that cross- site scripting vulnerability to send a customer a link that's going to include JavaScript that then harvests the cookie like I explained in number two and sends it off to them so this one is definitely feasible and happens but not if you set the HTTP only flag on your cookie unless you absolutely have to read your cookie through JavaScript for whatever reason then you're going to set the HTTP only flag on your cookie and javascript's not going to be able to pick it up out of customer browsers and the last one is data harvesting and Transit and this is going to be the secure flag of the cookie that's going to help prevent it it's just going to help it's going to encrypt the cookie on its transport so that something in the middle is not going to be able to read it in plain text the solutions to cookie security problems are going to start with treating cookies as untrusted user data once you have this mindset a lot of the other things are going to fall into place want to keep in mind that the data that is sent from cookies can be in manipulated it's going to be treated as input on your server and even though it's often not used as part of your business logic you need to take a look that it is scrubbed for valid values when it is come in so that it can't be used to manipulate a user's access or do something more catastrophic on your server once you start treating it as untrusted user data you're probably going to also be more restrictive about what you're going to put into cookies if something can be used to manipulate someone's access or even the state of a process you're probably not going to want to put it inside of a cookie you're going to try to find a different solution for that and only use cookies as something that's going to keep track of your session or something that is absolutely required for your State Management if you have it and then analyze your cookies from an offensive mindset look at the cookies that are actually showing up in your browser from your application or from your API and parch them out see what's easy to make sense of does it lend any clues as to the internal architecture of your system are you doing things like storing table names in there or something Dynamic that somebody thought was a clever solution to a back-end problem that maybe you don't want to expose if you know now that people can easily go and look at it so just take that offensive mindset look at your cookies see if there's anything there that you can then apply rule number two and remove that and move it somewhere else and then lastly and probably most importantly when it comes to the basics of doing cookies you want to make sure that you've got time out on your cookies set something reasonable based on your policy that you have the HTP only flag that's going to keep JavaScript on different sites from reading the cookies remember this JavaScript can be not only on your site but on other people's sites and even if your cookie is only for your site and you allow JavaScript to read it then now a cross-site scripting javascripts can read it as well and then send it off to somewhere else so don't allow JavaScript to read your cookie if you don't have to then lastly make sure that you have the secure flag set on your cookie so that it can't be read in transit or nobody in the middle can read that cookie as it's being transmitted thanks for joining us in this video I hope you got something useful out of it if you have any questions feel free to ask us on Discord we're going to be Contin with this series on secure server configuration so I'll see you in the next [Music] one hi I'm Anthony OTS for apis University and in this video we'll be talking about path traversal vulnerabilities path traversal vulnerability is anything that allows a attacker or user to be able to access files and directories that weren't intended to be served up by the API or web server this can include things like direct file access either inside or outside of the web rout or access to things that weren't in the web rout at all but somebody was able to get it through Dynamic file includes or something similar so we'll be going over various ways that can be done whether it's through missing server configuration or lack of defensive coding or even vulnerabilities in your spec so here's an example of a traversal vulnerability that I hope doesn't exist in the wild anymore but it definitely would have 10 or so years ago this blatantly because it was easy to do there's lots of different ways that you can create traversal vulnerabilities especially in server configs but a lot of those have been tightened by default but you can still mess it up when it comes to developing if you develop something that allows a input to come in and directly be used as a Dynamic file include of some sort or file path that you're going to then return you're going to have a traversal vulnerability and nothing's really going to stop you from doing that besides cleaning up your own code or thinking more defensively in doing that so here is a example of a cookie remember cookies can be easily crafted and there's a number of ways that we can do these traversals whether it's a DOT do slash to go to a parent directory and you do that as many times as you need to in order to find the file that you're trying to get to Etsy password just a a great example if somebody can get a hold of it then that's a very severe vulnerability and then you can see in the PHP source code here where somebody thought oh well you know if I just keep templates as a variable I don't need to program each one I don't need to list them or anything so let me just include template and since their assumption here was probably that because a template is a cookie and I send the cookies back to the client machine then that's just a convenient way for me to store what template they're going to use and then I dynamically include that as a variable name in my code not realizing that if somebody opens that up and they see something says template and let's say it says default.php or something like that then they're immediately going to see that that is a traversal vulnerability and they can then exploit that by trying different paths something that I don't think we emphasize enough is how important the spec can be to security so here's an example where a data type of string is definitely going to be used against you on a number of different things no matter what you're doing with the code strings that do these directory traversals probably should never have even been submitted back to your API server it should have been caught by the Gateway or the WFT but when your definition for the data that's allowed to come in for different variables is loose enough to just be strings then that's what it's going to allow it doesn't know that it needs to filter these it doesn't know that they're bad so that's going to leave you to have to try to only Define everything on the API which is fine to to list things in the API that are correct but it's even better is if you can Define your allowed parameters in such a way that it's fill filtered at your gateway or your web application firewall I ran a directory traversal tool against crappy and it did 1,026 I think different attempts at just the public paths that it could see and all of these are going to register as strings but you can see that if these were defined as a string for say someone's name or address or even a user agent then they shouldn't have been allowed through we can look at these intuitively and know these aren't valid as the parameters for a lot of the things that are needed for an API as variables coming in not even from a cookie the better that you can tighten what's allowed early on by putting it in your spec that's used by your gateway or your web application firewall a lot of this stuff never gets through it's not even going to make it to your API server to decide if it's okay or not but then obviously when it does get to your API server if you can list out what is allowed rather than trying to filter all these different ways that it can be encoded is that's one of the things I want to show is how many ways it can be encoded URL encoded it can use the asky encoding unic code and cod anything that it thinks is going to be happening on the server in to filter some servers will just try to filter dot do slash and you can put it twice or intersperse them so that the removal of any do slash is going to leave a do do slash as the next iteration so all of these attempts are actually all the attempts to bypass the common filters and it's just not a game you want to play you don't want to play the filtering game you want to try to Define what is valid and good for your application and only accept that the problems that create a past traversal vulnerability are listed here we have our input data validation which is the logic level of what to validate that is allowed for different parameters before you use them we have a server configuration and this is the one that is pretty tight in more recent versions of web servers if you're running an older web server it might not have these as default but hopefully you've plugged it up since then if you ever find a server configuration that allows directory listing you need to cut that off you don't need to give people directory listings there's no benefit in it I still run across it especially on Apache web servers but you want to cut those out and also in allowed include file paths so when you have your API server or typically a web server that's serving an API there's the web rout and then there's everything underneath the web root and there's usually a server configuration checkbox that says to only allow inclusions or files that are under that web rot never allow anything outside of that web rout or above that web rout to be used and that will help somewhat they still might be able to get files you forgot to remove from the web rout and we'll we'll talk about a bit but it will at least keep them from going above the web route to something like a system directory and then like we mentioned before the loose definition of a strain for your parameters that are allowed that are in your API spec is also contributing to the problem and something as simple as even giving it a Max link can go a long ways to ging a lot of the payload attempts that I was showing with the past reversal to check on how prevalent a vulnerability is you can always go to look at the cve details and the cves are known vulnerabilities and they're often categorized in the same way that we discuss vulnerabilities that are found and that we test for you can also find things by similar names in the cve databases so when I just look for this category there are thousands that are there here you can see when I sort to try to get the latest ID first that these are still happening right we still have path traversal vulnerabilities that are found in applications today autog GPT that's actually that's a really recent one and a lot of these are going to be found in places you didn't think of it's you have a function that needs to have a file name it needs to grab something dynamically off of dis let's say a customer or a user of your application has a thing where they're supposed to upload a file you process it and then they download a file you allow a variable to say what file am I going to get that's going to be something that somebody's definitely going to try to exploit for a directory or path traversal vulnerability to see if they can dynamically get something else right it doesn't have to be something like the PHP example where I showed it displays whatever file that it's trying to access but instead it can also try to retrieve a file whenever that's what the logic is supposed to do if it's supposed to retrieve a file and send it to you like some of the examples here then you can try to get it to send you a different file these are definitely still occurring I these scores are low in how they're exp exploited to get different things but they definitely get higher and you could see that the ones that we had with higher severity were some of the older ones because people had figured out how to connect them together with other vulnerabilities unless they can actually directly access something like your Etsy password then they will often keep the the severity low until they can connect it with something else that allows that level of access but yeah they're definitely still occurring they're still out there people need to take it seriously as something that is both easy to make a mistake on in the coding and easy to exploit if it's there let's go through the solutions real quick so we're going to scrub the input data it's worth repeating in every video disable your server directory listings that's a web server configuration also in a web server configuration is the setting to allow something to access anything above the web route that is commonly done by default but it's still something we're checking and in addition to that you want to make sure that nothing at the web rout or lower is something you don't want anybody to access if if nobody's should be able to access it just don't allow it below the web rout that includes your hidden file systems such as your dogit or your repo type things that might end up getting copied in because they just went along with it it would also include things that might be a read me or something that has sensitive information in it environment configs for other environments you want to just get those out of the web rout don't ever assume that you're filtering so well that they can never be accessed to go a step further than that you could put your web rout on a completely separate drive that way if they were able to somehow Traverse directories up it's not going to get them anywhere because they would need to change drives in order to get to that location you definitely want to remove variables from paths and your source code if you are able to like the example I mentioned before if you have files and you're supposed to serve those files you're going to have some Dynamic stuff there but still probably the best pattern is to have an ID the ID is then used to find the PATH and that is the path that you're going to retrieve for the file for uh your API response anytime that you're going to take a variable and use it for a dynamic thing to access the file system at all there's the danger there for these vulnerabilities so just try to avoid it and lastly if you run across something that is unexpected you should air it's better to have an error and log that error somewhere to research what's going on than to be so permissive that you're allowing things to get through that should not have gotten through and then you get to a layer that you didn't think anybody would be able to access because they were able to create exceptions down a path until they got to something that was fairly insecure so as a quick review Pat traversal vulnerabilities can be really severe they shouldn't occur that often but you should definitely look at anything that dynamically includes things from the file system anything that dynamically accesses the file system in your code they should be easy to find by those patterns the reason I say that it can be severe is if you look at the examples of the type of things that it could access especially at common paths people know where Etsy password is they know where your host file is if you're on a Windows Server they know where your log files are going to be so all they have to do is try all the various encoding and Escape bypasses in order to try to access those locations obviously they share some common Solutions as the other vulnerabilities that we've been talking about one of your best ways that you're going to be able to know if you have the these issues and prevent them is to both do your testing testing like tools that will do the past traversal or directory traversal attempts against all the different inputs that go into the request and response process and then a static analysis so there's no substitute for static analysis of your code finding these locations that may be dynamically accessing the file system thanks for joining me in this video I hope you got something out of it happy to discuss more on Discord and I'll see you in the next one hi I'm Anthony aois and this is the rate limiting course for the secure server configuration series rate limiting is much more than a couple of things that you configure on your server and you're done it can incorporate your business workflow your needs your budget a number of other things and even just known limitations of your application you do want to set your rate limit headers that are going to be respected by some browsers and the HTTP status of 429 which is the accepted one for T many requests but you also need to configure Things based on individual endpoints how frequently they should happen and for what scope rate limiting is more significant than you might think the oos Foundation came out with their new API top 10 list for 2023 and number four is unrestricted resource consumption now this is exactly like the broad concept that we're talking about today not just a couple of headers if you care about the oasp top 10 and it's part of your security framework then that could be just enough of a good reason but my primary reason is for the service availability I want to make sure that when I write an API that the primary use that it needs to serve is serving the people that are supposed to receive it and it's not overwhelmed by things like bot Nets and scanning or even just sloppy use so the more limits I can put in there in order to keep things on that path of what I'm expecting it to be able to provide the more likely it's going to be able to provide that there are a few security considerations or security scenarios where a overwhelming of resources in one area will allow a vulnerability to show up in another but these are fairly rare compared to just general rate limit scenarios and finally we have the budget consideration when you've got when you've got everything hosted in a cloud for instance and it is priced per processing hour or bandwidth or concurrent users it's simply going to cost you more money the further into the network that you allow that connection to go there's a lot of different layers that you can enable resource limiting to your needs at that specific layer the earlier that you filter out a process that doesn't belong going further into your network the more headache you're going to save yourself the more budget you're going to save yourself and the more that those lower layers can handle for instance if you are able to set something in a load balancer that limits your general number of connections or requests per session then that's going t