Monitoring von Subressourcen mit Compute

Eine der lästigsten Herausforderungen für App-Betreiber und -Nutzer ist der Schutz von Webanwendungen und APIs (WAAP). Angreifer machen sich an den Ressourcen zu schaffen, von denen eine Website abhängt, um Zahlungsinformationen abzuschöpfen, Passwörter zu stehlen oder Malware zu installieren. 

Angesichts dieses Problems wollten wir herausfinden, ob wir eine Lösung für das Monitoring von Subressourcen entwickeln können, um unseren Kunden die Schwierigkeiten zu ersparen, die mit der Änderung und Manipulation von Ressourcen verbunden sind. In diesem Post erhalten Sie einen Überblick über den Problembereich und unsere Lösung, die in unserer Serverless-Compute-Umgebung Compute zum Einsatz kommt.

Was ist eine Ressource (oder Subressource)? 

„Als Ressource gilt alles mit einer Identität, darunter elektronische Dokumente, Bilder, Services (wie der heutige Wetterbericht für Los Angeles) und eine Reihe anderer Ressourcen.“ -- RFC 2396, August 1998

Eine Subressource ist eine Ressource, die als Teil einer anderen Ressource geladen wird. Mit Blick auf dieses Projekt definieren wir sie als alles, was einen Uniform Resource Identifier (URI) hat (von denen URLs eine Variante sind). Wenn ein Nutzer eine Webseite (eine Ressource) anfordert, die in seinem Browser geladen werden soll, sind die CSS-Datei, die das Aussehen der Seite bestimmt, und die JavaScript-Datei, die die notwendigen Funktionen enthält, ebenfalls Subressourcen, die geladen werden müssen. Diese Subressourcen können und werden oft von einem Dritten geladen, der darauf spezialisiert ist, Inhalte schnell und zuverlässig an die Nutzer auszuliefern, zum Beispiel von einem Content Delivery Network (CDN).

Da Compute auf unserem CDN basiert, ist es der perfekte Ort, um diese Subressourcen zu überwachen: Mit unserem Edge-Computing-Netzwerk können Entwickler eigens entwickelten Programmcode direkt auf unserem weltweit verteilten Netzwerk, der Edge-Cloud-Plattform, ausführen.

Was passiert, wenn ein Angreifer eine Subressource modifiziert?

Wenn ein Angreifer eine Subressource verändert, kann er verschiedene Arten von Problemen verursachen, die jedoch alle unter die Kategorie „Modifizierung von Skriptabhängigkeiten“ fallen.

Die meisten modernen Websites benötigen mindestens eine JavaScript Datei, um Nutzern die gewünschten Funktionen bereitzustellen. Diese notwendigen JavaScript Dateien werden oft als Skriptabhängigkeiten bezeichnet. Ein klassischer Fall von Angreifern, die Skriptabhängigkeiten missbrauchen, ist Magecart. Dabei wird JavaScript Code in Online-Bezahlformulare eingefügt, um Kreditkartendaten abzuschöpfen.

Angriffe zielen üblicherweise auf eine Drittanbieterabhängigkeit ab, um das ursprüngliche Skript zu verändern. Aber es gibt auch die Möglichkeit eines langfristigen Betrugs, bei dem ein Angreifer als legitimer Skriptverwalter auftritt und sich später als bösartig erweist. 

Die Änderung von Skriptabhängigkeiten erleichtert auch Cross-Site Scripting (XSS) und Cross-Site Request Forgery (CSRF):

• XSS-Angriffe kapern das Konto oder die Browsersitzung eines Nutzers, wodurch der Angreifer Zahlungsinformationen oder Kennwörter stehlen und möglicherweise auch Malware installieren kann.

• CSRF-Angriffe zwingen Nutzer dazu, (ohne ihr Wissen oder ihre Zustimmung) eine Anfrage in einer Webanwendung zu übermitteln. Dies ermöglicht es dem Angreifer, den Status der Webanwendung zu manipulieren, um beispielsweise Passwörter zu ändern, Geld zu überweisen, Einkäufe zu tätigen und andere Funktionen der App zu missbrauchen.

