Hallo zusammen, Pat Reeves hier, zurück auf botsec.net. Heute möchte ich über etwas sprechen, das mich in letzter Zeit ein wenig wach hält, und das sind nicht die üblichen Kaffeezuckungen spät in der Nacht. Es ist das stille Summen der Bots, nicht die gute Sorte, und der pure Frechheit, die einige Angreifer zeigen, um sich einzuschleichen. Ich rede speziell über Session Hijacking, aber nicht über irgendein Session Hijacking. Wir werden erkunden, wie sich das entwickelt, insbesondere mit dem Anstieg des anspruchsvollen Trackings von Browsern und Client-Seite Kompromittierungen. Es geht nicht mehr nur darum, ein Cookie zu stehlen; es geht darum, der Benutzer zu werden, auf eine zunehmend schwer zu erkennende Weise.
Das letzte Mal, als ich dieses Thema wirklich vertieft habe, ist vielleicht drei oder vier Jahre her, war der allgemeine Rat „Schützen Sie Ihre Cookies mit den HttpOnly- und Secure-Flags, verwenden Sie kurze Sitzungstimeouts und regenerieren Sie die Session-IDs nach der Authentifizierung.“ Alles gute Ratschläge, das kann ich Ihnen versichern, und immer noch absolut wichtig. Aber was passiert, wenn der Angreifer nicht nur Ihr Cookie durch Netzwerk-Sniffing oder eine XSS-Schwachstelle stiehlt? Was passiert, wenn sie bereits in Ihrem Browser sind, geduldig beobachten und sich dann in eine aktive, völlig legitime Sitzung einklinken?
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 die Köpfe über eine Reihe von gezielten Kontenübernahmen zerbrach. Ihre Sicherheitsprotokolle waren makellos. Keine fehlgeschlagenen Anmeldeversuche, kein Brute-Force, keine seltsamen IP-Wechsel. Es schien, als ob legitime Benutzer sich anmeldeten, ihre Dinge erledigten und dann plötzlich kritische Einstellungen geändert oder Gelder übertragen wurden. Am auffälligsten? Der „legitime“ Benutzer meldete das Problem oft erst Stunden später, völlig perplex. Sie hatten sich nicht zum Zeitpunkt der böswilligen Aktivität eingeloggt oder sie taten dies, nur um etwas Unbedeutendes zu überprüfen.
Es war kein einfaches Replay-Angriff. Es war etwas Gemeineres. Nach viel Graben fanden wir einen gemeinsamen Nenner: eine bestimmte Browsererweiterung, die viele ihrer Mitarbeiter und einige Power-User installiert hatten. Ein scheinbar harmloses Produktivitätstool, das kompromittiert worden war. Es injizierte böswilliges JavaScript direkt in die aktive Sitzung und zielte spezifisch auf die API der Anwendung ab. Das Session-Cookie wurde nie gestohlen; es wurde verwendet von dem injizierten Code des Angreifers, direkt aus dem Browser des legitimen Benutzers, als ob der Benutzer selbst die Anfragen stellte.
Client-Seite 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 abgedroschene Alphabet-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 *aus dem Inneren* des Perimeters, indem sie das bestehende Vertrauen des Benutzers nutzen.
Denken Sie darüber nach: eine bösartige Browsererweiterung, ein Watering-Hole-Angriff, der eine vergiftete JavaScript-Bibliothek bereitstellt, sogar ein kompromittiertes Werbenetzwerk, das Code injiziert. Sobald dieser böswillige Code im Browser des Benutzers ausgeführt wird, hat er Zugriff auf das DOM, localStorage, sessionStorage und vor allem die Möglichkeit, Anfragen mit den bestehenden Session-Cookies des Benutzers zu stellen. Es ist, als hätte man einen kleinen unsichtbaren Angreifer direkt neben seinem Benutzer sitzen, der seine Tastatur und Maus benutzt.
Das Beunruhigende 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 *von* dem Browser des Benutzers mit seinen tatsächlichen Session-IDs gemacht werden.
Schutz gegen den Geist im Browser
Also, was tun wir dagegen? Wir können nicht einfach die Hände in den Schoß legen. Wir müssen unsere Abwehrmaßnahmen 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)
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 woher sie Ressourcen laden dürfen. Dies wird eine bösartige Browsererweiterung nicht direkt stoppen, da Erweiterungen oft außerhalb der CSP arbeiten, aber es ist entscheidend, um XSS und andere Formen von Skriptinjektion aus der Sicht des Servers oder von kompromittierten Drittanbieter-Skripten zu verhindern.
Eine strenge CSP kann inline-Skripte verbieten, die Skriptquellen auf vertrauenswürdige Domains beschränken und sogar festlegen, wo Formulare Daten übermitteln dürfen. Es ist keine Allheilmittel-Lösung, aber es erhöht das Schutzniveau 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 nur Skripte von Ihrer eigenen Domain und einem bestimmten vertrauenswürdigen CDN. Es verbietet Inline-Skripte, eval() und das Laden von Objekten. Das ist ein Ausgangspunkt; Sie werden es an die spezifischen Bedürfnisse Ihrer Anwendung anpassen müssen, was mühsam sein kann, aber es lohnt sich.
2. Implementieren Sie Verhaltensanalysen und Anomaliederkennung
Da die Protokolle auf Serverseite „normal“ erscheinen könnten, müssen wir anfangen zu suchen, was *anomal* im Verhalten der Benutzer ist. Hier kommt die Verhaltensanalyse ins Spiel. Wenn sich ein Benutzer typischerweise aus London anmeldet, auf bestimmte Berichte zugreift und sich dann abmeldet, und plötzlich administrative Aktionen ausführt, die er noch nie zuvor gemacht hat, oder auf sensible Daten in einer ungewöhnlichen Reihenfolge zugreift, sollte dies alarmieren.
- Ungewöhnliche API-Aufrufsequenzen: Ruft ein Benutzer in der Regel einen Bericht auf, um dann einen Datensatz zu aktualisieren? Oder beginnt er plötzlich, direkte Aktualisierungsaufrufe ohne vorherige Abfrage zu machen?
- Geschwindigkeit der Aktionen: Führt der Benutzer plötzlich Aktionen in maschinenartiger Geschwindigkeit aus, viel schneller, als ein Mensch klicken und tippen könnte?
- Geografische Anomalien (mit Vorsicht): Während IP-Wechsel harmlos sein können (Roaming, VPN), ist ein Benutzer, der plötzlich innerhalb von Minuten zwischen Kontinenten wechselt, ein klares Alarmzeichen.
- Neu aufgerufene Funktionen: Wenn ein Benutzer plötzlich auf Funktionen zugreift, die er zuvor nie berührt hat, speziell auf sensible Funktionen, rechtfertigt dies eine Untersuchung.
Es geht nicht darum, jede Anomalie zu blockieren, sondern Vertrauenswerte zu bilden und verdächtige Aktivitäten zur erneuten Prüfung zu eskalieren. Vielleicht werden Sie die Aktion nicht sofort blockieren, aber Sie könnten eine erneute Authentifizierung erzwingen, eine Benachrichtigung an den Benutzer senden oder sogar den Zugriff auf risikobehaftete Funktionen vorübergehend einschränken.
3. Integritätsprüfungen auf Client-Seite (mit Vorsicht)
Dies ist ein heikleres Thema und nicht ohne seine eigenen Herausforderungen. Einige Anwendungen versuchen zu erkennen, ob ihr Client-Code verändert wurde. Dies kann Datei-Checksummen von JavaScript oder die Suche nach unerwarteten Änderungen im DOM umfassen. Das Problem ist, dass ein ausgeklügelter Angreifer, der den Browser kompromittiert hat, diese Prüfungen ebenfalls umgehen oder manipulieren kann.
Für weniger ausgeklügelte Angriffe oder zur Erkennung grundlegender Manipulationen könnten Sie jedoch ein System implementieren, bei dem ein Hash kritischer JavaScript-Dateien an den Server gesendet wird, und der Server diesen Hash mit seinem eigenen bekannten Hash vergleicht. Wenn es eine Diskrepanz gibt, könnte das auf eine Client-Seitige Manipulation hindeuten.
// Beispiel (vereinfacht, Client-Seite)
// In einem realen Szenario wäre dies komplexer und potenziell obfuskiert
function calculateScriptHash() {
const scriptContent = document.getElementById('critical-script').textContent;
return sha256(scriptContent); // Vorausgesetzt, eine sha256 Hilfsfunktion ist verfügbar
}
// Beim Laden der Seite oder periodisch
const currentHash = calculateScriptHash();
// 'currentHash' an den Server zur Überprüfung senden
Der Server würde dann diesen `currentHash` mit einem vordefinierten Hash vergleichen. Wenn sie nicht übereinstimmen, haben Sie ein Problem. Es ist jedoch ein Katz-und-Maus-Spiel. Ein entschlossener Angreifer könnte die Hashfunktion selbst ändern oder einen falschen Hash bereitstellen.
4. Übernehmen Sie FIDO2/WebAuthn für starke Authentifizierung
Obwohl dies den Diebstahl von Clientsitzungen nicht direkt verhindert, verringert eine starke Authentifizierung erheblich die anfänglichen Kompromittierungsvektoren. Wenn ein Angreifer keinen einfachen Zugriff auf die Sitzung erhält, kann er seinen Client-Beobachtungsplatz nicht einrichten. FIDO2/WebAuthn, insbesondere mit Hardware-Schlüsseln, bietet eine phishing-resistente Authentifizierung. Selbst wenn ein Benutzer auf einer Phishing-Seite landet, kann sich sein Hardware-Schlüssel nicht im falschen Domain authentifizieren, was die Übernahme des Kontos erheblich erschwert.
Wenn Sie FIDO2 implementieren, hat ein Angreifer selbst dann, wenn er es schafft, eine Sitzung zu kompromittieren, immer noch nicht die Hauptidentifikation zur Authentifizierung des Benutzers. Das bedeutet, dass er sich nicht einfach erneut authentifizieren kann, wenn die Sitzung abläuft oder wenn Sie eine erneute Authentifizierung nach der Erkennung verdächtiger Aktivitäten erzwingen.
Was ich dagegen tue
Für botsec.net verfeinere 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 halte auch ein sehr aufmerksames Auge auf meine Serverprotokolle, um etwas Ungewöhnliches zu erkennen, selbst wenn es wie eine „gültige“ Anfrage aussieht. Ich untersuche auch raffiniertere Tools zur Verhaltensanalyse, insbesondere solche, die sich in meine bestehende Protokollinfrastruktur integrieren können. Das Ziel ist nicht, eine Festung zu schaffen, die legitime Benutzer stört, sondern ein System aufzubauen, das subtil erkennen kann, wenn der Geist im Browser anfängt, die Fäden zu ziehen.
Es ist klar, dass sich das Schlachtfeld weiterentwickelt. Wir können uns nicht mehr nur auf den Server und den Netzwerkperimeter konzentrieren. Die Client-Seite, der Browser des Benutzers, wird für Angreifer zunehmend zu einem attraktiven Ziel. Wir müssen anfangen, den Browser als potenziell feindliches Umfeld zu betrachten, auch wenn er angeblich „uns gehört“.
Praktische Punkte zum Mitnehmen
- Überprüfen und verstärken Sie Ihre CSP: Seien Sie nicht einfach 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 damit, das Verhalten der Benutzer aufzuzeichnen und suchen Sie nach Abweichungen von normalen Mustern. Dies erfordert ein Verständnis der typischen Arbeitsabläufe Ihrer Benutzer.
- Erwägen Sie eine erneute Authentifizierung für risikobehaftete Aktionen: Bei kritischen Operationen (zum Beispiel Passwortänderungen, Geldtransfers) zwingen Sie den Benutzer zur erneuten Authentifizierung, selbst in einer aktiven Sitzung. Das erschwert es einem Angreifer erheblich, die Aktion ohne explizite Interaktion des Benutzers abzuschließen.
- Bildung der Benutzer (nochmals!): 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, stellt es dennoch eine wesentliche Verteidigungsschicht dar.
- Erforschen Sie FIDO2/WebAuthn: Eine solide und phishing-resistente Authentifizierung ist entscheidend, um die anfängliche Kompromittierung des Kontos zu verhindern, die oft den Angriffen auf Client-Seite vorausgeht.
Seien Sie vorsichtig da draußen und halten Sie diese Bots unter Kontrolle!
Verwandte Artikel
- Ich habe meine Bots kompromittiert gefunden: Offengelegte API-Schlüsselanfälligkeiten
- Verteidigung gegen Kommandoinjektion: Ein praktischer Vergleich mit Beispielen
- Sicherheit von AI-Bots in der Bildung
🕒 Published: