Drittanbieter-Skripte auf Ihrer Website: Jeder Tag ist ein Risiko

Oeffnen Sie Ihre Website jetzt und zaehlen Sie, wie viele externe Dienste sie laedt. Google Analytics. Google Tag Manager. Facebook Pixel. Ein Live-Chat-Widget. Google Fonts. jQuery von einem CDN. Ein Cookie-Consent-Banner. Ein YouTube-Embed. Ein Twitter-Feed. Ein Kundenbewertungs-Widget. Ein Heatmap-Tool wie Hotjar.

Die durchschnittliche Geschaeftswebsite laedt zwischen 15 und 30 Drittanbieter-Skripte. Einige E-Commerce-Websites laden 40 oder mehr. Jedes einzelne dieser Skripte laeuft mit vollem Zugriff auf Ihre Webseite. Sie koennen Formulareingaben lesen. Sie koennen die Seite modifizieren. Sie koennen Klicks abfangen. Sie koennen Besucher umleiten. Sie koennen Daten stehlen.

Wenn einer dieser Drittanbieter-Dienste kompromittiert wird, sind Ihre Besucher betroffen. Nicht weil Sie etwas falsch gemacht haben, sondern weil Sie dem Code eines anderen vertraut haben, auf Ihren Seiten zu laufen.

Das ist Supply-Chain-Risiko angewandt auf das Web, und es ist eine der am meisten unterschaetzten Sicherheitsbedrohungen fuer Unternehmen heute.

Was Drittanbieter-Skripte auf Ihrer Seite tun koennen

Wenn Sie ein Drittanbieter-Skript zu Ihrer Website hinzufuegen (ein <script>-Tag, das auf eine externe Domain zeigt), laeuft dieses Skript mit denselben Berechtigungen wie Ihr eigener Code. Es gibt keine Sandbox, keine Einschraenkung, keine Grenze. Es hat vollen Zugriff auf:

• Das gesamte DOM: Es kann jedes Element auf der Seite lesen und modifizieren.
• Formulardaten: Es kann alles lesen, was ein Benutzer in Formulare eingibt, einschliesslich Passwoerter und Kreditkartennummern.
• Cookies: Es kann Cookies lesen, die nicht als HttpOnly markiert sind.
• Local Storage und Session Storage: Es kann im lokalen Speicher des Browsers lesen und schreiben.
• Netzwerkanfragen: Es kann HTTP-Anfragen an jede Domain senden.
• Benutzerinteraktionen: Es kann Klicks, Scrollvorgaenge, Mausbewegungen und Tastenanschlaege verfolgen.

Das Supply-Chain-Problem

Supply-Chain-Angriffe auf Websites funktionieren so: Anstatt Ihre Website direkt anzugreifen, kompromittiert ein Angreifer einen der Drittanbieter-Dienste, von denen Ihre Website abhaengt. Wenn der kompromittierte Dienst sein modifiziertes Skript an Ihre Besucher liefert, laeuft der boesartige Code auf Ihren Seiten, als haetten Sie ihn selbst dort platziert.

Fuer einen tieferen Einblick in Supply-Chain-Angriffe im Kontext von CMS-Plugins lesen Sie unseren Artikel ueber Supply-Chain-Angriffe ueber Plugins.

Warum Supply-Chain-Angriffe effektiv sind

• Skalierung: Die Kompromittierung einer populaeren Drittanbieter-Bibliothek kann Tausende oder Millionen von Websites gleichzeitig betreffen.
• Vertrauen: Website-Betreiber vertrauen ihren Drittanbietern. Die Skripte laden automatisch bei jedem Seitenaufruf.
• Tarnung: Die boesartige Modifikation kann subtil sein und nur wenige Zeilen Code hinzufuegen, die nur auf Checkout-Seiten aktiviert werden.
• Persistenz: Solange Ihre Website das kompromittierte Skript laedt, geht der Angriff weiter.

Der British-Airways-Fall: Eine Lektion fuer 230 Millionen Dollar

