Wichtige Informationen (und potenzielle Gefahren) bei Skripten von Drittanbietern

Das Web ist voll von Skripten Dritter. Websites nutzen sie für Werbung, Analysen, Retargeting und mehr. Aber das ist nicht immer die ganze Geschichte. Skripte können Ihr Verhalten, Ihre Vorlieben und andere Informationen verfolgen.

Hier werden wir uns die potenziellen Risiken dieser Skripte von Drittanbietern ansehen.

Ein Skript von Drittanbietern kann ein Datenschutzbedenken darstellen

Skripte von Drittanbietern können Daten zurückmelden, von denen Sie nichts wussten.

Die Dokumentation von Google, Facebook und Wikipedia besagt direkt, dass diese Skripte Verhalten, besuchte Seiten, Kaufhistorie, Demografie, IP-Adresse, Standort und mehr verfolgen können. Dieser Teil ist allgemein bekannt.

Einige der Daten, die Facebook laut seiner Dokumentation verfolgen kann.

Während das standardmäßige Tracking von Drittanbietern generell dokumentiert ist, kann es auch Tracking geben, von dem wir nichts wissen.

Zum Beispiel, laut einer Studie von Forschern an den Universitäten Princeton und Stanford, geben 42 % der Top-Websites (Alexa Top 50 U.S.) eindeutige Identifikatoren im Klartext preis. Das bedeutet, dass Lauscher Dinge wie Ihre E-Mail-Adresse, Ihren Benutzernamen, Ihren vollständigen Namen, Ihre Wohnadresse, Käufe, Ihren Standort, Ihre Historie, Ihre IP-Adresse und Ihre Präferenzen verfolgen können. Allein durch das Herumklicken im Web können Sie unwissentlich zulassen, dass jemand ein umfangreiches Profil von Informationen über Sie aufbaut. Tatsächlich besprach dieselbe Studie, wie die NSA einige Skripte von Google nutzte, um Menschen zu verfolgen.

Hier ist ein Screenshot eines offiziellen Implementierungsleitfadens eines Werbetreibenden, der Personen ausdrücklich Code zur Übertragung von E-Mail-Adressen an sie als unverschlüsselten Klartext zur Verfügung stellt. Sie verschlüsseln jede Adresse nach dem Empfang, aber sie wird immer noch als Klartext gesendet, sodass der Schaden bereits angerichtet ist.

Implementierungsleitfaden, der das Senden von E-Mails im Klartext ermöglicht.

Ein Skript von Drittanbietern kann ein Sicherheitsrisiko darstellen

Jedes Mal, wenn Sie ein externes Skript von jemand anderem auf Ihrer Seite einbinden, besteht ein inhärentes Sicherheitsrisiko, da dieses Skript vollen Zugriff auf das Frontend Ihrer Website hat.

Hier sind einige Beispiele dafür, was diese Skripte getan haben.

Preisinformationen werden durch nicht bereinigte Daten weitergegeben

Der Sicherheitsexperte Randy Westergren hat entdeckt, dass viele große Tracking-Skripte Daten nicht richtig bereinigen (dank meines Kollegen Sam Ratcliffe, der mich auf diesen Artikel aufmerksam gemacht hat). Dies ermöglicht es Angreifern, beliebigen Code einzuschleusen, einschließlich Code, der Kreditkartennummern stehlen kann.

Hier ist ein Screenshot von bösartigem Code, der in eine nicht bereinigte URL eingeschleust wird.

Ein Angreifer hätte beliebigen Code einfügen können.

Was den obigen Screenshot besonders knifflig machte, war, dass die Schwachstelle nicht tatsächlich aus dem Skript selbst stammte. Stattdessen stammte sie von der unsicheren Implementierung eines anderen Skripts von Drittanbietern für ein weiteres Skript von Drittanbietern.

Ich habe einen Test auf einer betroffenen Website durchgeführt, um diese Schwachstelle selbst zu sehen (keine Sorge, ich habe keine echte Kartennummer verwendet), und es erwies sich als einfach, sensible Informationen zu extrahieren.

Viele der Werbetreibenden haben die Schwachstelle inzwischen behoben, aber das wirft die Frage auf, welche anderen Exploits noch existieren.

Weitergabe privater Daten durch Nicht-HTTPS-Skripte

Viele Tracking-Skripte im Umlauf verwenden reguläres, unsicheres HTTP. Dies kann Angreifern den Zugriff auf die Informationen von Personen ermöglichen und Sicherheitshinweise verursachen, die Benutzer auf sicheren Seiten abschrecken können.

Hier ist ein Beispiel für einen Implementierungsleitfaden, der HTTP auf einer sicheren Warenkorbseite verwendet.

