A Synack Red Team member discovered a DOM-based XSS vulnerability that was patched… and then found in another product from the same company a year later. In this edition of Exploits Explained, SRT member “nerrorsec” recounts the tale of this recurring flaw.
I discovered a DOM-based cross-site scripting (XSS) vulnerability in a client’s application. A year later, I stumbled upon the exact same flaw on a different asset belonging to the same client. This experience emphasizes an important lesson: vulnerabilities, if not properly understood and addressed at their root, have a way of resurfacing in unexpected places.
The Initial Discovery
It all started during an assessment of a client’s web application. While testing the login functionality, I noticed an interesting behavior involving the “routeAfter” parameter. After authentication, the application would redirect users based on the value provided in this parameter.
A quick analysis of the code revealed the following logic:
if (K.parameters.routeAndExecute) {
W.controller.mRouteAndExecute(K.parameters.routeAfter)
} else {
window.location = K.parameters.routeAfter
}
Here, in the else block, “window.location” was being set directly to the user-controlled “routeAfter” parameter without any validation or sanitization. This meant an attacker could inject a malicious JavaScript payload and have it executed within the victim’s browser.
Exploiting the Vulnerability
By default, the login page was a popup form, making the attack non-trivial. However, after a bit of tinkering, I discovered that it was possible to load the login form as a standalone page. With that, I could easily test my payload:
https://client-app.com/login?routeAfter=javascript:alert(document.cookie)
Just like that, a harmless alert popped up, confirming the vulnerability. This could have been weaponized for session theft, phishing or other malicious activities.
A Year Later
Fast forward a year, and I was back testing another application belonging to the same client. It was a different asset and a different functionality, but as I sifted through the JavaScript files, I had a strong sense of familiarity.
Sure enough, the same pattern emerged. Another redirect function and another case of window.location being set without validation. I used the same payload and executed it, and just like before, I was greeted with an alert box.
Takeaways
Finding the same vulnerability twice in different assets of the same company raised a crucial question: Why did it happen again?
1. Reused Code Means Reused Vulnerabilities
Many organizations reuse scripts, libraries or even entire codebases across different projects. This can be efficient but also means that vulnerabilities get copied and pasted along with the functionality.
2. Patching Symptoms vs. Addressing Root Causes
When security teams fix a reported vulnerability, the focus is often on patching the specific instance of that vuln rather than understanding how it originated. In this case, a fix was applied to the first application, but the underlying issue, an insecure redirect pattern, was never addressed at a broader level.
3. Security Requires Holistic Thinking
A single vulnerability can persist across multiple assets if developers aren’t aware of its risks. Proper security reviews, training and proactive scanning for known patterns can help prevent these mistakes from recurring.
So, next time you patch a bug, ask yourself: Did I fix the problem, or just this instance of it?
Be sure to follow Synack and the Synack Red Team on LinkedIn for later additions to this series.
