BOOK THIS SPACE FOR ADARTICLE AD
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.
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.
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.
It’s pretty cool that after clicking on the text the XSS popup occurred.
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.