in today's class. We're gonna talk about server side request forgery.
A lot of people find these vulnerabilities confusing or hard to understand.
So to keep it simple, let's forget about the forgery part.
And let's just talk about server side requests.
Previously we learned when you try to access a website,
you basically communicate with a computer
that has a certain program installed on it that we call a web server.
And the web server can serve you files, images and so on.
And it can also interpret or execute server side languages like PHP python and so on.
Now a lot of web servers do much more than simply serve you files and execute code a
lot of the time they actually communicate with other
servers for example and here we have an example
of a web server that is communicating to another
server in here that we're calling server one it's
communicating to it by sending a request to this
server's address which is server one dot com.
Or it could be the I. P. Of this server.
And then as a result it's getting user information.
Now it's probably doing this because this is
a protected server that contains private information.
But we'll talk about that later.
Right now, basically what's happening is you as a user is using a web server.
The web server can serve your files, images and execute server site code.
But to get the user information it actually makes a request to
another server in here and then serve you the user information.
Now. Again in many cases websites these days do so much more than that.
So they might even have a shop and to do that.
They communicate with another server to get your products or
to get you your Visa card information so you can pay
or to get you the stock of the amount of
products that they have in their stock and so on.
And to do that,
it's making another request to another server in here
and it's communicating to it using its domain name.
But like I said, it can also communicate to it using its address.
I should also mention that these servers could
exist on the cloud in a completely different
location or they might be connected to the same network as this computer in here.
And as we know, a server is simply just a computer.
So this right here could be just another computer with a certain application
installed on its same goes to this and this device right here.
So what we have right now is a client making a client request to the
web server and then the web server is making server requests to other servers.
So this is an example of a server request and this is an example of a client request.
And if you remember previously we actually
covered CSR f vulnerabilities where we manipulate the
client request and get the client to submit something that they don't want to do
and in server side request, forgery.
We manipulate the server and make the server submit
requests that it is not programmed to send.
And as a result give us useful information as hackers or pen testers.
So going back to this example right here,
we have the client request in here to the web
server and then the server side request in here,
going to another server
and a server side request forgery scenario.
As a hacker, you would send a forged request to the web server.
And as a result you could get the web server
to go and submit requests to a completely different server.
And as a result,
if you are hacking the server or if
you are submitting anything malicious to the server
when this server is analyzed,
it will seem like this server is the one that is trying to hack into it and not you.
That's just one simple example.
You can also submit requests to one of the
servers that this server is usually communicate to.
So if you remember we said this server might be communicating with
this server to get user information as you can see in here.
And this server is actually a protected server.
So if you try to communicate with it directly,
your requests will be denied because this server only communicates with
this server because it probably has a whitelist or a blacklist.
So it wouldn't communicate with you but it would
communicate with this web server because it trusts it.
So assuming this web server is vulnerable to a server side request forgery,
you would be able to send a forged request to this web server.
And then instead of simply asking server one dot com,
you're gonna ask for forward slash private.
Which in this scenario for example would
get you private information about the user information
that this server has like their passwords or address or phone and so on.
Now this is only possible and this will only work
because this server right here trusts the web server.
So if you send that request directly from the client,
it will be denied because this server does not know who you are and does not trust you.
Another scenario of exploiting server side request forgery. You can simply send a
request to the server and cause it to send requests to itself.
Again,
probably bypassing security measurements and firewalls that this
server has because you're simply sending these requests
from the server itself and overloading it by
requests that are originating from the same server.
You could even send forest requests to
this web server to discover the internal network
and possibly even discover the open ports or the running services on these ports.
And then from there discover vulnerabilities that these services
might have and maybe even gain full control or
code execution on the server or one of the
clients that are connected to the same network.
So the impact of server side request
forgery could be minor or very devastating depending
on the web application in here and what you can do with the exact vulnerability.
So as we've seen, you can simply just send requests to other servers,
you might be able to use it to access
private data that is only available to the server.
Or you could get it to disk, cover other clients in the same network,
you could get it to discover other services
running on these clients on the same network.
And you can even gain a remote code execution from these vulnerabilities
and don't worry about all of that.
We're going to spend a lot of time on these vulnerabilities.
You'll understand the impact of them better and you'll
have a better understanding on how they work,
how to discover them and how to exploit them.