This is a transcript of the A10 - Server Side Request Forgery training session. Click here to return to the OWASP Top 10 Security Vulnerabilities page.
Fabian Franz: [00:00:00] Anyway, let's go over to server-side request forgery. In essence what I've shown you with XML external entities is a kind of server-side request forgery. Service side request forgery means essentially I need to tell a server to, that it loads a certain URL for me. It does a certain thing. And as you have seen from the other things that Janez, for example showed before cross site request forgery, for example, or other parts can be nice to use to also be able to see certain things that are making it problematic to do server side request forgery, which means in a sense, if I'm able to have a cross site request, forgery problem, somewhere on some backend server. And as I said, it could sit in some forgotten corner, [00:01:00] but now I can trick, like for example, a SOLR server or log for JSON to make a request.
Suddenly, I get an exploit the opportunity in an otherwise open system. So what has changed over the last years is that we don't have this like little silos anymore where you have a server and just configure with just, mySQL, Apache, PHP, et cetera, like that, like the typical LAMP stack, you know, Apache, mySQL, PHP.
Um, but what I see now is that the well, it gets a lot more complex, especially with communities cloud formation, things, et cetera like that. So it's much more often happening that we are fetching things from another server, just to be able to, to see things like that. And I think that that's a really important point here.
That's why it [00:02:00] was not there. Um, That we need to really ensure that no one is doing outgoing things. And one of the easiest things you can do is to add ACLs to your server. For example, at a large enterprise client. It's absolutely standard security practice. And we do that for our properties as well. Um, to just not allow access to the internet from a server, this can feel really, really bad at first because, Hey, how can I do updates?
Like how can I do like an appget update, RPM update, whatever. Um, how can I do other things, but if you have only trusted end points that you can reach from a server, your attack surface vanishes a lot. Because if from that one server you've been able to trick it into a server-side request forgery to make a request to something in [00:03:00] the internal network, it cannot access anything in the internal network except itself. And maybe it's other web head peers. Then you did not win any kind of privilege escalation at that point. However, if there's no firewall rules and you can have everything outgoing to that, I could access a Memcached server that's sitting somewhere.
Maybe I could try to get access to a REDIS instance. That's not password protected, something that a lot of things can happen. And that brings us to the next point to prevent the other side request forgery. And the next important thing besides trusting your input or ensuring no trusting that you've correctly um, checked your input. So not trusting input and knowing which input you can trust and which input you can't trust. Um, it's very important to also [00:04:00] see that, that you are not allowing like sync like an open password, because for example, if you had, memcached running and the webhead can access it because it needs to do cache get cache static, work fast, actually.
Um, and you have the server-side request forgery where someone can do a little request to the memcache and get some data back then you've opened your door much more than if there's a password in front of it. And someone would need to use an API function to actually do as, as access or sv-side had already, already oversee XML external entities, settings, PHP, or password or PHP or whatever the web server needs to access the mySQL. And again, you have more credentials, so yeah, but going back to this trusting of input again, the most important thing is to never trust anyone. Because for example, let's say there's a trusted peer. Who's sending you log [00:05:00] messages and you're saying, Hey, log messages are fine.
They're just log messages. What could ever go wrong? And as we've seen in the log4j example, a lot can go wrong because the log4j can actually yeah, lead to some unrelated system, doing something that you've trusted it because it has been just log messages. There's nothing wrong about that.
Or SPS on the XML example, let's say you were expecting HTML from some other trusted source, but certainly that trusted source had an exploit and while their system. You could not really do something, but because you are receiving this HTML and you have like this XML entity problem, suddenly this trusted systems sent you untrusted content and it leads to much larger security problem.
Then if you had said, Hey, I think this is a trusted system, but trust, [00:06:00] but verify. And I think that's a much more important here as well in terms of XML entities to can determine the schema before. Uh, there's some nice code for doing that in terms of external links, you can check that those links are only two things.
You want them to go into terms of my SQL strings like my SQL injection. You would validate that, but another nice service site request forgery is for example, Apache SOLR. Um, if you were to be able to trick a web server to make a certain request to Apache SOLR, you could, for example, Make it rebuild a dictionary and because it takes awhile.
And if some service depends on those dictionaries being there, like for auto complete or suggestions, and then you could even denial of services, Apache SOLR. So just by sending it, Hey, rebuild it, rebuild it, rebuild it, rebuild it again again again, and this is kind of like what they're saying here. It's not enough to [00:07:00] just deny based on regexp or whatever, because people are finding very, very creative ways around it.
log4j, it was solved three times because they were like, Hey, we've mitigated that yet. And then another thing came in and log4j by the way was very similar to XML external entities again. You're able to reference something external, which was then part of your log message here. Uh, just a Java default functionality.
Very useful. Not as useful for this case here. And yeah, but here they are also saying you want to lock all accepted and block network flock flows on firewall. So if you see something like, Hey, there's someone trying to access something that they shouldn't from the internal, it's a very nice first step to block it.
But the next step is to also lock it because it gives you an idea of that you are dealing with server-side [00:08:00] request forgery. So security also always means to have a telemetry system. So you have always this kind of level of noise of errors happening, but if there's a lot of error suddenly happening at a point, and you're logging these like ACL failures, for example, then you now either they're spec in your application, but it's really good when, you know, Hey, that's someone trying to attack me right now and that's not a good idea.
So, yeah. Again, from the application layout just covered a lot of third already. You want to sanitize and validate everything, verify everything. Even if you're saying it's a very trusted service sending as a data and it uses XML or heart or something else validated ensure that what you're getting back is what you expect and is not completely something different.
And as an example, never, ever, ever send serialized data, PHP serialized [00:09:00] data across the wire, because it's so easy to explore it. It's like yeah, it, cache might be still okay. Or I mySQL because, well then you now that you've serialized that, but in theory, we even that as already a little bit insecure, because what you would want to do is you want to sign it.
And often you don't have the time or you want to don't use the computational effort, but in an ideal scenario, anything that you serialize as PHP you want to cryptographically sign because if anyone is in virtual teams, it, unless they have the key, they are not yet in. And if they have the key, you have other problems anyway.
Um, yeah. Then it's also important to not send our response to clients. We've come at that a lot, a little bit already in the security misconfiguration. Um, that's really important to to not just have logging [00:10:00] enabled, because for example, if it has like, Hey to SOLR sent back the message that here's your /etc/passwd.
And that's a very error and you're showing that to the user. Well, now you've exposed what before would not only have been ended up in some log file, to the attacker. That's not a good idea. HTTP redirections, also important thing, a lot of classes because in Drupal security problems if you're covered on previous security trainings has been to trick Drupal into using a destination parameter that was then redirecting someone to an external attacker side.
So I'm sending you a link to drupal.org/veryspecialparameter and then you think you stolen Drupal.org, but you are in, in reality, you are on Drupal attack, attack.org, and you're not seeing it. You're putting in your password, et cetera, and I've successfully done a phishing attack. So that's really important.
Yeah. [00:11:00] And another important thing is you could trick someone and you need a lot more infrastructure knowledge for that. But for example, you've tricked someone to try and get them to that DNS resolver address. DNS is still often unencrypted in the internet. So that's really important. Uh, part of thinking about if someone is able to get into your local network folks, now others, they can spoof DNS responses.
And if they are then not using TLS to, for example, access your REDIS cache server, you could be accessing the attacker's cache server instead. And that's also why it wouldn't shouldn't ever store sensitive information in caches or whatever like that, just as an aside. Oh, and the other thing is a VPN if you're using Docker for for example, for, [00:12:00] um, that one of the interesting, most interesting server side request forgery happening is that someone is attacking your local system that is going on a VPN.
So some bad actor was in a corporate VPN, this obviously non B or now that but just assuming that is able to hack your local machine and we are that they can then hack further into their network. Yup. And yeah, I think that would be at first when I said request forgery, we all sort of time, so that's a good time to stop and maybe take some very last questions.