Welcome back to the server side request forgery session.
In this second part, we will exploit server-side request
forgery in our intentionally. Vulnerable application. We
will jump straight to our intentionally vulnerable application, and
then move on to the mitigation part.
As discussed in the previous part nowadays. It is
common allowing users to provide a URL to fetch a resource as
an alternative to file uploads. This is a
feature. We usually find as part of the user profile settings to
choose a profile picture. Let's sign up
for an account and see if George shop offers such a feature.
And here it is. The feature we were looking for.
Let's play a bit with it to understand how it
works.
Based on what we can see here. In the Dom, the server, fetch
the image based on the given URL and stored it
locally. Let's see what happens if the URL
points to nowhere.
In this case, the application used given URL, is
this only based on this Behavior, we
can use this feature to understand what internal services are
running in the server.
Since no local resource was created. No,
internal service is listening on Port 80. Let's
try another one.
Again, no, internal service. Listening on Port. 80
8. Let's try it once more.
This time a local resource was created. Meaning
there's an internal service listening on Port 3000.
The application backend server expects, given URL, to
point to an image file, but URL, we provided is
unlikely to return an image. Let's download the
local resource in play with its extension.
Despite the file extension. Let's check. It's mime type.
In fact, what's inside? The file is HTML. What
would be much more likely to be returned by an HTTP service?
Listening on random port?
Based on the content. What we have is the Juice Shop homepage
market. Now. We have an idea of
Juice Shop internals since the public address,
used the default HTTP Port, but internally,
the mark-up is returned by a service listening on
Port 3000. We can assume that
there's a reverse proxy in the middle and Juice Shop. Back-end
server is likely to run inside the container. It
may not sound that impressive but you can keep
trying other port numbers to scan, what services?
Running internally as well as different resources.
Keep in mind that the services you may Reach exploiting This
vulnerability. They believe that it's the Jewish shop back-end
server, who is making the requests sometimes,
because internal Services tend to trust another
internal Services relying on the request origin.
You may end up accessing sensitive, internal data.
In our next video, we will discuss what makes
the application vulnerable and how to prevent it.