Welcome to the third and last part of the server-side request
forgery session in this part. We
will discuss server-side request forgery, mitigation.
We will start discussing what makes an application vulnerable. Since
I've asked Jude Shop is open source. We will spot
the vulnerable source code. Then we will
discuss how to avoid such a vulnerabilities applications
that allow users to provide URLs to be retrieved from
remote locations such as profile. Pictures are
likely to be vulnerable to server-side request forgery.
Other common scenario is when users are allowed to
provide webhook handlers or a callback URLs that
the server is supposed to contact. When some event occurs
note that not always users have
to provide complete URLs, Sometimes some user provided
data. For instance, in a URL parameter or
submitted on a form, may end up appended to
an internal or external system base URL.
Also note that some URL parsers do not handle URLs
properly and that can be exploited by
attackers to coerce the application to issue requests to
unexpected locations.
Let's see. What makes Juice Shop vulnerable.
We've exploited server-side request forgery on a profile
route. Let's find its implementation.
This looks like a good candidate.
On line 17, we have the user provided URL.
And here we have the server-side request to
fetch the image. As you can see, there
is no validation upon the user provided URL.
Let's put how the response is handled.
In case the remote server returns some content. The
local file extension is computed based
on the user provided URL. If it
is on the list, otherwise, it
use a default extension.
In this case, the file is named after our user ID
plus the computed file extension.
If the remote server fails to return a response, then the user profile
is updated and the profile image set with the
user provided URL and changed. Let's
discuss how to prevent this issue.
In general, it is a good security practice
to denial Network traffic and exceptionally,
allow Communications between two systems affect
strictly required system components
that are supposed to access remote resources, should use
a separate Network. When the
application fetch remote resources based on user
provided input, either complete URLs
or just some parameters, such input
should be properly sanitized, according to the
context where it will be used in forcing the
URL, schema port and destination based
on the positive list of allowed values may
prevent the application to contact. Unexpected locations
response is returned by
other systems, shouldn't be sent to the
client services since they may include sensitive information and
HTTP. Redirection should be disabled. This.
Is it about server-side request forgery, although
it was not part of the
Stop 10 2017 since it was added to
the 20 21 Edition and it was the only should not
covered in this course. We decided to add it
later on to keep you up with the most critical web application,
security risks, as Next Step, consider
reading the last top 10, 20, 21, and
other relevant or wasp resources.