Understanding Cross-site Scripting (XSS) Attacks: Anatomy, Risks, and Examples

15 Apr 2017 . tech . Comments
#security #redteam #dvwa

Cross-site Scripting (XSS) is a type of attack that allows an attacker to inject client-side instructions into a web application that is viewed by other users. This type of attack is very dangerous since an attacker can access the victim’s local storage and steal information like your session ID in order to deliver a session-hijacking, which can lead to identity theft within the web application. XSS vulnerabilities are at the top of the OWASP Top Ten web application vulnerabilities, making this kind of attack very valuable.

The anatomy of the attack is simple. Any user input can be an attack surface where an attacker can enter JavaScript code. If the web application returns this input to the client without encoding the < and > characters, the browser will interpret the script tags as trusted JavaScript instructions sent by the web application and execute it. From that point, the attacker can get access to the web page’s cookie:

&lt;script&gt;alert(document.cookie)&lt;/script&gt;

To demonstrate how XSS works, we can use the DVWA web application and navigate to the Reflected Cross Site Scripting (XSS) section. The form asks for our name, so let’s say we are John Smith:

xss

Then, we can inject the JavaScript code as shown in the example.:

xss

As a result, we obtained our own cookie. However, the question remains: how can we steal another user’s cookie?

It turns out that user input is sent to the server as GET parameters, which means that our JavaScript code is included in the URL:

http://127.0.0.1/dvwa/vulnerabilities/xss_r/?name=&lt;script&gt;alert(document.cookie)&lt;/script&gt;

If we send this URL to a victim and the victim clicks on it (assuming they are logged into the web application), we will obtain their cookie.

It’s worth noting that this attack can be made harder to detect by encoding the URL, making it more difficult for users to recognize that they are being targeted:

http://127.0.0.1/dvwa/vulnerabilities/xss_r%2F%3Fname%3D%3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E%0A%0A

Much harder to see that it’s an XSS attack, isn’t it?

However, the exploit is not yet complete, as our goal is to send the victim’s cookie to a server that we control. This way, we can take over the victim’s session. For the sake of this post, we will skip this part as it is out of scope.

It’s worth noting that DVWA categorizes XSS vulnerabilities into two types: Reflected XSS and Stored XSS. Reflected XSS attacks require the victim to submit the injected code, which is then reflected back to the server via the victim’s browser. On the other hand, Stored XSS attacks occur when we manage to persist the injected code on the web server itself. This is the most powerful type of XSS attack, as any user who visits the affected page will be served with the injected JavaScript code. A recent example of a Stored XSS attack was found against Twitter, where the injected code retweeted the original tweet whenever it appeared on a user’s timeline.

Let’s move on to the Stored XSS section in DVWA. This section requires us to input a name and a message. Let’s assume we are John Smith, and we will input “Hello World” as the message:

xss

Now, let’s inject our JavaScript in either of the two fields available:

xss

The injected code is now stored in DVWA’s database and will be executed every time the page is loaded. If you want to remove the injected code, you can recreate the DVWA database.


Me

A creative thinker who is not afraid to challenge the norm. His diverse track record includes failed startups, approved patents and scientific publications in top conferences and journals. On a mission to protect what matters most to you.