OWASP TOP 10: XSS (DOM) Attack - DVWA

NOTE: Click on the photo to zoom in.

Today, we will be covering XSS (DOM). Our goal for today is

• Learn the methodology behind XSS (DOM)
• How to carry out an XSS (DOM) Attack
• Network Perspective
• How to detect an XSS (DOM) Attack using snort?

Before we move into XSS (DOM), We need to know what XSS is.

XSS stands for Cross-site scripting. Attackers would send victims links that contain malicious scripts. Then, once the victim clicks on the link, the browser will respond to the link, execute the script, do whatever the malicious script says, and potentially transfer information to the attacker.

Visual representation:

Methodology

XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client-side script so that the client-side code runs in an “unexpected” manner.

The page itself (the HTTP response) does not change, but the client-side code in the page executes differently due to the malicious modifications in the DOM environment.

This is in contrast to other XSS attacks (stored or reflected), wherein the attack payload is placed on the response page (due to a server-side flaw).

From DVWA: “DOM Based XSS is a special case of reflected where the JavaScript is hidden in the URL and pulled out by JavaScript in the page while it is rendering rather than being embedded in the page when it is served. This can make it stealthier than other attacks, and WAFs or protections reading the page body do not see any malicious content.”

Carrying out an XSS (DOM) Attack

Objective:

Run your JavaScript in another user’s browser, and use this to steal the cookie of a logged-in user.

This is what we’re given:

What we can do to steal a user cookie is the following:

Set up our HTTP server:

Then craft our malicious script:

Let’s use this as our template:

“http://172.20.25.16/DVWA/vulnerabilities/xss_d/?default=English”

http://172.20.25.16/DVWA/vulnerabilities/xss_d/?default=

Once the victim pastes it in the URL, we will get the cookie. To make the link not noticeable, we can shorten it.

Medium:

The developer has tried to add a simple pattern matching to remove any references to “<script” to disable any JavaScript. Find a way to run JavaScript without using the script tags.

Hint: You must first break out of the select block, then you can add an image with an onerror event

Command:

1

/vulnerabilities/xss_d/?default=English>/option></select><img src='x' onerror='alert(1)'>

We would get something like this:

The code would look like this after execution:

As you can see how a section of code in the URL fits the overall picture, we escaped the option block and then the select block and inserted a section.

High

The developer is now safely listing only the allowed languages. You must find a way to run your code without it going to the server.

Hint: The fragment section of a URL (anything after the # symbol) does not get sent to the server and so cannot be blocked. The bad JavaScript being used to render the page reads the content from it when creating the page.

Template:

1

http://172.20.25.16/DVWA/vulnerabilities/xss_d/?default=English

URL:

1

http://172.20.25.16/DVWA/vulnerabilities/xss_d/#default=<script>alert(document.cookie)</script>

Network Perspective

We will set up our packet capture in pfSense and redo the attack. Then finally, analyze the packet capture in Wireshark.

I will not demonstrate how to set up packet capture in pfSense because I have shown the steps many times. So, I’m just going to provide the packet capture.

Low: Since a lot is going on, let’s filter it to HTTP.

Here we see a GET request to English. Then, we see another GET request that is holding the XSS injection. If we were to decode the URL, we would be able to see the command using cyber chef.

1

default=%3Cscript%3Ealert(%22Hacked%22)%3C/script%3E

I’ll set it to High mode and capture the attack from there since I expect this mode to differ from the rest.

High:

When we open the packet, there’s not much going on. However, the most important thing we’re focusing on is HTTP GET:

We can see that the Request URI is /DVWA/vulnerabilities/xss_d/. But wait, I thought we sent: “” what happen to the rest of the code?

The (#) act as a comment. What the web server does is it takes: “http://172.20.25.16/DVWA/vulnerabilities/xss_d/” then take the rest () is left behind.

How to detect an XSS (DOM) Attack using snort?

There is some approach to this. We could create an alert that only detects