December 14, 2022

How to Fix XSS Vulnerabilities on Web App Links

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.

1. If you hover your mouse over your browser and right click, you will see the “Inspect” code option. It will look something like this:
2. Clicking “Inspect” will show you the HTML code for that webpage.
3. 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.

However, other protocols like ftp, http, file, data, and JavaScript can be used by pages to render different actions. Let’s consider how these protocols can be abused by hackers if they know their data will end up inside of one of these tags. For example, an attacker can use the “javascript” protocol instead of the expected “https” protocol to craft a payload so that when the HTML tag calls the “src,” the injected script will execute automatically.

Here are a few examples of how JavaScript can be injected into HTML to execute an XSS payload.

For the “img” and “embed” tags shown in Example 1 and 2 below, the JavaScript will launch an alert message as soon as the HTML renders on the page.

Example 1 references the environment’s document variables to render any cookies reachable with Javascript. This payload can be used on Firefox.<.p>

XSS Example 1:

In Example 2 below, the “a” tag has JavaScript that will execute when a user clicks the link. This is an example of how “a” tags are used to create clickable links in HTML, as previously discussed.

XSS Example 2:

In the example screenshots below, you can see how hovering over the word “breachlock” reveals the address to be redirected to the Breachlock website. However, when you hover over “Click Me”, you’ll see the JavaScript alert function revealed, as shown below.

The user that clicks the link that hosts the JavaScript function will trigger the following alert message for the user.

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

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:

1. 1. Share authentication + IP
   2. Download a malicious external file
   3. 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.

Another use case has to do with web cookies. Many applications still use cookies to validate a session’s authenticity. If cookies have their “HttpOnly” flag set to “false”, then the server will give the application permission to call the cookie in a JavaScript function. Taking the previous scenario into consideration again, an attacker can create a payload that shares the admin’s cookies with a resource they monitor. This type of XSS attack, while more advanced, can be used to facilitate an entire account takeover.

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:

1. 1. • 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:

Since the application accepted and validated the tags provided by the user when they submitted their favorite URL, we can see our JavaScript in the script tag save on the browser. This ensures that every time the webpage is refreshed, this alert message pops up for the user. Here, the crafted payload closed the intended “img” tag and injected its own script tag with the alert message “Howdy”.

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.

Then, the payload instructs that if there is an error rendering the image, then execute the JavaScript alert function that displays the message ‘BREACHLOCK’ (shown below).

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:

1. 1. • 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:

1. 1. • 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.

Meanwhile, an attacker can bypass weak controls and still execute an XSS attack. In the above scenario, where a web app only allows references to paths with the same base URL, users will not have the option to attempt another protocol. However, attackers can bypass this control if they upload a file with JavaScript and use that as the “src” or “href” to get XSS.

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.