Die Datenschutzverletzung bei British Airways 2018 ist eines der lehrreichsten Beispiele fuer einen Drittanbieter-Skript-Angriff. Die Angreifer injizierten ein boesartiges Skript von nur 22 Zeilen JavaScript, das speziell die Zahlungsseite der Fluggesellschaft ins Visier nahm.

Der Angriff lief etwa 15 Tage, bevor er erkannt wurde. In diesem Zeitraum wurden etwa 380.000 Zahlungskartendaten gestohlen. Die ICO des Vereinigten Koenigreichs verhoengte eine Geldstrafe von 20 Millionen Pfund Sterling unter der DSGVO.

Mehr ueber Angriffe auf Zahlungsseiten erfahren Sie in unserem Artikel ueber Web-Skimming im E-Commerce.

Gaengige Drittanbieter-Skripte auf Geschaeftswebsites

Analytics und Tracking

• Google Analytics / GA4: Auf fast jeder Geschaeftswebsite geladen. Verfolgt Seitenaufrufe, Benutzerverhalten, Konversionen.
• Google Tag Manager: Besonders maechtig. GTM ist im Wesentlichen eine Plattform zum Laden und Verwalten anderer Skripte. Jeder mit Zugang zu Ihrem GTM-Container kann beliebiges JavaScript auf Ihrer Website bereitstellen.
• Facebook/Meta Pixel: Verfolgt Benutzerverhalten fuer Werbezwecke.
• Hotjar, Crazy Egg, FullStory: Session-Recording- und Heatmap-Tools.

Funktionalitaet

• Live-Chat-Widgets: Intercom, Drift, Zendesk Chat. Laden erhebliches JavaScript.
• Kundenbewertungs-Widgets: Trustpilot, Google Reviews. Laden externen Inhalt auf Ihre Seite.
• Social-Media-Embeds: Twitter/X-Feeds, Instagram-Galerien, YouTube-Player.

Infrastruktur

• CDN-gehostete Bibliotheken: jQuery, Bootstrap von oeffentlichen CDNs wie cdnjs, jsDelivr oder unpkg.
• Web-Fonts: Google Fonts, Adobe Fonts laden Schriftdateien von externen Servern.
• Cookie-Consent-Plattformen: CookieBot, OneTrust, CookieYes.

Wie Sie Drittanbieter-Skripte auf Ihrer Website ueberpruefen

Methode 1: Browser-Entwicklerwerkzeuge

1. Oeffnen Sie Ihre Website in Chrome oder Firefox.
2. Oeffnen Sie die Entwicklerwerkzeuge (F12).
3. Gehen Sie zum Network-Tab.
4. Laden Sie die Seite neu.
5. Filtern Sie nach "JS", um JavaScript-Dateien zu sehen.
6. Schauen Sie die Spalte "Domain" an. Jede Domain, die nicht Ihre eigene ist, ist ein Drittanbieter-Skript.
7. Wiederholen Sie dies fuer Schluesselseiten: Startseite, Kontaktseite, Produktseiten, Checkout-Seite.

Methode 2: Content Security Policy Report-Only

Der gruendlichste Ansatz ist die Bereitstellung einer Content Security Policy im Report-Only-Modus. Dies weist Browser an, jede Ressource zu melden (aber nicht zu blockieren), die von einer Domain geladen wird, die nicht in Ihrer genehmigten Liste steht.

Subresource Integrity (SRI)

Subresource Integrity ist eine Browser-Sicherheitsfunktion, die es Ihnen ermoeglicht zu ueberpruefen, ob Skripte von externen Quellen nicht manipuliert wurden.

<script src="https://cdn.example.com/library.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8w"
  crossorigin="anonymous"></script>

Einschraenkungen von SRI

• Funktioniert nur fuer statische Dateien. Wenn das Drittanbieter-Skript sich haeufig aendert, wird der Hash nach jedem Update nicht mehr stimmen.
• Funktioniert nicht mit dynamisch generierten Skripten.
• Erfordert manuelle Updates.

Content Security Policy (CSP)

Eine Content Security Policy ist ein HTTP-Header, der dem Browser mitteilt, welche Quellen Ressourcen auf Ihrer Seite laden duerfen. Es ist die wirksamste Verteidigung gegen Drittanbieter-Skript-Angriffe.

