Cross-site scripting (XSS) attacks in Q4 2020: Trends and best practices.

By Harry Wan CISSP, CCSK, Director Cloud Security Professional Services, Verizon Media and Chris Hererra, CISSP, Senior Security Solutions Architect, Verizon Media

Web application security remains a top threat vector for organizations large and small. According to the Verizon 2020 Data Breach Investigations Report (DBIR), 43% of all data breaches involved a web application,¹ and 80% of all hacking vectors target web applications.²

In the fourth quarter of 2020, Verizon Media saw a marked increase in cross-site scripting (XSS) traffic on our content delivery network (CDN) compared to previous quarters. This blog explores some traffic data points and dissects one of the top attempted XSS payloads. We also share how to use this data to apply protective measures.

Use this content as an action-driven guide for how to handle potentially-malicious XSS traffic knocking on the front door of your organization. It may also help you have a necessary security conversation with your leadership team and your business/operational counterparts.

‍We have the data — let’s explore it

‍The Verizon Media WAF mitigated 1.5 billion requests in the fourth quarter of 2020. We define “mitigate” as any WAF event that triggered a block, custom response, or URL redirect. These 1.5 billion blocks represent HTTP requests that otherwise would have reached our customers’ origin servers. This data tells us:

1. The amount of background vulnerability scanning is immense. You’re mistaken if you think you are safe because your target isn’t worth attacking or because you aren’t well-known. According to the Verizon DBIR, “If you will allow us a mixed metaphor, there is no outrunning the bear in this case, because the bears are all being 3D-printed in bulk and automated to hunt you.”³
2. If your web applications are secured, such scanning might seem no more harmful than a burglar jiggling doorknobs, and allowing such traffic to reach your servers is harmless other than incurring additional load on your server. But in the asymmetric cybersecurity war, the attacker only has to be right once, thereby making it easier for them to be right in the future. So why let the burglar jiggle the doorknob if you can prevent it?

To drive this home a bit further, let’s take a closer look at some of the blocked traffic from Q4 2020.

Blocked cross-site scripting (XSS) traffic over the past three quarters moved from the top spot in Q2 2020 to the fourth spot in Q4 2020, nearly doubling in volume during this time period, representing 10% of blocked traffic.

Figure 1. In just six months, we saw XSS traffic more than double.

‍Getting to know your XSS traffic

‍According to the Open Web Application Security Project (OWASP), XSS flaws occur when an application includes untrusted data in a new web page without proper validation or escaping or when an application updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser, which can hijack user sessions, deface websites, or redirect the user to malicious sites.

This exposure poses a threat to your infrastructure, data confidentiality and integrity, and the availability of data delivered over the Internet. These attacks can result in unauthorized access to content, the loss of personally identifiable information (PII) and the dissemination of private/copyrighted information.

This is an issue as nothing is hidden from view once it is connected and exposed to the Internet: if you stand it up, it will be scanned. In effect, once a new web application comes online and gets exposed to the Internet, it will be tested to see how it reacts to different actions or requests. The results of these findings can create an interesting plot twist, which we discuss shortly.

First, let’s continue exploring the scope of the potential exposure. Many websites, web applications, and web servers receive and process requests from outside a company’s protected internal network. As a result, they are vulnerable to various malicious threats as grouped by OWASP, including SQL injections, XSS and distributed denial-of-service (DDoS) attacks at the application layer.

Considering the increase in XSS attacks detected by the Verizon WAF, it’s no surprise that XSS tops the list for MITRE CWE Top 25 for 2020 as well:⁴

Figure 2. A brief listing of the weaknesses in the 2020 CWE Top 25, including the overall score of each.

Just as we’ve seen an increase in the blocked XSS traffic, so are the number of actual vulnerabilities documented in the National Vulnerability Database (NVD) that are also connected to XSS exploits:

• ‍513 XSS vulnerabilities documented in the last three months (171 per month)
• ‍5,507 XSS vulnerabilities documented over the last three years (153 per month)
• ‍16,936 XSS vulnerabilities documented all time

Yes, defenders use the same tools as attackers to probe for vulnerabilities. Therefore, it’s important to recognize the potential that the existence of malicious-looking traffic doesn’t necessarily mean there is evil intent behind the traffic. But there could be.

At a minimum, if a curious bad actor successfully scans a system, they could attempt an XSS exploit — all in the spirit of performing reconnaissance. Worse, the recon activity — and the results gained from it — could be used to drop a compromising or destructive payload via XSS or used as a stepping stone to something more nefarious, such as a server-side request forgery (SSRF).

‍Is that an “eXcellent stepping stone,” I see?

‍Remember the doorknob-jiggling scenario we mentioned earlier? It’s time to bring that metaphor back.

Most XSS traffic and events may not be critical unto themselves, but they could lead to significant challenges and problems down the road — a stepping stone to a successful compromise, if you will.

Successful XSS attacks could allow attackers to execute arbitrary HTML and JavaScript in a victim’s browser. Typically, the user will need to interact with some malicious link that points to an attacker-controlled page, such as watering hole websites or advertisements.

