Welcome to the server side request forgery session, since
server-side request, forgery was added
to the WASP, top 10, 20 21. We decided to
provide you an additional session to make the transition from the 2017.
Addition. This course is based on if
you want more details about what has changed in the top 10.
Please refer to the previous session of. This course, this
is the first of three parts. And for now,
we will focus on threat analysis.
We'll take our time to dig into what server-side request
forgeries. Then we will discuss how
the system can be harmed. The impact of a successful exploitation
and give you some insights to
identify who may want to harm your system. The
name server side request forgery is almost self-explanatory.
It occurs whenever I web application,
fetches remote, resources, without validating the
user, supplied URL, or at least parts of
it supplied, this perimeter,
Yes, nowadays. This is a common feature. Sometimes
provided to end users as an alternative to
file uploads allowing users to provide an URL
to download and use an image as Avatar. Is
a good example of such a feature when an application is
vulnerable. Then the attacker is able to coerce it to
send crafted requests to unexpected locations either
internal or external. The
most common server-side request, forgery flow evolves,
three parties, the attacker the
Application in the Target application. The
one the attacker wants to reach through the vulnerable application.
First, get a curse ends a specially crafted HTTP
request to the vulnerable application which will
create a new request. Based on the attackers request billowed.
The targeted application can be
an internal or external system. The targeted application.
Sends the response back to the vulnerable application
and the vulnerable application sends the response back
to the attacker, including the contents returned by the
targeted application. Note, that, in most cases,
from the targeted application perspective. The request was
United in the vulnerable application.
User control data is the most common attack Vector. Whether
users provide full URLs or just a few parameters
that are appended server-side to a base URL.
If the application is vulnerable to XML external
entity injection, then it can be exploited to
perform a server-side request forgery attack.
Being able to coerce the application to issue Network requests.
May allow a attackers to perform a port scanning. Both
an internal and external systems. When
the target application is an external system. The attacker may
use the vulnerable application, just to hide his activity. Attackers
may be able to access sensitive data,
stored in local files or other systems such
as databases that are not exposed to the internet, accessing
cloud services. Meta data, storage has
been one of the most common server-side request forgery.
Scenarios often internal systems tend
to trust on each other more than in public facing systems exploiting
a server-side request forgery. Vulnerability
attackers may find a way to exploit this
and conduct further attacks such as remote code execution on
other internal systems.
Threat agents, maybe someone interested on your user
data or system internal information. Nevertheless. You
should consider that attackers. May exploit the vulnerability in
your application to hide their activity. While attacking a
third party system.
Note that this table does not exist in the WASP top. Ten twenty
Twenty-One addition to keep this session aligned with
the rest of the course. I've used the WASP risk rating methodology
to compute, the exploitability detectability, and
Technical impact. Prevalence, was
computed based on the last top ten, twenty Twenty-One contributed data,
take some time to review it and
then read the server-side request forgery section. In do ask
top 10, 20 21 website in
the next part.
We will exploit server-side request forgery in
our intentionally, vulnerable application.