SkypeDestroyer: Anatomy of a Client-Side HTML Injection Exploit
Hook
In 2017, you could send messages on Skype Web that rendered in 72-point font or disguised links as legitimate URLs—all through a userscript that exploited how Microsoft sanitized user input. The vulnerability isn’t just academic; it’s a masterclass in why client-side validation alone fails.
Context
Before Microsoft Teams cannibalized its feature set, Skype Web was the go-to browser-based messaging client for millions of users. Like most web applications handling user-generated content, it faced a fundamental security challenge: how to allow rich text formatting while preventing malicious HTML injection. The typical solution involves sanitizing user input—stripping out dangerous tags, escaping HTML entities, and rendering everything safely in the DOM.
SkypeDestroyer emerged as a proof-of-concept demonstrating that Skype Web’s sanitization wasn’t happening where developers assumed it was. By intercepting messages client-side before they hit Skype’s validation layer, this TamperMonkey script could inject arbitrary HTML that would render in the sender’s view—and potentially in recipients’ clients if their sanitization also failed. While the repository is now archived and the exploits no longer work on modern Skype, the techniques it employed remain relevant for understanding DOM manipulation vulnerabilities and why defense-in-depth matters in web security.
Technical Insight
SkypeDestroyer operates at the intersection of userscript injection and DOM event interception. When you install it via TamperMonkey or GreaseMonkey, it loads on web.skype.com and immediately starts monitoring the message composition textarea. The architecture is deceptively simple: watch for specific command prefixes, transform the message content using regex, and inject the modified HTML before Skype’s own JavaScript processes it.
The core mechanism relies on a custom domain-specific language using inline commands. Prefixing a message with ’#’ triggers font size manipulation, ’!’ creates link spoofing, and ’##’ enables custom HTML injection. Here’s the essential pattern from the original implementation:
// Intercept the message input area
var messageBox = document.querySelector('[contenteditable="true"]');
// Monitor for Enter key (message send)
messageBox.addEventListener('keydown', function(e) {
if (e.keyCode === 13 && !e.shiftKey) {
var content = messageBox.textContent;
// Font size exploit: #72 Hello World
if (content.startsWith('#')) {
var match = content.match(/^#(\d+)\s+(.*)/);
if (match) {
var size = match[1];
var text = match[2];
messageBox.innerHTML = `<font size="${size}">${text}</font>`;
e.preventDefault();
}
}
// Link spoofing: !https://evil.com|https://google.com
if (content.startsWith('!')) {
var match = content.match(/^!(.*)\|(.*)/);
if (match) {
var realUrl = match[1];
var displayUrl = match[2];
messageBox.innerHTML = `<a href="${realUrl}">${displayUrl}</a>`;
e.preventDefault();
}
}
}
});The vulnerability SkypeDestroyer exploited wasn’t that Skype lacked sanitization—it was that sanitization happened after the client-side DOM manipulation. By modifying the innerHTML directly in the contenteditable div before the message send event fully propagated, the script could bypass the initial validation layer. Skype’s backend would receive whatever HTML the browser sent, and if the rendering client didn’t properly escape that HTML, arbitrary markup would display.
This attack surface exists because modern web applications often implement rich text editing through contenteditable elements, which are notoriously difficult to secure. Unlike traditional form inputs, contenteditable divs maintain their own DOM structure, and manipulating that structure programmatically can introduce HTML that the application doesn’t expect. Skype’s developers likely assumed users would type plaintext or use the built-in formatting toolbar, not that a userscript would inject raw HTML tags.
The regex-based command parsing is particularly interesting from a design perspective. Rather than building a complex UI for exploits, SkypeDestroyer used inline commands that feel natural to power users familiar with IRC or Markdown. A message like #96 STOP YELLING AT ME would render in massive font, while !https://malicious.site|https://microsoft.com would display what appeared to be a Microsoft URL but actually linked to an attacker-controlled domain. This DSL approach made the exploit accessible without requiring users to understand HTML or JavaScript—they just needed to remember a few command prefixes.
From a technical architecture standpoint, userscripts like this demonstrate the fragility of client-side security boundaries. TamperMonkey operates with full DOM access in the page context, meaning it can read, modify, or intercept anything the legitimate application does. It’s essentially a man-in-the-middle attack against your own browser session. The only defense is server-side validation that doesn’t trust anything from the client—a principle that Skype Web apparently violated in its earlier iterations.
Gotcha
The most significant limitation is that SkypeDestroyer is now entirely non-functional. The repository has been archived since 2017, and Skype Web has undergone multiple security overhauls. Modern versions implement proper server-side sanitization, reject messages with suspicious HTML patterns, and use Content Security Policy headers to prevent inline script execution. If you clone this repo expecting to send giant text messages or spoof links, you’ll be disappointed—Microsoft patched these vulnerabilities years ago.
Even at its peak, the exploit had limited scope. It only affected the sender’s view of messages and required that recipients’ clients also failed to sanitize incoming HTML properly. Many Skype clients implemented their own rendering engines with proper escaping, so the malicious HTML would simply appear as plaintext or get stripped entirely. The exploit also required manual installation as a userscript, meaning it was never a widespread security threat—more a demonstration of poor input validation than a functional attack tool. For security researchers today, it’s a historical artifact showing how not to handle user content, but it won’t teach you about modern XSS techniques or advanced exploitation patterns.
Verdict
Use if: You’re studying web application security fundamentals and want a clear, uncomplicated example of client-side HTML injection vulnerabilities. This is excellent for teaching developers why sanitization must happen server-side and why contenteditable elements require careful handling. Security researchers building training materials or presentation demos about DOM manipulation will find the straightforward code easy to explain. It’s also valuable if you’re auditing legacy web applications that might still implement similar vulnerable patterns—understanding this exploit helps you recognize the warning signs. Skip if: You need functional Skype modifications (the script is outdated and broken), you’re looking for advanced exploitation techniques (this is entry-level proof-of-concept work), or you want production-ready security testing tools (use Burp Suite, OWASP ZAP, or BeEF instead). Modern penetration testers will find little practical value here beyond historical context, and developers seeking actual userscript functionality should explore current browser extension APIs rather than this archived relic.
