CVE-2021-1825: Inadequate Input Encoding in WebKit

October 25, 2021 10 mins

CVE-2021-1825: Inadequate Input Encoding in WebKit

In August 2020, Aon discovered and reported to Apple an issue relating to the encoding of Uniform Resource Locator (URL) characters in the Safari web browser, making it easier for an attacker to perform Cross-Site Scripting (XSS) attacks.

In August 2020, Aon discovered and reported to Apple an issue relating to the encoding of Uniform Resource Locator (URL) characters in the Safari web browser, making it easier for an attacker to perform Cross-Site Scripting (XSS) attacks. Following further investigation, this vulnerability appeared to be a wider WebKit issue, and was found to be present in macOS, iOS, iPadOS, the GNOME Web browser, and other WebKit-based applications. The vulnerability was discovered by Alex Camboe and assigned CVE-2021-1825. As of April 2021, the vulnerability was patched with the releases of macOS 11.3, Safari 14.1, iOS 14.5, tvOS 14.5, watchOS 7.4, iTunes 12.11.3, iCloud for Windows 12.3, and as of July 2021 with the releases of WPE WebKit 2.30.0 and WebKitGTK 2.30.0. We would like to thank Apple for working with us as part of our coordinated disclosure process.

This post will give an overview of the issue and detail possible attack scenarios where this vulnerability can be exploited by an attacker. We consider this issue to be of overall low severity as the encoding of URL entities is a side-effect of the browser ensuring that URLs are standards-compliant and is not and should not be treated as a security feature. However, if the encoding of entities is inconsistent across browsers it may produce a blind spot to developers when ensuring their web applications are not vulnerable to XSS attacks.

Background

Consider the following two statements:

A successful XSS attack relies on the injection of arbitrary HTML into a web application.
All characters contained in URLs must be percent-encoded if outside the allowed set.

Depending on the context of the injection, an attacker attempting an XSS attack will commonly try and enter arbitrary HTML elements using angle brackets or break out from HTML attributes by using double quotes. Appropriately encoding these characters will help reduce the likelihood of a successful attack.

It should be noted that just encoding these three characters will not prevent all attacks as there are many other avenues to XSS such as injection into unquoted attributes, event handlers or dynamically generated JavaScript. In addition, single quotes (which are not percent-encoded as they are a reserved delimiter character) can also be used to break out from HTML attributes in some scenarios.

To ensure a URL remains valid, browsers typically automatically encode any characters outside of a defined set when a user navigates to a URL containing these characters (or a string is processed by JavaScript in the browser). As all three of the characters described above are outside the set of allowed characters to produce a valid URL the browser may encode as follows:

< : %3C
> : %3E
” : %22

The screenshot appearing below shows that even if the URL (or “document.location.href”) is explicitly set to contain these characters, Google Chrome will silently encode them. Note the address bar is updated so it appears to contain these characters, but when re-accessed in JavaScript (or a user copy and pastes the URL from the address bar) the characters are encoded.

CVE-2021-1825: Inadequate Input Encoding in WebKit Image 1

