XSS (Cross-Site Scripting) vulnerabilities are frequently discovered during web application penetration tests. These XSS vulnerabilities are considered a risk in web apps – as they can be present anywhere user input is reflected. In fact, even though it’s no longer on the OWASP Top 10, XSS still accounted for over 50% of high-risk findings in 8,000+ penetration tests conducted by BreachLock in 2021.
Testing and remediating XSS in web applications is an important skill to have in DevOps, as XSS is an ever-present vector for web development teams. In this article, we’ll first cover an overview of XSS vulnerabilities and why they are so common. Then, we’ll dive into one of the most popular vectors for XSS vulnerabilities – the popular “add a link” feature. The “add a link” feature is one of the most common features in web applications today and can be used to execute XSS attacks. Read on to learn how you can discover, remediate, and prevent XSS vulnerabilities on any web app link features to prevent XSS-related attacks.
What is Cross-Site Scripting (XSS)?
The term Cross-Site Scripting, better known as XSS, refers to a type of web application attack that allows the attacker to compromise the users of the targeted web application. A web application infected with an XSS vulnerability can be exploited by an attacker injecting malicious scripts that can execute as soon as a user loads the infected page. Learn more about discovering XSS vulnerabilities, remediation guidance for XSS, and preventing XSS vulns in the first place here.
Why are XSS vulnerabilities so common in web applications?
There are several effective, published techniques, tactics, and procedures (TTPs) that can be used to exploit XSS vulnerabilities present in web applications. An attacker can use XSS to cause problems for other users, compromise data, and interrupt business operations for their objectives. Considering these are web-facing vulnerabilities, XSS poses a critical risk for remediation and mitigation over time.
For example, many web applications, including leading social media platforms, ask users for URLs to share outside links. Any time a user is prompted to provide a URL, this is a potential vector for XSS. Many web applications are not developed with the right code implemented correctly for client-side and server-side validation. If that web application unintentionally allows users the ability to inject client-side scripts that can affect other users, the web app is vulnerable to an XSS attack.
Let’s say you are an admin for a company that approves home loans from an online web application vulnerable to persistent XSS via an intended link feature. A normal user would use that feature to add a link to an external document or image, while an attacker can use the intended link feature to craft an XSS payload that automatically approves the loan as soon as the admin opens their application.
How XSS Works on Common Website Applications
Web applications collect and transport data from user input. That user input must be cleaned, or sanitized, and there are a variety of methods applications can use to sanitize user input. In UI testing or a penetration test, these sanitation methods should be examined to eliminate or mitigate any potential for XSS. If not fully tested for, a vulnerable endpoint can allow malicious actors to embed their own pages, steal sensitive info from other users, perform unattended actions as the affected user, or deface the business.
Let’s further delve into how XSS vulnerabilities can be exploited within the way HTML code functions on websites.
Common Tags Used in HTML Code and How Hackers Abuse Them for XSS
HTML code uses a series of tags, URLs, cascading styles, and code actions to run a web application. To see how this works on the internet, you can inspect the code on a webpage by following these simple steps.
- If you hover your mouse over your browser and right click, you will see the “Inspect” code option. It will look something like this:
- Clicking “Inspect” will show you the HTML code for that webpage.
- You’ll notice that sections of the page are divided by tags, with identifying tag types which tell the web browser how to process or render the data.
For example, let’s look at these HTML snippets to understand if these tags work in HTML code.
The tag type highlighted in the second line, “embed” tells the browser to render the website specified as the “src” within the current application’s page. This is useful when dynamic content like ads, feeds, social media pages, etc., need to be included on a page.
Similarly, in the example below, the “iframe” tag is used to embed a webpage inside a webpage.
The code snippet below shows how the “a” tag is used to create clickable links.
In all four types shown above, the hyperlinks are using the “https” protocol.
XSS Example 1:
XSS Example 2:
Preventing and managing XSS risks in web apps ensures that threat actors cannot weaponize web-facing assets, utilities, or properties to execute XSS attacks. In order to prevent and mitigate XSS, it’s important for DevOps and security analysts to understand the nuances of the XSS types.
Persistent XSS vulnerabilities in applications refer to vulnerabilities that save these payloads on pages that may be shared by a single user or multiple users. Persistent XSS vulnerabilities pose significant risks to business applications, as a malicious user can leverage this to force other users to perform unintended actions within the app, including the following:
- Share authentication + IP
- Download a malicious external file
- Take a screenshot that is then shared with the attacker
Recall the example from the beginning of this article about approving home loans from an online application with exploitation of persistent XSS as a system admin via an intended link feature. As we mentioned, a normal user would use that feature to add a link to an external document or image. That’s fine. But when an attacker uses the intended link feature to craft an XSS payload that approves the loan as soon as the admin opens their application, that is an XSS attack with immediate financial impacts associated with it.
Preventing Persistent XSS in Web Applications
The best solution for any developer, DevOps engineer, or security analyst testing web app security to remediate persistent XSS vulnerabilities is to implement filters. This helps eliminate the potential for abnormal data in the user actions.
To prevent a persistent XSS vulnerability from being exploited with abnormal user input that could be acted upon, take these steps:
- Apply protocol filters in the web app to sanitize user input intended to become the “src” or “href” on tags.
- Ensure protocol filters are added to both the browser side and server side. This prevents attackers from generating requests to the application’s server directly without using the web application. It also prevents them from using cURL commands and Proxy services like Burp Suite to inject malicious XSS into web applications.
DOM based XSS
Another type of XSS that might come from purposely implementing a user link in the HTML is DOM based XSS. This type of vulnerability takes advantage of the client-side environment in the browser to execute the payload. The following use case demonstrates how DOM based XSS can be injected as a script to run on the client-side of the web app using the “img” or “embed” tag as the “src”.
A URL crafted with the intention of abusing this might look like this:
If this URL is copy/pasted on the “img” or “embed” tag as the “src”, it can render the following when the user takes action:
Because this affects users’ environments, this type of XSS vulnerability can be exploited to deface external and internal applications and alter valid data. In some cases, even if protocol is filtered in fields that accept URLs, the server might fail to block or sanitize out user-provided data that includes “img” and “embed” tags in other areas of the page. This can be avoided by filtering or encoding user data with tags and quotes.
Another tactic used to bypass a protocol restriction would be to include attributes that trigger based on various conditions. In this case, using the “onerror=alert(‘BREACHLOCK’)” within the tag and providing a non-URL value, like “x”, to execute the alert message. This can look like the following, which is also demonstrated below in an .xls file.
There are other tag attributes that can let the attacker control the next action when a DOM based XSS script executes. Other in-tag actions include “on load”, “on close”, “on click”, and “on zoom”.
Preventing DOM based XSS
Remediating DOM based XSS vectors requires a similar approach to the previous example with persistent XSS vulnerabilities. Any user provided data that includes tags needs to be encoded or treated like a string in the browser.
There are two reasons for encoding tags or treating them as a string in the browser:
- Encoding will change how the data is displayed and might still be able to be bypassed if a well-crafted payload uses the right encoding type and rules to create the HTML tags when the browser renders the page.
- Turning the data into a string makes the user experience smoother, as it does not confuse the user when their text that has a tag is encoded.
Best Practices for Remediating XSS with the Hyperlink Feature
We have highlighted how cross-site scripting can be present in applications and plausible security misconfigurations when filtering HTML tags provided by users in pages that host user-added links. Now, it is important to understand how these things can be tested for with one common feature – the hyperlink feature.
The DevOps checklist you should keep in mind to ensure that you are adding the link feature to your applications securely is as follows:
- Is my application strictly accepting “https” protocol URLs?
- Is my application rejecting user provided HTML tags as HTML tags?
- Are my authorization cookies protected with an “HttpOnly” flag set to “True”?
There are more things that you can consider depending on your application environment and how it interacts with external sources.
Identifying XSS Vulnerabilities in Test Environments
You can identify common XSS vulnerabilities in test environments or hire a third-party penetration testing vendor to help you identify vulnerabilities early before they are in production environments.
There are a few mechanisms that can be used to prevent XSS vulnerabilities. For example, most XSS vulnerabilities related to APIs can be filtered at the firewall level. Other applications use controls that ensure applications only allow references to paths with the same base URL.
Discovering Hidden XSS Vulnerabilities in Web App Pentesting
Taking time to test and identify XSS vulnerabilities early in development can help you address these types of XSS exploitation cases before the web app is in production.
When pentesting using Firefox, you can use this payload to hunt for XXS link vulnerabilities:
This type of payload for pentesting web apps for XSS works well for three reasons: it’s simple, it doesn’t require user interaction, and it bypasses filters looking for the infamous(specific to Firefox). Anyone can use this to test a web app. You don’t have to wait for the external penetration testing vendor to run this test yourself and remediate it per the instructions provided in this article. You can also get more help on more XSS remediation guidance in OWASP’s XSS (Cross Site Scripting) Prevention and DOM based XSS Prevention cheat sheets.
While no measure in security is fully guaranteed, penetration testing builds defense-in-depth security by helping ensure XSS vulnerabilities are remediated in external and internal web apps before XSS risks are pushed in production. By following this logic, you can prevent XSS vulns in test environments, remediate outdated web apps, and strengthen your web security posture by testing against the most common types of XSS attacks on your “add a link” feature.
For more prevention and remediation recommendations for XSS vulnerabilities, visit page 14 of our Annual Penetration Testing Intelligence Report.
Web App Penetration Testing for XSS Vulnerabilities
Pentesting your web application environment can reveal critical XSS vulnerabilities. With BreachLock’s team of in-house certified penetration testers, we work with you and your team to ensure that XSS vulnerabilities are remediated within the lifecycle of each web app pen test that BreachLock conducts.
With BreachLock’s full-stack Penetration Testing as a Service (PTaaS) solution, you can run pen tests for your digitally connected systems with confidence, including web applications. We leverage AI-driven automated scanning that includes verified evidence to reduce false positives, augmented by certified, in-house ethical hackers. Vulnerabilities like cross-site scripting are identified in initial findings, and remediation guidance is provided for you within the BreachLock Client Portal. Our clients can quickly and securely access benefits, such as free web vulnerability scanning, expert customer support for DevOps remediation, and audit-ready compliance reports, for 12 months from the start date of their pen testing engagement for comprehensive compliance and security validation.
Schedule a web application penetration testing discovery call today and accelerate your journey to cyber resilience.
About the Author:
Angel Cortez is a certified penetration tester working for BreachLock based in New York, NY. Angel has built expertise in penetration testing and security assessments, with a focus on application security, Python code, and SQL databases. Angel is currently in the top 1% of TryHackMe. Beyond cyber security, Angel is a certified personal trainer in the fitness industry and has worked with Olympic athletes on attacking niche pain points to improve in their sport. Angel now uses those same analytical techniques when researching and exploiting vulnerabilities.