Hey Leute, Pat Reeves hier, zurück auf botsec.net. Heute möchte ich über etwas sprechen, das mich in letzter Zeit etwas wach hält, und es sind nicht die üblichen Koffein-Jitter in der Nacht. Es ist das leise Summen von Bots, nicht die gute Art, und die schiere Dreistigkeit, wie einige Angreifer ihre Fänge setzen. Genauer gesagt, spreche ich von Session-Hijacking, aber nicht von irgendeinem Session-Hijacking. Wir werden untersuchen, wie es sich verändert, insbesondere mit dem Anstieg von raffiniertem Browser-Fingerprinting und Client-Seiten-Komponenten. Es geht nicht mehr nur darum, ein Cookie zu stehlen; es geht darum, den Benutzer zu werden, in einer Weise, die zunehmend schwer zu erkennen ist.
Als ich das letzte Mal wirklich tief in dieses Thema eingetaucht bin, vielleicht vor drei oder vier Jahren, war der allgemeine Rat: „Sichern Sie Ihre Cookies mit HttpOnly- und Secure-Flags, verwenden Sie kurze Session-Timeouts und regenerieren Sie Session-IDs nach der Authentifizierung.“ Alles gute Ratschläge, wohlgemerkt, und immer noch absolut essenziell. Aber was passiert, wenn der Angreifer Ihr Cookie nicht einfach von einem Netzwerk-Sniff oder einer XSS-Sicherheitsanfälligkeit stiehlt? Was, wenn er bereits in Ihrem Browser sitzt, geduldig zusieht und sich dann in eine aktive, vollkommen gültige Sitzung einfügt?
Die sich entwickelnde Bedrohung: Mehr als nur gestohlene Cookies
Letzten Monat hatte ich einen Anruf mit einem Kunden, einem mittelständischen SaaS-Unternehmen, das sich über eine Reihe von hochgradig gezielten Kontoübernahmen den Kopf zerbrach. Ihre Sicherheitsprotokolle waren makellos. Keine fehlgeschlagenen Anmeldeversuche, kein Brute-Forcing, keine seltsamen IP-Änderungen. Es sah so aus, als würden legitime Benutzer sich anmelden, ihre Sachen erledigen und dann plötzlich kritische Einstellungen geändert werden oder Gelder überwiesen werden. Der Clou? Der „legitime“ Benutzer würde das Problem oft Stunden später melden, völlig verwirrt. Sie hatten sich zum Zeitpunkt der bösartigen Aktivitäten nicht angemeldet oder hatten sich nur angemeldet, um etwas Unbedenkliches zu überprüfen.
Dies war kein einfacher Replay-Angriff. Das war etwas Gemeineres. Nach gründlicher Recherche fanden wir einen gemeinsamen Nenner: eine bestimmte Browser-Erweiterung, die viele ihrer Mitarbeiter und einige Power-User installiert hatten. Ein scheinbar harmloses Produktivitätstool, aber eines, das kompromittiert worden war. Es injizierte bösartigen JavaScript-Code direkt in die aktive Sitzung, speziell in die APIs der Anwendung. Das Sitzungscookie wurde nie gestohlen; es wurde verwendet von dem injizierten Code des Angreifers, als ob der Benutzer selbst die Anfragen stellte.
Client-Seiten-Kompromittierung: Die neue Grenze
Das hat mich wirklich getroffen. Wir verbringen so viel Zeit damit, unser Backend, unsere APIs, unsere serverseitige Logik abzusichern. Wir haben WAFs, IDS, IPS, die ganze Buchstabensuppe. Aber wenn ein Angreifer den Client – den Browser des Benutzers – kompromittieren kann, dann wird ein Großteil dieses Schutzes viel weniger effektiv. Sie operieren effektiv von *innerhalb* des Perimeters und nutzen das Vertrauen des Benutzers.
Denken Sie darüber nach: eine bösartige Browser-Erweiterung, ein Watering-Hole-Angriff, der eine verseuchte JavaScript-Bibliothek bereitstellt, sogar ein kompromittiertes Anzeigenetzwerk, das Code injiziert. Sobald dieser bösartige Code im Browser des Benutzers läuft, hat er Zugriff auf das DOM, den localStorage, den sessionStorage und vor allem die Fähigkeit, Anfragen mit den bestehenden Sitzungscookies des Benutzers zu stellen. Es ist, als hätte man einen winzigen, unsichtbaren Angreifer direkt neben dem Benutzer sitzen, der ihre Tastatur und Maus benutzt.
Der beängstigende Teil ist, wie schwierig das zu erkennen ist. Aus der Perspektive des Servers ist es eine gültige Sitzung, ein gültiger Benutzer-Agent, eine gültige IP, alles gültig. Die Anfragen sehen völlig normal aus, weil sie *aus* dem Browser des Benutzers mit deren tatsächlichen Sitzungsanmeldeinformationen gemacht werden.
Schutz vor dem Geist im Browser
Was tun wir also dagegen? Wir können nicht einfach die Hände in den Schoß legen. Wir müssen unsere Abwehrmechanismen weiterentwickeln. Hier sind einige Dinge, die ich meinen Kunden empfehle und an denen ich arbeite:
1. Stärken Sie Ihre Content-Security-Policy (CSP)
Dies ist Ihre erste Verteidigungslinie gegen injizierte Skripte. Eine gut konfigurierte CSP kann erheblich einschränken, welche Skripte auf Ihrer Seite ausgeführt werden können und wo sie Ressourcen laden können. Sie wird eine bösartige Browser-Erweiterung nicht direkt stoppen, da Erweiterungen oft außerhalb der CSP arbeiten, aber sie ist entscheidend, um XSS und andere Arten der Skriptinjektion aus der Sicht des Servers oder von kompromittierten Drittanbieterskripten zu verhindern.
Eine strikte CSP kann Inline-Skripte verhindern, Skriptquellen auf vertrauenswürdige Domänen beschränken und sogar einschränken, wo Formulare Daten übermitteln können. Es ist kein Allheilmittel, aber es erhöht den Standard erheblich.
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 Beispiel erlaubt Skripte nur von Ihrer eigenen Domain und einem bestimmten vertrauenswürdigen CDN. Es verbietet Inline-Skripte, eval() und das Laden von Objekten. Es ist ein Ausgangspunkt; Sie müssen es auf die spezifischen Bedürfnisse Ihrer Anwendung anpassen, was mühsam sein kann, aber die Mühe wert ist.
2. Implementieren Sie Verhaltensanalysen und Anomalieerkennung
Da die serverseitigen Protokolle möglicherweise „normal“ aussehen, müssen wir beginnen, nach dem zu suchen, was *abnormal* im Benutzerverhalten ist. Hier kommt die Verhaltensanalyse ins Spiel. Wenn ein Benutzer typischerweise aus London einloggt, bestimmte Berichte aufruft und sich dann abmeldet, und plötzlich führt er administrative Aktionen aus, die er noch nie zuvor gemacht hat, oder greift in einer ungewöhnlichen Reihenfolge auf sensible Daten zu, sollte das ein Warnsignal auslösen.
- Ungewöhnliche API-Aufrufsequenzen: Sieht sich ein Benutzer typischerweise einen Bericht an und aktualisiert dann einen Datensatz? Oder führt er plötzlich direkte Aktualisierungen durch, ohne vorher etwas anzusehen?
- Geschwindigkeit der Aktionen: Führt der Benutzer plötzlich Aktionen in Maschinen-Geschwindigkeit aus, viel schneller, als ein Mensch klicken und tippen könnte?
- Geografische Anomalien (mit Vorsicht): Während IP-Änderungen harmlos sein können (Roaming, VPNs), ist es ein klares Warnsignal, wenn ein Benutzer plötzlich in wenigen Minuten zwischen Kontinenten springt.
- Neue Funktionen aufgerufen: Wenn ein Benutzer plötzlich beginnt, Funktionen zu nutzen, die er noch nie zuvor angefasst hat, vor allem sensible, ist das eine Untersuchung wert.
Es geht nicht darum, jede Anomalie zu blockieren, sondern darum, Vertrauenswerte zu erstellen und verdächtige Aktivitäten zur Überprüfung hochzustufen. Sie blockieren die Aktion vielleicht nicht sofort, aber Sie könnten eine erneute Authentifizierung erzwingen, eine Warnung an den Benutzer senden oder den Zugang zu hochriskanten Funktionen vorübergehend einschränken.
3. Client-Seiten-Integritätsprüfungen (mit Vorsicht)
Das ist eine kniffligere Angelegenheit und nicht ohne eigene Herausforderungen. Einige Anwendungen versuchen, zu erkennen, ob ihr clientseitiger Code manipuliert wurde. Dies kann die Überprüfung von Prüfziffern für JavaScript-Dateien oder das Suchen nach unerwarteten Änderungen im DOM umfassen. Das Problem ist, dass ein raffinierter Angreifer, der den Browser kompromittiert hat, diese Prüfungen ebenfalls umgehen oder manipulieren kann.
Für weniger raffinierte Angriffe oder um grundlegendes Manipulieren zu erkennen, könnten Sie jedoch ein System implementieren, bei dem ein Hash wichtiger JavaScript-Dateien an den Server gesendet wird, und der Server überprüft, ob dieser mit seinem eigenen bekannten guten Hash übereinstimmt. Wenn es eine Abweichung gibt, könnte das auf eine Manipulation auf der Client-Seite hindeuten.
// Beispiel (vereinfacht, clientseitig)
// In einem realen Szenario wäre dies komplexer und möglicherweise obfuskiert
function calculateScriptHash() {
const scriptContent = document.getElementById('critical-script').textContent;
return sha256(scriptContent); // Vorausgesetzt, sha256 Utility ist verfügbar
}
// Beim Laden der Seite oder periodisch
const currentHash = calculateScriptHash();
// 'currentHash' zum Server zur Überprüfung senden
Der Server würde dann diesen `currentHash` mit einem vorab berechneten Hash vergleichen. Wenn sie nicht übereinstimmen, haben Sie ein Problem. Dies ist jedoch ein Katz-und-Maus-Spiel. Ein entschlossener Angreifer könnte die Hash-Funktion selbst ändern oder einen gefälschten Hash bereitstellen.
4. FIDO2/WebAuthn für starke Authentifizierung nutzen
Während dies die klientenseitigen Session-Hijacking nicht direkt verhindert, reduziert starke Authentifizierung erheblich die anfänglichen Kompromittierungsvektoren. Wenn ein Angreifer nicht leicht Zugang erhalten kann, kann er seine clientseitige Beobachtungsstation nicht einrichten. FIDO2/WebAuthn, insbesondere mit Hardware-Schlüsseln, bietet phishing-resistente Authentifizierung. Selbst wenn ein Benutzer auf eine Phishing-Seite reinfällt, wird ihr Hardware-Schlüssel nicht für die falsche Domain authentifizieren, was eine Kontoübernahme erheblich erschwert.
Wenn Sie FIDO2 implementieren, selbst wenn ein Angreifer es schafft, eine Sitzung zu kompromittieren, hat er immer noch nicht die primäre Authentifizierungsanmeldeinformationen des Benutzers. Das bedeutet, dass er sich nicht leicht erneut authentifizieren kann, wenn die Sitzung abläuft oder wenn Sie nach der Erkennung verdächtiger Aktivitäten eine erneute Authentifizierung erzwingen.
Was ich dagegen tue
Für botsec.net verbessere ich ständig meine CSP. Es ist ein lebendiges Dokument, ehrlich gesagt, und jedes Mal, wenn ich ein neues Widget oder Skript hinzufüge, überarbeite ich es. Ich halte auch ein sehr genaues Auge auf meine Serverprotokolle nach allem Ungewöhnlichen, selbst wenn es wie eine „gültige“ Anfrage aussieht. Ich schaue zudem nach raffinierten Verhaltensanalysetools, insbesondere solchen, die mit meiner bestehenden Protokollierungsinfrastruktur integriert werden können. Das Ziel ist nicht, eine Festung zu schaffen, die legitimen Benutzern Unannehmlichkeiten bereitet, sondern ein System zu entwickeln, das subtil erkennt, wenn der Geist im Browser beginnt, Fäden zu ziehen.
Es ist klar, dass das Schlachtfeld sich verschiebt. Wir können uns nicht mehr nur auf den Server und den Netzwerkperimeter konzentrieren. Die Client-Seite, der Browser des Benutzers, ist ein zunehmend attraktives Ziel für Angreifer. Wir müssen anfangen, den Browser als potenziell feindliche Umgebung zu betrachten, selbst wenn er angeblich „unserer“ ist.
Umsetzbare Erkenntnisse
- Überprüfen und Verschärfen Sie Ihre CSP: Haben Sie nicht nur eine; machen Sie sie streng und halten Sie sie aktuell. Erwägen Sie eine ‚report-uri‘, um Verletzungen zu sammeln, ohne zu blockieren.
- Investieren Sie in Verhaltensanalysen: Beginnen Sie, Benutzeraktionen zu protokollieren und nach Abweichungen von normalen Mustern zu suchen. Dies erfordert ein Verständnis für die typischen Arbeitsabläufe Ihrer Benutzer.
- Erwägen Sie eine erneute Authentifizierung für hochriskante Aktionen: Für kritische Operationen (z. B. Passwortänderungen, Geldtransfers) zwingen Sie den Benutzer zur erneuten Authentifizierung, selbst innerhalb einer aktiven Sitzung. Dies erschwert es einem Angreifer erheblich, die Aktion ohne die ausdrückliche Interaktion des Benutzers abzuschließen.
- Bilden Sie Benutzer (wieder!): Erinnern Sie die Benutzer an die Gefahren der Installation unbekannter Browser-Erweiterungen und des Klickens auf verdächtige Links. Auch wenn dies keine technische Kontrolle ist, ist es immer noch eine kritische Verteidigungsschicht.
- Erforschen Sie FIDO2/WebAuthn: Starke, phishing-resistente Authentifizierung ist der Schlüssel zur Verhinderung anfänglicher Konto-Kompromittierungen, die oft vor clientseitigen Angriffen erfolgen.
Bleiben Sie sicher da draußen und halten Sie diese Bots im Schach!
Verwandte Artikel
- Ich fand meine Bots kompromittiert: API-Schlüssel-Sicherheitsanfälligkeiten aufgedeckt
- Prompt Injection Verteidigung: Ein praktischer Vergleich mit Beispielen
- KI-Bot-Sicherheit in der Bildung
🕒 Published: