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:
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.
Getting to know your XSS traffic
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:⁴
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:
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.
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:
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.”⁶
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.
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:
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.