Wie kann man sich vor der Manipulation von Subressourcen schützen?

Grundsätzlich können Sie sich vor Änderungen von Subressourcen schützen, indem Sie eine Bestandsaufnahme sämtlicher Skripte, Stylesheets und anderer Ressourcen durchführen, die in Ihrer Anwendung benötigt werden, und anschließend die Vorteile von Subresource Integrity (SRI) nutzen. SRI ist ein optionales (aber sehr empfehlenswertes!) Feature für Skript- und Stylesheet-Link-Tags, das von Browsern genutzt wird, um zu überprüfen, ob die Ressourcen von Origin-Servern oder CDNs ohne unbeabsichtigte oder unautorisierte Änderungen ausgeliefert werden.Etwaige Verstöße können mithilfe von Content Security Policy Headern an einen bestimmten Endpoint gemeldet werden.

Wenn ein Angreifer ein bösartiges Skript einschleust, kann SRI Ihre Webanwendung allerdings nicht retten. Angreifer sind Ihnen leider nicht behilflich, ein Integritätsfeature für ihr Skript bereitzustellen, sodass der Browser nichts dagegen unternehmen kann. Allerdings kann die Content Security Policy diesen Fall verhindern, wenn Sie eine strenge Richtlinie (Vermeidung von „unsafe-inline“) implementieren.

Wie können wir uns noch besser gegen Änderungen von Subressourcen schützen?

Es gibt eine Reihe geeigneter Schutzmaßnahmen, die wir von der Edge aus implementieren können.  Compute ermöglicht es uns, einen Proxy zu implementieren, der Subressourcen verfolgt und Verstöße gegen die Content Security Policies automatisch überwacht. Schauen wir uns an, wie dies im Detail funktioniert.

Die Implementierung eines Proxys in Compute ermöglicht es uns, alle Subressourcen zu verfolgen, die in Antworten auf Client-Anfragen erscheinen. Wenn der Proxy also eine neue Subressource für eine bestimmte Website entdeckt, kann er eine Warnung an den Service-Inhaber senden, um ihn über diese nichtautorisierten Änderungen an externen Skripten und CSS-Dateien zu informieren. Im Großen und Ganzen sieht der Proxy-Prozess wie folgt aus:

Wenn ein Kunde beispielsweise die index.html seiner Website über Fastly bereitstellt, erkennt der Proxy in Compute alle bislang unbekannten Skriptquellen in der Antwort des Origin-Servers. Wir können diese Informationen verwenden, um eine Warnung zu generieren oder eine Benachrichtigung in der Nutzeroberfläche anzuzeigen, sodass Website-Besitzer erfahren können, wenn unerwartete Subressourcen vom Proxy erkannt werden. (Beispiel: https://sketchcdn.attacker.com/js/bootstrap.bundle.min.js im nachfolgenden Screenshot.)

Wir können auch den Header „Content-Security-Policy-Report-Only“ zu dem in Compute implementierten Proxy hinzufügen, um das automatische Monitoring von Richtlinienverletzungen zu erleichtern. Wenn ein Angreifer beispielsweise versucht, ein Skript an einem bekannten URI zu manipulieren, können wir über Compute auch einen Endpoint für das Reporting bereitstellen. So kann der Browser Verstöße melden, die dann (über unsere bestehenden Echtzeit-Log-Integrationen) an den Kunden weitergeleitet werden können.

Fazit

Unser Projekt nutzte die Leistungsfähigkeit und Reichweite von Compute, um einen Proxy zu implementieren, der die Änderung von Subressourcen durch Angreifer überwacht. Auf dieser Grundlage könnten wir zum Beispiel ein Out-of-Browser-Äquivalent zu Browser-Integritätsprüfungen schaffen, indem wir einen separaten Prozess verwenden, um Ressourcen von Drittanbietern abzurufen und sie in regelmäßigen Abständen für einen Hash-Vergleich zu nutzen, um den Eigentümer der Website auf Änderungen der Ressourcenintegrität aufmerksam zu machen.

Wenn Sie neugierig sind, was Compute noch so alles kann, können Sie es jetzt mit kostenlosem Guthaben unverbindlich testen.Probieren Sie es aus.