Hallo zusammen, hier ist Pat Reeves von botsec.net. Heute möchte ich über etwas sprechen, das mich in letzter Zeit ein wenig wach gehalten hat, und das sind nicht die üblichen Schauer von einem nächtlichen Kaffee. Es ist das stille Summen von Bots, nicht die gute Art, und der schiere Dreistigkeit, mit der einige Angreifer ihre Klauen anlegen. Genauer gesagt, spreche ich über Session-Hijacking, aber nicht irgendein Session-Hijacking. Wir werden erkunden, wie sich das entwickelt, insbesondere mit dem Anstieg der ausgeklügelten digitalen Fingerabdrücke von Browsern und Kompromittierungen auf der Client-Seite. Es geht nicht mehr nur darum, ein Cookie zu stehlen; es geht darum, den Benutzer zu werden, auf eine zunehmend schwer zu erkennende Weise.
Als ich das letzte Mal wirklich in dieses Thema eingetaucht bin, vor vielleicht drei oder vier Jahren, war der allgemeine Rat „sichere deine Cookies mit den Flags HttpOnly und Secure, verwende kurze Session-Timeouts und generiere nach der Authentifizierung neue Session-IDs“. Alles gute Ratschläge, muss ich sagen, und nach wie vor absolut entscheidend. Aber was passiert, wenn der Angreifer nicht nur dein Cookie von einem Netzwerk-Sniff oder einer XSS-Schwachstelle stiehlt? Was passiert, wenn er bereits im Browser ist, geduldig zusieht und sich dann in eine aktive, vollkommen gültige Sitzung injiziert?
Die sich entwickelnde Bedrohung: Mehr als nur gestohlene Cookies
Ich hatte letzten Monat einen Anruf mit einem Kunden, einem mittelständischen SaaS-Unternehmen, der sich die Haare rieb über eine Reihe von sehr gezielten Kontoübernahmen. Ihre Sicherheitsprotokolle waren tadellos. Keine fehlgeschlagenen Anmeldeversuche, kein Bruteforce, keine seltsamen IP-Wechsel. Es schien, als würden legitime Benutzer sich anmelden, ihre Dinge erledigen und plötzlich wurden kritische Einstellungen geändert oder Gelder überwiesen. Das Merkwürdige? Der „legitime“ Benutzer meldete oft Stunden später das Problem, völlig verwirrt. Er war zum Zeitpunkt der böswilligen Aktivität nicht angemeldet, oder wenn doch, dann nur, um etwas Unbedeutendes zu überprüfen.
Das war kein einfaches Replay-Angriff. Es war etwas hinterhältigeres. Nach intensiver Recherche fanden wir einen gemeinsamen Nenner: eine bestimmte Browsererweiterung, die viele ihrer Mitarbeiter und einige fortgeschrittene Benutzer installiert hatten. Ein scheinbar harmloses Produktivitätswerkzeug, das jedoch kompromittiert worden war. Es injizierte bösartigen JavaScript-Code direkt in die aktive Sitzung, zielte gezielt auf die API der Anwendung ab. Das Session-Cookie war nie gestohlen worden; es wurde verwendet von dem injizierten Code des Angreifers, der vom Browser des legitimen Benutzers kam, als ob der Benutzer die Anfragen selbst machte.
Client-seitige Kompromittierung: Die neue Grenze
Das hat mich wirklich getroffen. Wir verbringen so viel Zeit damit, unser Backend, unsere APIs, unsere Logik auf der Serverseite zu härten. Wir haben WAF, IDS, IPS, die gesamte alphabetische Suppe. Aber wenn ein Angreifer den Client – den Browser des Benutzers – kompromittieren kann, dann wird ein großer Teil dieses Schutzes viel weniger effektiv. Sie operieren effektiv von *innerhalb* des Perimeters, indem sie das Vertrauen des Benutzers ausnutzen.
Denk darüber nach: eine bösartige Browsererweiterung, ein Watering-Hole-Angriff, der eine vergiftete JavaScript-Bibliothek verteilt, oder sogar ein kompromittiertes Werbenetzwerk, das Code injiziert. Sobald dieser bösartige Code im Browser des Benutzers ausgeführt wird, hat er Zugriff auf das DOM, den localStorage, den sessionStorage und vor allem die Fähigkeit, Anfragen mit den bestehenden Session-Cookies des Benutzers zu machen. Es ist, als hätte man einen kleinen unsichtbaren Angreifer direkt neben seinem Benutzer sitzen, der seine Tastatur und Maus benutzt.
Was besorgniserregend ist, ist wie schwer es ist, dies zu erkennen. Aus der Sicht des Servers ist es eine gültige Sitzung, ein gültiger User-Agent, eine gültige IP, alles ist gültig. Die Anfragen erscheinen vollkommen normal, weil sie *wirklich* vom Browser des Benutzers mit seinen echten Session-IDs gemacht werden.
Sich gegen den Geist im Browser verteidigen
Also, was sollen wir dagegen tun? Wir können nicht einfach die Hände heben. Wir müssen unsere Verteidigungen weiterentwickeln. Hier sind einige Punkte, die ich empfohlen habe und an denen ich mit Kunden gearbeitet habe:
1. Stärken Sie Ihre Content-Security-Policy (CSP)
Das ist Ihre erste Verteidigungslinie gegen injizierte Skripte. Eine gut konfigurierte CSP kann erheblich einschränken, welche Skripte auf Ihrer Seite ausgeführt werden dürfen und von wo sie Ressourcen laden können. Sie blockiert nicht direkt eine bösartige Browsererweiterung, da Erweiterungen oft außerhalb der CSP arbeiten, aber sie ist entscheidend, um XSS und andere Formen von Skriptinjektionen aus der Sicht des Servers oder von kompromittierten Drittanbieterskripten zu verhindern.
Eine strenge CSP kann Inline-Skripte verhindern, die Skriptquellen auf vertrauenswürdige Domains einschränken und sogar begrenzen, wo Formulare Daten absenden können. Es ist keine Allheilmittel, aber es erhöht erheblich den Schwierigkeitsgrad.
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self';
Dieses Modell erlaubt Skripte nur von Ihrer eigenen Domain und einer spezifischen vertrauenswürdigen CDN. Es verbietet Inline-Skripte, eval() und das Laden von Objekten. Das ist ein Ausgangspunkt; Sie müssen es an die spezifischen Bedürfnisse Ihrer Anwendung anpassen, was mühsam sein kann, aber es ist es wert.
2. Implementieren Sie Verhaltensanalysen und Anomalieerkennung
Da die Serverprotokolle „normal“ erscheinen können, müssen wir anfangen zu suchen, was *unnormal* im Verhalten der Benutzer ist. Hier kommt die Verhaltensanalyse ins Spiel. Wenn sich ein Benutzer normalerweise aus London anmeldet, auf bestimmte Berichte zugreift und sich dann abmeldet, und er plötzlich administrative Aktionen ausführt, die er noch nie zuvor gemacht hat, oder auf empfindliche Daten in einer ungewöhnlichen Reihenfolge zugreift, sollte dies Alarm schlagen.
- Ungewöhnliche Sequenzierungen von API-Aufrufen: Sieht sich ein Benutzer normalerweise erst einen Bericht an und aktualisiert dann einen Datensatz? Oder führt er plötzlich direkte Aktualisierungsaufrufe ohne vorherige Konsultation aus?
- Geschwindigkeit der Aktionen: Führen Benutzer plötzlich Aktionen mit Maschinen-Geschwindigkeit aus, viel schneller, als ein Mensch klicken oder tippen könnte?
- Geografische Anomalien (mit Vorsicht): Obwohl IP-Änderungen harmlos sein können (Roaming, VPN), ist ein Benutzer, der plötzlich von einem Kontinent auf den anderen in Minuten wechselt, ein klares Warnsignal.
- Neue zugängliche Funktionen: Wenn ein Benutzer plötzlich auf Funktionen zugreift, mit denen er zuvor noch nie gearbeitet hat, insbesondere wenn es sich um sensible Funktionen handelt, sollte dies nachgeprüft werden.
Es geht nicht darum, jede Anomalie zu blockieren, sondern vertrauliche Punkte zu vergeben und verdächtige Aktivitäten zur Überprüfung hochzuschicken. Sie könnten die Aktion möglicherweise nicht sofort blockieren, aber Sie könnten eine erneute Authentifizierung erzwingen, eine Warnung an den Benutzer senden oder sogar vorübergehend den Zugriff auf risikobehaftete Funktionen einschränken.
3. Integritätsprüfungen auf der Client-Seite (mit Maß)
Das ist ein heikler Punkt und nicht ohne eigene Herausforderungen. Einige Anwendungen versuchen zu erkennen, ob ihr Client-Code manipuliert wurde. Dies könnte die Überprüfung von Checksummen der JavaScript-Dateien oder die Suche nach unerwarteten Änderungen im DOM umfassen. Das Problem ist, dass ein ausgeklügelter Angreifer, der den Browser kompromittiert hat, auch diese Prüfungen umgehen oder manipulieren kann.
Für weniger ausgeklügelte Angriffe oder um grundlegende Manipulationen zu erkennen, könnten Sie jedoch ein System implementieren, bei dem ein Hash von kritischen JavaScript-Dateien an den Server gesendet wird und der Server ihn mit seinem eigenen bekannten gültigen Hash überprüft. Wenn es eine Abweichung gibt, könnte dies auf eine Manipulation auf der Client-Seite hinweisen.
// Beispiel (vereinfacht, Client-Seite)
// In einer realen Situation wäre das komplexer und potenziell obfuskiert
function calculateScriptHash() {
const scriptContent = document.getElementById('critical-script').textContent;
return sha256(scriptContent); // Vorausgesetzt, das sha256-Utility ist verfügbar
}
// Beim Laden der Seite oder regelmäßig
const currentHash = calculateScriptHash();
// Senden Sie 'currentHash' an den Server zur Überprüfung
Der Server würde dann diesen `currentHash` mit einem vorab berechneten Hash vergleichen. Wenn sie nicht übereinstimmen, haben Sie ein Problem. Es ist jedoch ein Katz-und-Maus-Spiel. Ein entschlossener Angreifer könnte die Hash-Funktion selbst ändern oder einen falschen Hash bereitstellen.
4. Implementieren Sie FIDO2/WebAuthn für starke Authentifizierung
Obwohl dies nicht direkt die Sitzungsübernahme auf der Client-Seite verhindert, reduziert eine starke Authentifizierung erheblich die anfänglichen Kompromittierungsvektoren. Wenn ein Angreifer nicht einfach zu einem ersten Zugriff gelangt, kann er seinen Beobachtungsstandpunkt auf der Client-Seite nicht etablieren. FIDO2/WebAuthn, insbesondere mit Hardware-Token, bietet phishing-resistente Authentifizierung. Selbst wenn ein Benutzer in die Falle einer Phishing-Seite tappt, kann sein Hardware-Token sich nicht auf der falschen Domain authentifizieren, was die Übernahme des Kontos viel schwieriger macht.
Wenn Sie FIDO2 implementieren, wird ein Angreifer, selbst wenn er es schafft, eine Sitzung zu kompromittieren, dennoch nicht über die Hauptauthentifizierungs-ID des Benutzers verfügen. Das bedeutet, dass er sich nicht einfach re-authentifizieren kann, wenn die Sitzung abläuft oder wenn Sie eine Re-Authentifizierung erzwingen, nachdem Sie verdächtige Aktivitäten erkannt haben.
Was ich dagegen tue
Für botsec.net optimiere ich ständig meine CSP. Es ist ein lebendiges Dokument, ganz ehrlich, und jedes Mal, wenn ich ein neues Widget oder Skript hinzufüge, überarbeite ich es. Ich behalte auch meine Serverprotokolle sehr genau im Auge, um alles, was ungewöhnlich sein könnte, selbst wenn es wie eine „gültige“ Anfrage aussieht. Ich suche auch nach ausgefeilteren Verhaltensanalyse-Tools, insbesondere solchen, die sich in meine bestehende Protokollierungsinfrastruktur integrieren lassen. Das Ziel ist nicht, eine Festung zu errichten, die legitime Benutzer behindert, sondern ein System zu schaffen, das subtil erkennen kann, wann der Geist im Browser anfängt, die Fäden zu ziehen.
Es ist klar, dass sich das Schlachtfeld verändert. Wir können uns nicht mehr nur auf den Server und den Netzwerkperimeter konzentrieren. Die Client-Seite, der Browser des Benutzers, wird eine zunehmend attraktive Zielscheibe für Angreifer. Wir müssen anfangen, den Browser als eine potenziell feindliche Umgebung zu betrachten, selbst wenn er vermeintlich „uns gehört“.
Handlungsfähige Punkte
- Überprüfen und verschärfen Sie Ihre CSP: Seien Sie nicht nur damit zufrieden, eine zu haben; machen Sie sie streng und halten Sie sie aktuell. Ziehen Sie ein ‘report-uri’ in Betracht, um Verstöße zu sammeln, ohne zu blockieren.
- Investieren Sie in Verhaltensanalyse: Beginnen Sie mit der Aufzeichnung der Aktionen der Benutzer und suchen Sie nach Abweichungen von normalen Mustern. Das erfordert ein Verständnis der typischen Arbeitsabläufe Ihrer Benutzer.
- Erwägen Sie eine Re-Authentifizierung für risikobehaftete Aktionen: Für kritische Operationen (z. B. Passwortänderungen, Geldtransfers) zwingen Sie den Benutzer zur Re-Authentifizierung, sogar innerhalb einer aktiven Sitzung. Dadurch wird es einem Angreifer deutlich erschwert, die Aktion ohne die ausdrückliche Interaktion des Benutzers abzuschließen.
- Bildung der Benutzer (noch einmal!): Erinnern Sie die Benutzer an die Gefahren, unbekannte Browsererweiterungen zu installieren und auf verdächtige Links zu klicken. Auch wenn dies keine technische Kontrolle ist, ist es eine kritische Verteidigungsschicht.
- Erforschen Sie FIDO2/WebAuthn: Starke, phishing-resistente Authentifizierung ist entscheidend, um die anfängliche Kompromittierung des Kontos zu verhindern, die oft den Angriffen auf der Client-Seite vorausgeht.
Bleiben Sie vorsichtig und halten Sie diese Bots unter Kontrolle!
Verwandte Artikel
- Ich habe meine Bots kompromittiert gefunden: API-Schlüssel-Sicherheitsanfälligkeiten aufgedeckt
- Verteidigung gegen Eingabeaufforderungs-Injektion: Ein praktischer Vergleich mit Beispielen
- Sicherheit von KI-Bots in der Bildung
🕒 Published: