Welcome to cross-site scripting session.
India's first part, we will focus on threat analysis. We
will take our time to discuss, cross-site scripting details, then
we will discuss how the system can be
harmed, then, backed off, successful, exploitation, and
give you some insights to identify who may want to
harm your system. X access for cross-site scripting is
a type of injection in which malicious scripts are
injected into otherwise Bennigan's interested websites. We
have already discussed injection flaws, but cross-site scripting
was so prevalent. And
Civic that it was given its own category in
the last top 10. It has remained in
the top 10 for several editions. Although it has
dropped from 3rd to 7th in the 2017 top
10. It is still the second most prevalent issue
affecting around two-thirds of all applications. Let's
see how it works. In this picture. We're
searching for banana juice. We first
type the keyword banana in the search field. The
page was reloaded and the results.
Matching our search criteria rendered on
the screen. The Red Arrows point to places
where our keyword appears on the page. Let's
see this in terms of HTTP requests and responses, after
typing our search keyword. Banana, an
HTTP request is made to the server client issues,
a get request and our keyword is
sent as a query string parameter Q. When
the server receives the request, it reads the query string parameter
runs the database query to retrieve
Records matching, our search criteria and
then computes the final HTML output to be rendered client
site with all matching records. Then
the server responds to the client sending the
final HTML to be rendered. Note that
our keyword is also outputted as part of
the HTML and this is where troubles begin. What
If instead searching for banana, we decide to
search for an HTML tag from the
request point of view, everything Remains the Same.
Same the server may not find any matching
records in the database but is still outputs our
searching keywords next to search results. Title, has
highlighted with the red background, when
the browser receives the HTML to render. It doesn't know that the
highlighted part was provided as part of the request. It
just knows that the server sends these HTML to
be rendered. The HTML tags script has a
special meaning, and the code inside the tag is executed that
JavaScript popping up the model box saying X.
In this scenario, sharing the URL with other users will
trigger the same behavior in their browsers. Meaning
that we can run arbitrary code remotely. There
are two main types of X access server.
X access is exactly what we have discussed
until now, user-supplied data. Our
search keyword is included in an HTML
response generated by the server.
In the described scenario. Our search keyword is not stored
anywhere in the server. It is sent as part
of the request and returned in the response due
to this fact, it is called reflected server access
if it was stored somewhere such
as, in a database and later included in
another response, such as a product reviews, then
it would be called start accesses. The
other type is client xss in
this case, and
To data such as a user supplied data is used to update the
Dom using an unsafe, JavaScript call. Imagine
that web application uses an API to perform product
search. In this case, the server responds with
a Json object, including the list of matching products when
the API responses arrives, the web application copies, the
content in the search input Fields appending it to
the Dom next to the search results title, and then
the list of matching products in this scenario,
the X access payload was not part of sir.
A response instead. It was gathered from client-side input
field, and appended to the dawn.
There's also reflected and start client access, but
you're better reading about it in the WASP website. Let's
discuss about attack vectors.
Let's put things simple regarding X access
attack. Vectors. You just have to
focus on user controlled data, regardless its source, URL
parameters and form. Data may be the first things to
come to your mind, but there's a lot more. You
should realize that users control the HTTP request and
so request, headers and cookies may
also be sources of hostile data.
Browsers. Local storage is another typical attack
Vector since malicious actors may be able to tamper with
it.
If your application expects file uploads, such as photos
and then you reading the photos metadata, then
it can also be used as an attack vector.
Finally, a less obvious source of all style data, external
Services. If the application retrieves
data from other services, for example, by
means of apis malicious actors, may
decide to go after those third party Services, indirectly
compromising your application.
Any data source is a potential attack vector.
Keep in mind that attackers will be able to execute code remotely on
victims browsers.
The first thing attackers will look for is a session tokens. If
they can actual trade such token from a victim's browser,
chances are they will be able to use it in
another browser to impersonate the victim. This
is called session hijacking.
Even if session hijacking is not possible, attackers
will be able to use JavaScript to automate tasks
to scrape user data from the Dom or to do
some actions on victims behalf. Such as fraud one transactions, being
able to execute code remotely in specific Pages.
Such as the login page may give attackers access
to credentials. There are other techniques
to trick the browser and password managers to lie credentials among
other impacts attackers will always
Able to exploit the trust relationship between the victim and
the website Warner driving the former to
download and install malware. Technical skills
are required to identify and exploit the cross-site scripting
vulnerability. Nevertheless. There are automated tools
to assist this task and plenty of information about
the subject.
Threat agents, maybe after specific to victims targeting
an application administrator may allow attackers
to gain control over a privileged account and access sensitive
data or shut down the system.
On the other hand attackers may be interested in
the particular individual. Let's say a VIP.
If your application manages sensitive data, such as health
records, a success xss exploitation
may give attackers access to sensitive information
regarding that individual.
Xs/s. Can also be used for widespread attacks. It
happens already in the past, creating a warm effect
to identify threats agents. Consider,
who may wants to gain control over your application and
how sensitive is the information your application managers,
and who may want to access it.
You'll find this table in the last top 10. Pause
the video and take your time to carefully, read it.
The next part, we will exploit X access on
our intentionally vulnerable application.