XSS Unleashed: Bypassing Filters with XLink Namespace

Greetings, wonderful readers!

I trust you’re all happily hacking away in your digital endeavors. My sincerest apologies for my extended absence from the blogosphere — it seems I took an unintended detour. But fear not, for I have returned with a delightful treat: an exhilarating XSS adventure complete with a nifty filter bypass. Now, before we embark on this thrilling journey, I’ll spare you the mundane details of what XSS is, assuming you’ve already mastered its mischievous ways.

Without further ado, let’s inject some formality and a pinch of humor into our introduction for this whimsical blog post.

During my recent web application testing, I came across an interesting feature that allows users to edit email templates. What’s even better is that you can preview the templates before finalizing them.

I swiftly injected a basic XSS payload — <img src=x onerror="alert('document.domain')"/>. To my dismay, instead of being treated to an entertaining XSS popup, I was met with a pitiful display of a fractured image just like my hope.

The Broken Hope!

The payload leverages the onerror attribute, a handy JavaScript event handler for handling image loading failures. In this case, the alert('document.domain') snippet attempts to execute a benign alert box, showcasing the document.domain value. However, it seems our intended exploit has been thwarted by the web application's vigilant defenses. But fret not, fellow hackers, for there are always tricks up our sleeves to overcome such obstacles!

After this unsuccessful attempt, I endeavored to comprehend and debug the behavior of the application to discern why it staunchly thwarted the execution of XSS. I activated the browser’s developer tools and meticulously examined the available reflections within the source code.

My inserted XSS payload was getting converted into the following code :(

The reason is that the application utilized CKEditor, which performed sanitization on my malicious XSS content.

Upon analyzing the transformation, a few notable changes become evident. Firstly, the onerror attribute has been modified and replaced with data-cke-pa-onerror, which suggests that the application is likely utilizing a customized attribute to handle events securely. Additionally, the src attribute has been duplicated with data-cke-saved-src, indicating that the application may be storing and using the original source value for internal purposes while assigning a sanitized value to the src attribute.

These alterations indicate that the web application is actively sanitizing user inputs to prevent the execution of potentially malicious code.

Okay!! Interestingly, I attempted to insert another payload into the application, specifically <svg/onload =alert(document.domain)>. However, once again, the application swiftly intercepted my endeavor and converted the input into sanitized code.

Before we embark on our filter-bypassing adventure, let’s take a moment to grasp the essence of this payload. Trust me, understanding the basics will make the bypass journey a breeze for both of us.

The code <svg/onload =alert(document.domain)> represents an SVG payload intended to trigger an alert dialogue displaying the value of document.domain.

Let’s break it down:

<svg>: This is the opening tag of the SVG element, which is used to define scalable vector graphics./onload: This attribute specifies an event handler that is triggered when the SVG image finishes loading.=alert(document.domain): Here, the alert() function is invoked, displaying the value of document.domain within the alert box.

In my continued quest, I endeavored to insert another basic payload: <a href="javascript:alert(1)">XSS</a>. This payload exploits the standard JavaScript protocol by executing the alert(1) function upon clicking the link. My aim was to investigate which elements of this payload were being blocked by the application's security measures.

They are again sanitizing the malicious href value.

I was thinking that what should be the alternative of href? While pondering on potential alternatives to the href attribute, I conducted a bit of research and stumbled upon an intriguing option: the xlink:href attribute within the xlink namespace. However, there was a caveat—I discovered that the tag utilizing the xlink:href namespace should be nested within the <svg> tag. This finding opened up a fascinating possibility for my quest to bypass filters and explore new avenues of XSS exploitation.

Swiftly, I concocted a clever payload utilizing the xlink namespace: <svg><a xlink:href="javascript:alert(origin)"><text x="40" y="40">Click Here</text></a>. This artful creation was promptly saved into the email template, ready to be unleashed and tested against the application's defenses, and voila!

Adorable Popup

It’s pretty cool that after clicking on the text the XSS popup occurred.

Let’s unravel the magic behind the code <svg><a xlink:href="javascript:alert(origin)"><text x="40" y="40">Click Here</text></a>:

<svg>: This is the opening tag of the SVG element, which is used to define scalable vector graphics.<a xlink:href="javascript:alert(origin)">: This is an anchor (<a>) element that utilizes the xlink:href attribute within the xlink namespace. The xlink:href attribute is set to execute the JavaScript code alert(origin). When clicked, this code triggers an alert dialog displaying the origin of the current webpage.<text x="40" y="40">Click Here</text>: This is a text element within the SVG, positioned at coordinates (40, 40), displaying the text "Click Here". It serves as the clickable text for the anchor element.

Overall, this code creates an interactive SVG element that, when clicked, executes the JavaScript code alert(origin), showcasing the origin of the webpage.

Thank you for taking the time to engage with this blog post. I sincerely hope that you found it both enjoyable and educational, gaining valuable insights along the way.

Bye!