Well, here we are at the very end. INFOSEC Skills learning path, the 2021 OWASP Top 10, we have made it to the last security risks on the list. This is number 10. It is server-side request forgery. What is this thing and how does it work and all that? Well, hey, we'll dive right into this thing and get to it in this video. Let's go. All right. Server-side request forgery. This is a new one on the 2021 list and this is another one that was added from the survey, if you remember, the logging and monitoring failures, was the other survey added risk. In fact, this one, even though it's number 10 on the list, it was number 1 as in terms of a risk on the survey results, so that's an interesting thing. But obviously, the committee that does all the ranking and all that, they look at more than just the strict, "Hey, was this number 1 on the survey? Well, then it has to be number whatever on the list." They look at all of the different CVEs and CWEs and all that stuff. You can see there that second bullet, the data shows a relatively low incidence rate with above-average testing coverage, above-average exploit and impact ratings. There is above-average testing and exploit and all that but it's a low incidence rate. Anyway, you put all that together in terms of making a decision on where does this need to rank and it comes in at number 10 in the end. Then, you can see there as well as new entries are likely to be a single or small cluster of CWEs, for attention awareness, the hope is that they're able to focus and be rolled into a larger category in a future edition of the OWASP top 10, and so I was going to point out too that this one tends to be a bit more specific in terms of a vulnerability or a problem as it were, this is a specific server-side problem, whereas some of the other ones, like cryptographic failures or components with vulnerabilities, things like that. That could be a lot of things, a lot of details could be wrapped into those broader categories, whereas this one is a much more focused type category. But nonetheless, it's on the list, so let's check it out. What is this thing? As we dive in, here are the factors that the committee was looking at, and there's only one CWE mapped to this particular risk and so because there's only one CWE, the max incidence, rate, and the average incidence rate are exactly the same. The average weighted exploit, obviously there's only one CWE, so it's 8.28. Now, that's a big number. The exploit is big. That's a reason I think that the survey came back is like, "Hey, this has got to be on the list this time around." The weighted impact is 6.72. That's also pretty big. Again, those are out of 10 and so those are big numbers. Then because there's only one CWE map, the max coverage and the average coverage are going to be the same because those are applications tested against that CWE, and then there were 9,503 out of just over 500,000 applications tested that had vulnerabilities related to that CWE that was mapped to this particular security risk. But there were 385 CVEs mapped to that one CWE, so there's still a lot of vulnerabilities out there related to this risk. Those are the factors that the group looked at to say, "Hey, where do we put this thing on the whole list?" Like we said, it lands at number 10 for the 2021 list. A bit about SSRF, server-side request forgery. These flaws occur when there's a web application that is looking to fetch a remote resource without validating the user-supplied URL, and we'll get into more details with some scenarios and examples here in a minute. But the idea is you have a user that supplies a URL to a web application, and then based on the nature of that URL, the web application then has to reach out to a remote resource. As it reaches out to that remote resource, that reaching out action happens on behalf of the server, so it's a server-side request. The server-side request forgery, the forgery comes in the nature of when the user supplies that URL, it is forging or manipulating the URL in such a way that it's making or it's asking the server effectively to reach out and request a resource on behalf of the server, but in a way or maybe to a resource that it does not need to be requesting. So that's the nature of this flaw. You can see there, the second bullet, it allows an attacker to coerce the application, sends a crafted request to an unexpected destination. It says even when there's a firewall, when there's a VPN, some access control list, those are not going to work against this particular vulnerability in a server because again, the server itself would be allowed access through the firewall or a VPN is not really going to make a difference because the request is coming from a valid server. You can see that third one, modern web applications. They're built in such a way that fetching these URLs becomes very common, it's a very normal thing for this to happen. You can see that last one, a typical attack, the attacker causes the server to make a connection to internal-only services or in other cases they may be able to force the server to connect to an arbitrary external system. They could leak sensitive data, authorization credentials. There's all kinds of stuff that the attacker could try to get a hold of via this server side request. As far as the internal-only services, there may be services within your organization that you say, hey, these are internal networks, these are not accessible to any outside user, that thing, but if those resources are being accessed from an internal server, that server itself may have access to the outside world or from an outside user. Again, if the request is coming from the inside server then that request can go through because the request again, is coming from the internal server. That's the nature. Here's a scenario, I'm going to use my pointer here just a little bit. Let's say you have a shopping application. This over here on the right would be the application, let's say, and you have a user that wants to see if there's an item in stock in a particular store, which pretty common thing. Go to your favorite online marketplace website and see if something's in stock or not. They would submit an HTTP request and it's going to look something like this. It's a POST/product/stock HTTP/1.0, Content-Type, Content-Length, normal HTTP requests, look here. But then here's the URL, so stockApi equals and then it has this big URL that it's going to reach out and say, go to this stock.weliketoshop.net. Effectively what happens, this request comes into the application and then the application says, I need to reach out to an external or a backend API so I need to make, in this case let's call it a REST API call to this backend API endpoint. This is the API URL right there. This is the stockApi location. This server is going to send a request to, let's call it this API endpoint right here to ask about the stock condition of that particular item in that particular store. When that URL is sent out via that API call then that API is going to respond with all of the information that it's being asked for and then the application, the server, will have the information now that the user is looking for and it's going to be able to return the information and say, here's the status of that inventory. Again, the idea is there is a frontend to the application, this frontend coming this direction. A frontend HTTP request that results in a backend API call that then returns the information. That's the idea of what's going on here and the way that things are set up. Again, because endpoints APIs are so common now in terms of building modern applications, this is a very common scenario. Anyway, that's the scenario. Well, here's what could happen. An attacker could come in and say, give you that same HTTP request. Here's the POST and the Content-Type and Length, all this stuff's exactly the same except it's going to say, hey, the stockApi instead of pointing out to that backend API, why don't we change this stockApi URL location to localhost/admin? We're just going to redirect right back here internally on the server to its local host address and then it's going to pull in the /admin contents. What are the contents of the /admin page on that local server? Then it's going to send that back. Now, it's going to do that if it's vulnerable to server side request forgery. You can see down here in these notes, the attacker can modify the request to specify a URL that's local to the server itself. When the request to the /admin URL comes from the local machine itself, the normal access controls are bypassed. Why is that? Well, it's because this is a known good entity. If the server itself is making the request to the /admin page on itself then it's going to allow that request and it's going to provide those results. Now, if the attacker himself were to just say, hey, give me localhost/admin then it either would not be able to get to that page if you've got a lot of the other controls set in place like we've talked about before, or if the attacker was able to get to that then maybe not all of the functionality would be listed there. But when the server itself requests its own /admin page then all of the functionality, all of the information from that /admin URL will be presented because it's a trusted location at that point, because this is the requester at that point. That's the nature of the server-side request and the forgery comes in the way of the attacker as forging this URL right here. That's one scenario. Let's look at maybe a different scenario. It's a similar type thing, except this one specifically references redirections or redirects. That is the application user is here and it says, hey, I need to look up this particular URL. Then there's going to be a path to get to that information and there's going to be another URL embedded that ultimately will result in a HTTP redirect. You can see down here the user-submitted URL is strictly validated. This particular server strictly validates which URLs it allows to come in. Those are strictly validated to prevent malicious exploitation of the SSRF behavior. In this case, it's like, hey, we're looking good. We strictly validated your URLs. However, the application whose URLs are loud contains an open redirection vulnerability. If the API that's used to make this backend HTTP request supports redirection. Let's come back up here to this API or maybe this one, whichever one is that it's going to end up going to. If it supports redirection, then you, as the attacker can construct a URL that still satisfies the strict filter that's going to come in and be looked at here, at this frontend part of the application but then the backend HTTP request if this API supports redirections, then you can craft the URL in such a way that this is going to then redirect to a different location. Then you can start to do some crazy things at that point, let's take a look at if this is the way it's supposed to work. Is the application user or the user sends in this request and then the back-end API calls maybe API supports redirections, and so it's redirected to this httpexample.net. Then example.net comes back to the user. That's the way that the redirection would happen. But then, of course, you can manipulate that and you can use that for not good things. Let's look at the way that the attack would work. The attacker same exact HTTP requests in terms of posts and Content-Type and all that but then it's going to say here's the stock API. Remember we're looking at that stock stuff. Here's, we like to shop blah, blah, blah. This right here is a known good URL weliketoshop.net. In terms of the URL filtering that happens here at the server, then it's going to look at, okay, hey, do I allow, weliketoshop.net? Do I allow that domain, that particular URL? The answer is yes because that's a good backend API location, API endpoint. But then as you do all that stuff, then you're going to say, okay, end your path equals, and now you're going to come right back to this internal URL slash admin again. Again, this could be any number of things. You can manipulate this however you need to. But what would happen there is the request comes in to the server, the server makes this backend API call. The API in this case supports redirection, and so it's going to redirect to this internal slash admin page. This is where you can access internal resources. Maybe this particular IP address points to some other internal resource that has an admin page on it as well that you would normally never, ever be able to get to. As the attacker, you could not just navigate straight to that location. But because of the server-side request forgery, URL redirects vulnerability of this backend API, then this thing will get you there ultimately. That is another scenario of an open redirection problem when it comes to server-side request forgery. That's another example. In this case, the attacker would be supplied the contents of this internal IP slash admin page and whereas they would never be able to get to that otherwise. There's a few things. By the way, those scenarios were taken from the PortSwigger. You may have noticed it down there on the bottom. I meant to say that PortSwigger page. They do a great job over there of explaining just all kinds of different vulnerabilities and attacks and all that. I just want to say thanks to them for those scenarios. But here in terms of protecting yourself, there's a couple of different things. If you look at the network layer, so this is the infrastructure, the pipes that everything runs on. You can segment remote resource access functionality in separate networks. When you talk about remote resources accessing your networks, you can start to do the network segmentation and that can reduce the impact of this. We've talked about that idea before in terms of segmentation or trying to compartmentalize different parts of your application or your network so that if a problem does arise, it doesn't spill or spread to the entire application or the entire network. The other one, they're enforced and I abided by default firewall policies, which is always a good idea so deny by default and then you explicitly allow things that you want to allow. You can do access control rules, that kind of thing, block all but essential intranet traffic. Those are a few other things. A couple of hints there, establish an ownership, a life cycle for firewall rules based on applications. These firewall rules can get out of control pretty quick, so it's good to have an owner of that and a life cycle to come back and look at those, like revisit those and see, hey, what's still valid, what's not valid, etc. Then you can say log all accepted and blocked network flows on firewalls. This gets back to the previous security risks, number 9 and that is logging and monitoring failures. This is one of the things that you should log from a network perspective and don't just log it, but also monitor it. Don't just write it down, but look at it, see what it says. That's from a network layer. Then also as you step into the application layer shows you, as you climb up the stack as it were, you can sanitize and validate client supplied input data. That's always a good idea. Any kind of client supplied or user supplied data, you always need to be wary of that. You always need to sanitize that and say, I don't know who that user is and it could be a bad user. So I need to validate that data, I need to sanitize that data. Don't just take it at face value. Enforce URL schema port destination with a positive allow list. This would help with some of that redirection and some of those open redirection problems that we've talked about in that one scenario. Don't send raw responses to clients. So you need to sanitize the response as well and look at like, "Hey, what did I just send to this client?" That way you can kind of check it on the way out as well. Disable HTTP redirections wherever you can. That would help, of course, with that open URL redirect problem. Then just another point down here, don't try to mitigate SSRF via the use of a deny list or regular expressions, attackers have different payload lists or tools or skills to bypass these deny lists. That's why you should do the deny all like on the firewall policy for example and then you should have explicit allow list. Instead of trying to lock down like, "Hey, I'm going to allow everything except. So I'm just going to deny these certain things. You can never keep up with that because those lists are going to change all the time so it's much safer, it's much more secure to say I'm going to deny by default and then I'm going to allow specific things. That's a better way to approach this. I would just point out too that SSRF is more than just the two scenarios that we showed here in this video. Those are two examples of SSRF, but it can certainly go beyond. There's other scenarios that could be valid or that are valid when it comes to SSRF. So I mean, I didn't want to go through every single possible scenario, but hopefully, you get the idea when it comes to SSRF that again, the fundamental idea is that you have a user-supplied HTTP request into a server and that server is going to make a request to some backend API or some internal resource but nonetheless, the request at that point is going to come from the server. Once the user has supplied the initial, the inbound HTTP request to the server, then there's going to be a request that comes out of the server to something else. That request from the server is where you can start to get into problems when it comes to the server-side request forgery because again the requests that comes from the user can be manipulated such that the server then is sending a malicious or a malformed or a not correct request to some other resource then that just turns into all kinds of problems. Again, that's kind of the basic nature of the server-side request forgery. Here's a couple of resources that you can look at. Some good cheat sheets from OWASP. That's the server-side request forgery prevention cheat sheets. So that's a good one to take a look at. You can see there, there's the portswigger.net, web security, SSRF, that's where I got some of those scenarios. A great job over there. The acunetix.com blog, there's just some good write-ups on those things. Down there at the bottom, there's a black hats document. So that's an interesting read as well. It's a new era of SSRF exploiting these URL parsers in these trendy programming languages. All kinds of details there. So great job on the black hat. Those are a variety of resources that you can take a look at to the compliment and get more of an understanding if you need to on the server-side request forgery. With that, let me say thanks for hanging in there and watching this video. Not just this one, but if you have followed every single video, it's been a lot of fun, it's been a good learning experience to walk through the 2021 OWASP top 10 lists, we've made it all the way to the end so congratulations for making it all the way to the end. I hope you've learned a thing or two, and I hope you've enjoyed your time watching these videos. I'll just say, thanks again for joining here and I hope you have a great day.