Let’s look at the top rule violation for Q4 2020 — internally designated as rule ID 941100 — which mapped to one of the top payloads, demonstrating the ability to use XSS as a stepping-stone attack:

“><script >alert(String.fromCharCode(88,83,83))</script>”

This is a very common XSS test string that shows up in many code repositories such as htmlpurifier.org.⁵ While looking to validate this particular payload will work, a popup alert box with the string “XSS” is displayed, immediately verifying to the attacker that a specific website is vulnerable to reflected XSS.

Once an attacker verifies that a reflected XSS exists, the “reflected attacks are delivered via another route, such as in an e-mail message, or another website. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user’s browser.”⁶

Figure 3. How cyberattackers leverage XSS vulnerabilities.

This attack can perform anything on the website the user being attacked can perform, including the “disclosure of the user’s session cookie, allowing an attacker to hijack the user’s session and take over the account.”⁷ For example, a script changing a user’s password submitted on the user’s behalf can result in account take over.

There are other stepping stone examples to draw upon. In another publicly-documented case, an SSRF attack was originally started via an XSS exploit, and the security researcher “was able to escalate from XSS inside of an image all the way to arbitrary local-file read on the server.”⁸

Not every researcher (nor cybercriminal) will be patient enough to link their XSS exploit to something more meaningful. However, holding an XSS for bigger and better things does appear to be a common method for some researchers looking to score the big prize in their bug bounty programs.

‍Mitigation and defense‍

In the absence of data, it is hard to make a decision. However, once you have visibility into a situation, it becomes easier to identify a path that leads you to the desired outcome. Here is a collection of tips and resources to help you mitigate the risk XSS traffic brings to your network and your business.

1. Ensure you are aware of all Internet-facing devices and that both legacy and testing systems are either considered for hardening or taken offline. This is especially important in the era of cloud infrastructure, where development teams can spin-up machines with just a few clicks or by submitting a form.
2. Properly configure and harden web servers. Consider using tools like Center for Internet Securities Benchmarks to understand how to configure your server’s controls. Properly configure your TLS configurations to protect against MITM attacks.
3. Regularly patch all Internet-facing servers. Sometimes, commonly used frameworks are vulnerable to XSS. As of February 2021, MITRE’s ATT&CK database lists nearly 17,000 vulnerabilities and weaknesses with some connection to XSS.
4. Periodically verify the effectiveness of your security hardening. Use the same dynamic application security testing (DAST) tools the attackers use, such as OWASP ZAP or similar vulnerability scanning tools in Kali Linux. Alternatively, use a DAST or penetration test service to discover and scan for vulnerable internet-facing servers.
5. Enable a web application firewall (WAF) to block common attacks.
6. Keep the WAF updated to block any discovered vulnerabilities immediately to allow the application team to deploy a fix. Update the WAF as new rules are available to protect against newly discovered vulnerabilities.
7. Enable logging and inspect those logs.
8. Protect your websites and critical network infrastructure from volumetric attacks by using a highly redundant authoritative DNS service as well as using highly distributed DDoS protection and web acceleration services i.e., the CDN.‍

Start with your data‍

You may have your apps finely tuned to deliver content — and you may have a robust set of security controls to help mitigate risks and perhaps even block attacks that make it inside. Still, why let potentially-harmful traffic enter your network in the first place? Why take a chance that a policy is missed or a control is bypassed?

Verizon Media Security customers have two capabilities at their fingertips that can protect them from threats:

1. We provide a view of potentially harmful (or at least unhelpful) network traffic hitting your site.
2. The integrated Verizon Media WAF can be enabled to automatically block malicious traffic before it becomes a problem.

To learn more about the current state of web app attacks and the cybersecurity threat landscape, please join us for the upcoming Verizon Threat Research Advisory Center Monthly Intelligence Briefing (MIB) live on March 17, 2021. Secure your virtual seat now.

Take an important step to improving the security of your web applications, sign up for a free 14-day trial of our CDN Edge Security Solution. Why let the doorknobs get jiggled if you don’t have to? Learn more and sign up for the free trial now.

References

1. Verizon, “2020 Data Breach Investigations Report,” Verizon.com/business.com, enterprise.verizon.com/resources/reports/dbir/. Page 7.‍
2. Ibid, page 88.‍
3. Ibid, page 23.
4. CWE, “2020 CWE Top 25 most dangerous Software weaknesses,” CWE.mitre.org, cwe.mitre.org/top25/archive/2020/2020_cwe_top25.html.
5. HTMLpurifier, “HTML purifier XSS attacks Smoketest,” HTMLpurifier.org, htmlpurifier.org/live/smoketests/xssAttacks.php.‍
6. OWASP, “Cross site scripting (XSS),” owasp.org, owasp.org/www-community/attacks/xss/.‍
7. Ibid‍
8. Buerhaus, Brett, “Escalating XSS in PhantomJS image rendering to SSRF/local-file read,” buer.haus. 29 June 2020.