Code kann sich ändern, ohne dass Sie es wissen

Bei Skripten von Drittanbietern besteht immer die Gefahr, dass sich der Code ändern oder verschwinden kann, ohne dass Sie es wissen.

Mein Kollege Brent Kimmel erzählte mir von einer Technik namens Subresource Integrity, die es Ihnen im Wesentlichen ermöglicht, sicherzustellen, dass Sie das bekommen, was Sie erwarten. Zum Zeitpunkt der Veröffentlichung hat sie noch keine vollständige Browserunterstützung, aber behalten Sie sie im Auge.

Beachten Sie auch, dass diese Technik am besten funktioniert, wenn das ursprüngliche Skript von Drittanbietern nicht bereits fehlerhaft ist.

Skripte von Drittanbietern laden oft eigene Skripte von Drittanbietern

Wenn die Skripte von Drittanbietern, denen Sie vertrauen, Skripte einbinden, die Sie nicht erwarten, vervielfacht dies das Potenzial für alle bisher genannten Sicherheits- und Datenschutzrisiken.

Hier ist ein Beispiel für ein Skript von Drittanbietern, das andere Skripte lädt.

Es ist immer eine Party, wenn Skripte ihre Freunde mitbringen.

Ein Skript von Drittanbietern kann ein Leistungsproblem darstellen

Langsamere Seitenaufrufe

Skripte von Drittanbietern führen häufig dazu, dass Seiten langsamer geladen werden. So lädt die tatsächliche Website von Business Insider in etwa 1 Sekunde, während Skripte von Drittanbietern den Großteil der Ladezeit von 7 bis 15 Sekunden ausmachen. Der folgende Screenshot zeigt das Ende einer langen Reihe von Hunderten von Skripten von Drittanbietern.

Zu ihrer Ehre lädt Business Insider die meisten ihrer Skripte von Drittanbietern asynchron, sodass die wahrgenommene Ladezeit nicht annähernd 7 bis 15 Sekunden beträgt.

Was passiert, wenn Skripte von Drittanbietern das Laden nicht asynchron zulassen?

Manche Skripte lassen sich nicht asynchron laden

Wenn ein Skript document.write verwendet, verhindert dies, dass es asynchron geladen wird. Viele gängige Skripte von Drittanbietern verwenden document.write, blockieren also das Dokument und verlängern die Ladezeiten unnötigerweise.

Hier ist ein Beispiel:

Manche Skripte beeinträchtigen die Scroll-Performance

Skripte von Drittanbietern führen oft Operationen für das Scroll-Ereignis durch. Hier ist ein Screenshot eines Skripts, das bei jedem Scrollen eine Schleife ausführt.

Obwohl dieses Beispiel allein eine Website nicht zum Absturz bringt, kann es zu einer spürbaren Verlangsamung beitragen, wenn mehrere Skripte das Scroll-Ereignis belasten.

Ein Skript von Drittanbietern kann unbeabsichtigte Folgen haben

Skripte von Drittanbietern können alle möglichen unerwarteten Dinge mit Ihren Seiten tun. Hier sind ein paar.

Überschreiben Ihrer Variablen

Einige der am weitesten verbreiteten Skripte von Drittanbietern im Web verwenden unnötige globale Variablen, die die Variablen auf Ihrer Seite überschreiben können.

Der folgende Screenshot zeigt ein Skript, das zwei globale Variablen zur Erzeugung einer Zufallszahl verwendet (und dabei sogar eine unnötige Typkonvertierung vornimmt).

Durch die Verwendung von eval unnötige Risiken schaffen

Da eval alles ausführt, ist es ein Hauptziel für Angreifer. Hier ist ein Beispiel für ein Tracking-Skript mit einer Funktion, die eval auf beliebigem JavaScript verwendet. Interessanterweise heißt die Funktion tatsächlich arbitraryJSCode.

Obwohl eval nicht unbedingt in allen Fällen alles zerstört, birgt es Risiken, sodass es zumindest eine zweite Prüfung verdient, wenn Sie es sehen.

Ändern Ihres Layouts

Einige Tracking-Skripte fügen winzige Bilder und iFrames am unteren oder oberen Rand Ihrer Seite ein, was eine Lücke über Ihrem Header oder unter Ihrem Footer erzeugen kann.

Der folgende Screenshot zeigt ein Tracking-Tag, das eine Lücke am unteren Rand der Comcast/Xfinity-Website erzeugt.

Alternativ kann ein Skript von Drittanbietern einfach fehlerhaft sein, wie im folgenden Screenshot mit einem Werbe-Code auf der Elite Daily-Website.

Fehler werden durch zu enge Kopplung der Funktionalität an das DOM verursacht