Modern web applications commonly make use of fragments (or URL anchor, following the “#” character), queries (following the “?” character) or even URL paths to generate content using client-side JavaScript code. For example, a search term may be rendered back to the page or values in an HTML form pre-filled for convenience. A developer may access these values by using the JavaScript Web API:

location.href = 'https://aon.com/path?query=value#fragment'
location.search = '?query=value'
location.hash = '#fragment'
location.pathname = '/path'

Some developers may deliberately or inadvertently rely on the browser to automatically encode the noted potentially dangerous characters (i.e. <, >, and “) when using client-side JavaScript to generate page content. This is generally considered to be inadvisable because, as previously noted, there are other avenues to attack which will not be mitigated by encoding these characters.

Nevertheless, the default URL encoding behavior of modern browsers has the side-effect of providing a marginal security benefit, which may protect users from client-side attack.

Building — Support

Contact our cyber response teams for urgent breach assistance.

Contact Us

Overview

WebKit applications such as the Safari web browser fail to percent-encode the characters <, >, and ” contained in URL fragments. The following example shows a vulnerable web page hosted on a local server named “vulnerable.local”:

<html>
    <body>
        <script>
            document.write(`<div>
            <p>Full URL: ${location.href}</p>
            <p>URL Query: ${location.search}</p>
            <p>URL Fragment: ${location.hash}</p>
            <p>URL Path: ${location.pathname}</p>
            </div>`);
        </script>
    </body>
</html>

The URL “http://vulnerable.local/?query=<aon””>#<aon””>” was then visited in Safari 14.0.3 running in macOS 10.15.7:

CVE-2021-1825: Inadequate Input Encoding in WebKit Image 2

Note that the angle brackets and double quotes contained in the URL are percent-encoded in the query string, but not in the fragment. The browser treats as an HTML element and therefore does not render it as text on the page.

Upon further investigation, the Safari web browser on macOS, iOS, iPadOS and the WebKit-based GNOME Web browser were all found to not encode the <, >, and ” characters, causing them to be susceptible to the attack scenarios described below.

An attacker can leverage this behavior to inject HTML and JavaScript code into an application which renders content from a URL fragment without adequate input sanitization. WebKit has a built-in “XSS auditor” which may mitigate some XSS attacks, and in this case will indeed prevent an attacker from compromising a user by entering a simple script in the URL fragment.

The same HTML page as before was visited via the following URL: “http://vulnerable.local/#<script>alert(document.domain)</script>”.

CVE-2021-1825: Inadequate Input Encoding in WebKit Image 3

Note that the JavaScript code injected into the fragment did not execute when the “X-XSS-Protection” HTTP header was not set by the test web server, showing that Safari defaults the XSS auditor to enabled.

In recent years, the use of built-in browser XSS auditors has become a controversial topic. An auditor was never implemented in the Gecko browser engine (used in Firefox) and has now been removed in recent versions of Blink (Google Chrome). In some cases, the presence of an XSS auditor was found to introduce additional security issues. Therefore, many of the most popular websites (such as sites run by Google, Facebook, and Twitter) now explicitly disable XSS auditors by setting “X-XSS-Protection: 0” in server responses.

As a result, the likelihood of Safari’s XSS auditor being disabled is increased and the risk of an attacker being able to execute arbitrary JavaScript in the context of the application remains. This is demonstrated in the first scenario described in our Reproduction Steps provided in the next section below.

Additionally, the XSS auditor does not catch all cases and several bypasses have been identified. A technique demonstrating this is detailed in the second scenario of the Reproduction Steps provided.

Reproduction Steps

Scenario 1

This first scenario shows an attacker executing JavaScript code in a vulnerable application that disables the XSS auditor via the “X-XSS-Protection” HTTP response header.

Environment:

A web application which renders content from the URL fragment to the web page and sets “X-XSS-Protection: 0” in server responses.

URL containing an example payload:

http://vulnerable.local/s1.php#<script>alert("Code_execution_in:"+document.domain);</script>

Minimal vulnerable webpage “s1.php” example:

<?php
    header('X-XSS-Protection: 0')
?>
<html>
    <body>
        <script>
            document.write(`<p>URL Fragment: ${location.hash} </p>`);
        </script>
    </body>
</html>

When the example URL is visited in a vulnerable web browser, the script is executed in the context of the vulnerable application:

CVE-2021-1825: Inadequate Input Encoding in WebKit Image 4

Explore More

Capability Overview

Cyber Resilience
Product / Service

Penetration Testing Services

Scenario 2

In this second scenario, an attacker bypasses the Safari XSS auditor by injecting a script tag, which loads a script from a relative URL (absolute URLs will trigger the filter). This exploit has the prerequisite that an attacker has previously uploaded the malicious script and it is hosted on the same domain as the vulnerable page.

Environment:

A website application which renders content from the URL fragment to the web page and allows users to upload content to the same domain.

URL containing an example payload:

http://vulnerable.local/s2.php#<script/src="local.js"></script>

Uploaded file “/local.js” containing:

alert("A script was loaded from the same domain.");

Minimal vulnerable webpage “s2.php” example:

<html>
    <body>
        <script>
            document.write(`<p>URL Fragment: ${location.hash} </p>`);
        </script>
    </body>
</html>

When the victim visits the target URL in a vulnerable web browser the script is loaded and executed:

CVE-2021-1825: Inadequate Input Encoding in WebKit Image 5

Remediation

It is expected that all modern browsers follow the standard defined in RFC3986 and encode all characters contained in the URL if outside the allowed set. Although not recommended, some web developers may deliberately or inadvertently rely on this encoding to mitigate the likelihood of successful XSS attacks.

This issue has now been remediated in WebKit and applications that depend on it, including Safari 14.1 and GNOME Web 40.0. Both browsers now percent-encode the noted dangerous characters (<, >, and “) in the URL fragment.

Author

Alex Camboe

Security Testing, Cyber Solutions

Aon’s Cyber Solutions offers holistic cyber risk management, unsurpassed investigative skills, and proprietary technologies to help clients uncover and quantify cyber risks, protect critical assets, and recover from cyber incidents.

This material has been prepared for informational purposes only and should not be relied on for any other purpose. You should consult with your own professional advisors or technologists before implementing any recommendation or following the guidance provided herein. The companies referenced in this article and/or links provided have no affiliation with our firm and we do not represent any opinions or support any studies by these third party sources. Further, the information provided and the statements expressed are not intended to address the circumstances of any particular individual or entity. Although we endeavor to provide accurate and timely information and use sources that we consider reliable, there can be no guarantee that such information is accurate as of the date it is received or that it will continue to be accurate in the future.

The contents herein may not be reproduced, reused, reprinted or redistributed without the expressed written consent of Aon, unless otherwise authorized by Aon. To use information contained herein, please write to our team.