Was CSP kontrolliert

• script-src: Welche Domains JavaScript bereitstellen duerfen.
• style-src: Welche Domains CSS bereitstellen duerfen.
• img-src: Welche Domains Bilder bereitstellen duerfen.
• font-src: Welche Domains Fonts bereitstellen duerfen.
• connect-src: Welche Domains AJAX/Fetch-Anfragen empfangen duerfen.
• frame-src: Welche Domains in Iframes eingebettet werden duerfen.

Selbst-Hosting kritischer Ressourcen

• Fonts: Statt Google Fonts von fonts.googleapis.com zu laden, laden Sie die Font-Dateien herunter und liefern Sie sie von Ihrer eigenen Domain.
• JavaScript-Bibliotheken: Binden Sie sie in Ihren Build-Prozess ein, anstatt sie von oeffentlichen CDNs zu laden.
• CSS-Frameworks: Wie JavaScript-Bibliotheken. Hosten Sie sie selbst.

Leistungsauswirkungen von Drittanbieter-Skripten

• DNS-Lookups: Jede externe Domain erfordert einen separaten DNS-Lookup.
• Verbindungs-Overhead: Jede externe Domain erfordert einen separaten TLS-Handshake.
• Render-Blockierung: Skripte im <head> blockieren das Seiten-Rendering.
• Hauptthread-Blockierung: JavaScript-Ausfuehrung findet auf dem Hauptthread des Browsers statt.
• Layout-Verschiebungen: Drittanbieter-Inhalte, die nach dem initialen Rendering laden, koennen Layout-Verschiebungen verursachen.

Datenschutzimplikationen unter der DSGVO

• Einwilligung: Unter der DSGVO benoetigen Sie informierte Einwilligung, bevor Sie Tracking-Skripte laden.
• Auftragsverarbeitungsvertraege: Sie brauchen einen AVV mit jedem Drittanbieter, dessen Skript personenbezogene Daten verarbeitet.
• Datenschutzerklaerung: Ihre Datenschutzerklaerung muss jeden Drittanbieter-Dienst auflisten, der Daten ueber Ihre Website sammelt.
• Grenzueberschreitende Uebermittlungen: Wenn ein Drittanbieter-Skript Daten an Server ausserhalb der EU/des EWR sendet, benoetigen Sie angemessene Garantien.

Ein praktischer Aktionsplan

1. Audit und Inventar: Erstellen Sie eine vollstaendige Liste aller Drittanbieter-Skripte auf Ihrer Website.
2. Entfernen Sie, was Sie nicht brauchen: Weniger Skripte bedeutet weniger Risiken, bessere Leistung und einfachere Compliance.
3. Selbst hosten, wo moeglich: Verschieben Sie Fonts, JavaScript-Bibliotheken, CSS-Frameworks auf Ihr eigenes Hosting.
4. Implementieren Sie SRI fuer statische Ressourcen.
5. Stellen Sie eine Content Security Policy bereit.
6. Verwenden Sie Tag Manager vorsichtig: Beschraenken Sie den Zugang zum GTM-Container. Aktivieren Sie Zwei-Faktor-Authentifizierung.
7. Ueberwachen: Richten Sie Monitoring ein, um Aenderungen an den auf Ihrer Website geladenen Drittanbieter-Skripten zu erkennen.

Naechste Schritte

Wenn Sie sich um die Drittanbieter-Skripte auf Ihrer Website Sorgen machen (und nach dem Lesen dieses Artikels sollten Sie das), koennen wir helfen. Bei Envestis fuehren wir Website-Sicherheitsbewertungen durch, die ein gruendliches Audit der Drittanbieter-Skripte, ihrer Sicherheitsimplikationen, ihrer Leistungsauswirkungen und ihres Compliance-Status umfassen.

Kontaktieren Sie uns fuer eine Bewertung. Wir geben Ihnen ein klares Bild Ihrer Drittanbieter-Exposition und einen praktischen Plan, um sie zu reduzieren.