Das folgende Beispiel zeigt ein Tracking-Skript, dessen Funktionalität von bestimmten DOM-Elementen abhängt. Eine leichte Änderung am Layout der Website kann diesen Code brechen.

Zusammenfassung

Skripte von Drittanbietern können leistungsstarke Funktionalitäten bieten, aber sie bergen auch Risiken für Datenschutz, Sicherheit, Leistung und Seitenverhalten. Nachdem Sie nun einige der Risiken von Skripten von Drittanbietern gesehen haben, haben Sie hoffentlich eine Vorstellung davon, was Sie erwarten können, wenn Sie ihnen begegnen.

Wenn Sie Fragen, Gedanken oder Geschichten haben, hinterlassen Sie gerne einen Kommentar. Es wäre interessant zu hören, wie Leute über die Integration nachdenken. Vermeiden Sie sie ganz? Erlauben Sie nur Quellen, denen Sie sehr vertrauen? Verwenden Sie einen Vermittler wie vielleicht Google Tag Manager oder Segment? Überprüfen Sie den Code selbst, indem Sie ihn lesen oder DevTools genau beobachten?

Phil

# 27. Juni 2016

Ich habe nie verstanden, warum Leute gut bekannte Bibliotheken wie jQuery oder Prototype.js von Google oder anderen Content-Providern laden. Es ist so einfach, sie selbst auf dem eigenen Server zu verwalten. Sharding und CDN mögen gute Argumente sein, aber nur mit dem Risiko zusätzlicher Fehlerquellen.

Hosten Sie so viele dieser Bibliotheken wie möglich auf Ihrem eigenen Server.
Fassen Sie Skripte in einer einzigen Datei zusammen (verwenden Sie ggf. Grunt).
Wenn Ihre Website viele Assets verwendet: Ziehen Sie Sharding in Betracht. Wenn der Webserver über ungenutzte Ressourcen verfügt, können Sie einfach Servernamen in der DNS hinzufügen, was den Browser zwingt, mehr gleichzeitige Verbindungen zu Ihrem Server zu öffnen. Dies ist natürlich redundant mit HTTP/2 oder SPDY.
Betrachten Sie selbst geschriebene, verzögerte Skripteinfügung.

function loadJS(sUrl,iDelay)
{
    setTimeout
    (
        function()
        {
            var s=document.createElement('script');
            s.type='text/javascript';
            s.src=sUrl;
            document.getElementsByTagName('head')[0].appendChild(s);
        },
        iDelay
    );
}

loadJS('js/tracker_min.js',2000);

/* Yes, this is allman style. I like it. */

gcampbell

Permalink zum Kommentar# 27. Juni 2016

Warum verwenden Sie type="text/javascript"?
Yaphi

Permalink zum Kommentar# 27. Juni 2016

Ich stimme zu, und ich persönlich bevorzuge die Idee, Bibliotheken wie jQuery auf dem eigenen Server zu hosten. Ich bin sicher, es gibt andere Seiten dazu, aber ich stimme Ihnen zu, dass das separate Hosten eine zusätzliche Fehlerquelle darstellt.

Was die Tracking-Skripte angeht, so erfordern einige davon eine direkte Interaktion mit den Servern von Drittanbietern, was die Sache verkomplizieren und eine ganze Reihe von Risiken mit sich bringen kann.
Phil

Permalink zum Kommentar# 27. Juni 2016

@gcampbell: Warum .type=’text/javascript’ verwenden?

Ich erinnere mich, Probleme mit bestimmten Browsern gehabt zu haben, wenn der Skripttyp nicht angegeben war. Welche, kann ich mich im Moment nicht erinnern; ich habe früher Pads, Handys usw. mit solchen JS-Lösungen ausprobiert. Vielleicht kann jemand anderes das beantworten?
gcampbell

Permalink zum Kommentar# 28. Juni 2016

@Phil

Habe etwas recherchiert, nur HTML4-Tags ohne type-Attribut sind als Fehler gedacht, aber Browser scheinen standardmäßig type=”text/javascript” zu verwenden. Siehe

http://stackoverflow.com/questions/2267476/html-script-tag-type-or-language-or-omit-both
http://stackoverflow.com/questions/4195427/is-the-type-attribute-necessary-for-script-tags
http://javascript.crockford.com/script.html

Carsten

Der Grund für die Verwendung von CDNs für gängige Bibliotheken wie jQuery und so weiter ist, dass Ihre Besucher dieses Skript oft BEREITS in ihrem Browser-Cache heruntergeladen haben – wodurch IHRE Website SCHNELLER geladen wird = bessere Platzierung bei Google in Bezug auf mobile Zugänglichkeit (Zeit zum Herunterladen und Rendern der ersten Seite).