LTT Hack - generelle Bewertung Session Token / Auth Token

[M-X]

das glaube ich erst wenn ich es sehe.

Googel halt einfach wie Session cookies funktionieren, dann kannst du es auch mit eigenen Augen sehen.
Deine Passwörter kann ich auch mit einem Keylogger klauen wenn du sie eingibst, an dein KeePass komme ich auch wenn dein Safe entsperrt wird.

Google hat halt aus Komfortgründen die Session prüfungen wohl etwas locker gehabt. Trotzdem muss dafür erstmal jemand auf deine Kiste kommen um die Cookies zu klauen..

Hier ist halt der Fehler das jemand voll zugriff auf die Kiste hatte und dadurch eben Zugang zu diesen Daten hatte. Kein Hack sondern menschliches versagen.

 

[BeBur]

Ob eine Bank überhaupt lang laufende Sessions erlauben sollte?

Banken benutzen sichere 2FA Verfahren für die wichtigen Dinge.

Genau dieser Fall wird damit aktiv auf Serverseite unterbunden. Damit du eben nicht irgendwas einfach "kopieren" kannst und uneingeschränkten Zugriff erhälst. Wenn du mit jedem Request deine Daten erneut fakest, bekommst du halt keine Session. Schluss aus. Ich geh auch nicht in den Club und wechsel alle drei Minuten mein komplettes Outfit um dann dem Türsteher ein "ich war vor drei Minuten schon drin" an den Latz zu knallen.

Also ich denke du missverstehst da etwas grundlegend falsch. Der "User Agent" ist einfach nur ein String, der freiwillig mitgesendet wird. Der Fake ist daher ununterscheidbar vom Original. Auch alle anderen potentiellen Fingerprint-Eigenschaften können ziemlich trivial gefälscht bzw. kopiert werden.

 

[Piktogramm]

Mittel gegen Session Hijacking hat einzig Google in der Hand und auch für die Sicherheit ihrer Konten ist einzig Google verantwortlich. [...] Sehr wohl können sie aber Sessions invalidieren, wenn sich unterschiedliche Geräte von unterschiedlichen Standorten anmelden. Ggf. gar über nen längeren Zeitraum gleichzeitig.

Der letzte Request kam aus Timbuktu mit "Samsung Browser" und der jetzige Request kommt aus der Antarktis mit "curl"? Hm ja, klingt legitim. ¯\_(ツ)_/¯

Mich hat Google schon mehrfach aus Sessions geschmissen, als ich Zugriff aus "komischen" IPbereichen haben wollte. Die machen nicht gar nichts an der Stelle. Es könnte etwas empfindlicher sein, aber ein Allheilmittel ist das nicht. Zum einen weil man mit VPNs ganz fix geografische Nähe hinbekommt. Auf der anderen Seite sind Nutzer·innen heute mal ganz gern mobil und wechseln selbst zwischen Festnetz, Mobil, Hotspot und eigenen VPNs.
So richtig schön wäre da eine einstellbare Empfindlichkeit für geschäftliche Zwecke. Der Angriffsvektor geht an der Stelle aber nicht weg. Die Angreifer sind im Userspace um die Token zu extrahieren, da kann man als Angreifer genausogut auch ein VPN-Endpunkt im Userspace setzen und kann die Tokens vom selben Rechner aus wie das Ziel nutzen.

Oder zumindest vor der nächsten Aktion (gerade sowas wie "Account löschen", "tausende Videos löschen" u.ä.) erneut nach dem Passwort fragen. Das hat Linus ja auch im Video erwähnt, dass es schöne tolle Rate Limits für die API gibt, aber will man tausende Videos auf einmal löschen, kann man ohne Probleme gewähren.

Feinere und bessere Rechteverwaltung samt sinnvoller Ratelimits sind auf jeden Fall was Wert. So schnell wie Youtube und Google normalerweise Inhalte filtern, sollten der Laden auch generell in der Lage sein solche Kanalübernahmen mitzubekommen.

Genau dafür ist doch genanntes Szenario gedacht? Damit bei einem unterschiedlichen Browsern/User Agents eben nicht einfach die Session ID rüber kopiert werden kann. Genau dafür hat doch die Gegenseite sicherzustellen, dass sie nicht einfach beliebige Requests frisst und ausführt, sondern die Daten halbwegs auf Plausibilität prüft. Man fixiert sich heute extrem auf TLS und "ob der Server auch wirklich der Server ist", will MITM unterbinden und stellt Schranken noch und nöcher auf, aber bei der Richtung Client -> Server wird geschlampt wie eh und je in den 90ern?

Angreifer im Userspace kommt an Daten vom Browser lesen wie schreibend ran. Braucht es mehr als ein Sessionkey, kopiert man einfach alle Daten mit, die zum Fingerprinting nötig sind oder erweitert den Browser um ein Plugin, welches direkt als VPN-Endpunkt für die Angreifer etabliert. Fürs Redteam ist das allenfalls ein Witz, für das Blueteam ist es viel Arbeit.

Und auch die Trennung ist egal, denn prinzipiell kann das jeder einzelnen Rolle passieren. Mit den Rollen hast du die Authorisierung (wer darf was?) im Griff, nicht aber die Authentifizierung (wer bin ich?).

"denn prinzipiell kann das jeder" -> Was kann passieren? (Das ist ne Sprachkritik, es gibt kein Subjekt/Objekt aus welches sich dieses "das" beziehen kann)
Das mit einem Schädling von extern eine Rolle mit kritischen, internen Zugriffsrechten übernommen wird, wenn diese Rolle keine externen Kommunikationsrechte hat? Möglich ist das, weil die perfekte Trennung im Alltag meist nicht existiert, aber es ist so unglaublich viel schwieriger.

Mit dem gleichen Argument könnte man sagen, dass CSRF Blödsinn ist. Bis irgendwann jemand ein "Bild" (<img>) mit der URL "http://meine-bank.de/uberweisung-ausfuehren/?an=angreifer&wert=1000000" einbindet. Und jeder, der dort aktuell angemeldet ist, wundert sich, warum einem plötzlich Geld auf dem Konto fehlt. Mal abgesehen von der nächsten Lücke, dass Aktionen keinem GET-Request entsprechen sollten.

CSFR geht wunderbar über POST, wobei die Thematik CSFR in meinen Augen nicht sorecht zum LTT Hack passt. Über CSFR Sessiontokens und/oder Cookies zu extrahieren ist bei aktuellen Browsern schwierig.

Ergänzung (29. März 2023)

Auch sollte es bspw. ein PayPal oder eine Bank eher mehr interessieren, ob sich die IP oder der User Agent innerhalb der Sessionlaufzeit ändert. Aus sicherheitstechnischen Gründen wird die Session invalidiert, bevor Schabernack getrieben wird. Ob eine Bank überhaupt lang laufende Sessions erlauben sollte?

Banken haben da recht wenig Entscheidungsspielraum, die haben Richtlinien, dass sie Sessions nach wenigen Minuten invalidieren müssen. Genauso wie aller Monate einen 2FA Login erzwingen müssen und kritische Aktionen nur mit 2FA auszuführen sind.

 

[Arcturus128]

Es war keine PDF-Datei. Es war eine .scr (Screensaver) Datei getarnt als PDF samt Icon. Man KÖNNTE es erkennen, aber je nach Rahmenbedingung auch leicht übersehen.

Deshalb sollte man nie die Dateiendungen ausblenden lassen.

Mit einer Sicherheitslücke in Windows hat das nichts zu tun.

Wenn eine Screensaver-Datei einen Trojaner enthalten kann, dann kann man das durchaus als Sicherheitslücke bezeichnen.

 

[Yuuri]

Banken benutzen sichere 2FA Verfahren für die wichtigen Dinge.

Haha... :>

Also ich denke du missverstehst da etwas grundlegend falsch.

Nein. Du missverstehst eher das Problem.

Auch alle anderen potentiellen Fingerprint-Eigenschaften können ziemlich trivial gefälscht bzw. kopiert werden.

Ja können sie. Was aber zur Folge hat, dass eine Session, die von 10.0.0.1 und UA Firefox 100 initiiert wurde, nicht von 10.0.0.2 und Edge 95 "kopiert" werden kann. Genau das sagen doch die OWASP Guides aus. Dass eben nicht einfach irgendwas kopiert werden kann und trotzdem gültig ist, weil eben auf Serverseite erweiterte Prüfungen zur Plausibilität der Daten bestehen. Wenn keine Merkmale vorhanden sind, wird eben keine längere Session erlaubt.

Du willst hier grad nen OAuth Auth Code mit der Client ID abc haben und nen Auth Token mit Client ID def anfordern. Das klappt nicht, da wird dir sehr wohl ein Fehler um die Ohren geworfen.

Mich hat Google schon mehrfach aus Sessions geschmissen, als ich Zugriff aus "komischen" IPbereichen haben wollte.

Ich kenne nur den Captcha wenn Google meint, dass "komischer Traffic" von mir kommt. Aus der Session wurde ich aber nie geworfen oder irgendwas in der Art.

Es könnte etwas empfindlicher sein, aber ein Allheilmittel ist das nicht.

Nein. Ist es nicht. Aber ein zusätzlicher Faktor um Session Hijacking zu unterbinden oder mindestens zu erschweren.

Die Angreifer sind im Userspace um die Token zu extrahieren, da kann man als Angreifer genausogut auch ein VPN-Endpunkt im Userspace setzen und kann die Tokens vom selben Rechner aus wie das Ziel nutzen.

Umso sinnvoller, dass nicht blindlings jede Session aufgegriffen wird, die der Client einfach so ausweist. Je nach Umfang des Tokens und etwas Bruteforce könnte man damit jede einzelne Session übernehmen, bis ich irgendwann beim Admin angekommen bin und ein paar Channel lösche, die mich nerven. Aus dem Grund sollte die Session mindestens etwas gehärtet werden. Sonst kann ich als Session Token auch einfach den Usernamen verwenden, welcher genauso "sicher" wäre. Es gibt ja immerhin bereits eine Abstraktionsschicht dazwischen, dass der Server dir eine ID erteilt und die Sessiondaten bei sich speichert, während der Client nur dessen ID übermittelt. Jede Verbindung, die aber rein auf Clientseite läuft ist prinzipiell als unsicher zu betrachten und muss vom Server geprüft. Selbes Schicksal wie SQL-Injections.

Braucht es mehr als ein Sessionkey, kopiert man einfach alle Daten mit, die zum Fingerprinting nötig sind

Deswegen rede ich davon, dass die Session serverseitig gehärtet wird. Der Client bekommt weiterhin seinen Token zugespielt, auf Serverseite sollte diese aber genauso validiert werden. Da kann jeder kopieren wie er lustig ist und es passiert nichts, weil man clientseitig nicht einsehen kann, mit welchen Merkmalen der Server die Session härtet. Ist zwar etwas Security through Obscurity, aber wie bereits gesagt: Man versetzt Berge um eine verbesserte Serverauthentifizierung zu erreichen, schlampt aber vorn und hinten beim Client. Die Resultate sieht man somit bei übernommenen Accounts, ohne dass Credentials oder 2FA angefasst werden mussten, gar bereits geändert wurden und die Probleme trotzdem weiter bestehen.

In Zeiten von JWTs quasi unmöglich, da man diese eben ausgibt, damit man keine DB anfragen muss, aber eben auch ein eklatantes Problem, was es zudem unmöglich macht JWTs zurückzuziehen. Und wenn man JWTs zurückziehbar macht, landet man prinzipiell wieder bei herkömmlichen Cookies, hat aber einzig die Komplexität ins Unermessliche gesteigert. Quasi ein Baumhaus aus Carbon hergestellt. Schönes Proof of Concept. Ist halt trotzdem dumm.

"denn prinzipiell kann das jeder" -> Was kann passieren? (Das ist ne Sprachkritik, es gibt kein Subjekt/Objekt aus welches sich dieses "das" beziehen kann)

das = worüber wir uns hier gerade unterhalten

Das mit einem Schädling von extern eine Rolle mit kritischen, internen Zugriffsrechten übernommen wird, wenn diese Rolle keine externen Kommunikationsrechte hat?

Wir reden hier nicht vom Zugangs-PC für atomare Sprengköpfe, sondern von Google-Konten. Und ja, diese haben immer einen externen (Internet) Zugriff. Weiterhin ist es überhaupt offen, ob es explizit einen "Youtube-Kanal-Management-Scope" gibt, welcher getrennt vom eigentlichen "Google-eMail-Scope" liegt. Auch ist es zweifelhaft, dass es Write/Delete-Scopes gibt und "Rate-Limited-Scopes" sowieso nicht.

Ich hab hier allerdings keinen Firmenaccount oder Youtube-Kanal-whatever-Account um da irgendwas nachprüfen zu können.

CSFR geht wunderbar über POST, wobei die Thematik CSFR in meinen Augen nicht sorecht zum LTT Hack passt. Über CSFR Sessiontokens und/oder Cookies zu extrahieren ist bei aktuellen Browsern schwierig.

CSRF geht ausschließlich über POST. Und doch, es gibt Parallelen zum Session Hijacking. Bei CSRF wird sichergestellt, dass der User selbst die Aktion ausführt. Wenn man einen Link anklingt, ist das immer ein GET. Wenn der Link irgendwo eingebunden ist, ist das immer ein GET. CSRF ist nur bei POST aktiv und weiterhin brauch man immer einen aktuellen CSRF-Token, welcher nur vom Anbieter selbst ausgegeben wird, wodurch Forging Angriffe quasi unmöglich gemacht werden. CORS setzt dem dann noch die Krone auf, wobei ein Browser alle Requests zu "unterschiedlichen Origins" (nur Schema + Hostname + Port bilden "eine Quelle") einfach blockiert, was nicht mal durch den Request selbst, sondern durch einen Preflight (OPTIONS) validiert wird.

Serverseitig ist man mittlerweile relativ gut abgesichert, würde ich mal meinen.

Banken haben da recht wenig Entscheidungsspielraum, die haben Richtlinien, dass sie Sessions nach wenigen Minuten invalidieren müssen.

Ja, was die Richtlinien sagen ist mir prinzipiell vollkommen egal. In den Richtlinien kann sonst was drin stehen, so auch wie in manchen AGB steht, dass die Rechte am Erstgeborenen übergeben werden. Das ist genauso sinnvoll wie irgendwelche Zertifikate, wo sonst was ausgewiesen werden kann. Hier gehts aber um die Sicherheit und nicht dass irgendwo mal irgendwas festgehalten wurde. Dass die Richtlinien dann doch mal effektiv der Sicherheit dienen, ist doch eher löblich.

Was ich damit sagen will: Nur weil irgendwelche Richtlinien existieren, muss es deswegen nicht kritiklos hingenommen werden.

Ist es eigentlich auch ne Richtlinie, dass die Sparkasse (?) maximal 8-stellige Passwörter annimmt? Keine Ahnung welche das genau war...

À propos Richtlinie: Eine immer noch gültige "Richtlinie" beschreibt bspw., dass man sein Passwort alle drei Monate ändern soll und das geänderte Passwort nicht eines der letzten x Änderungen sein darf.

Frage: Wie sinnvoll ist diese Richtlinie so?

Also: Dass eine Richtlinie existiert, die man ggf. mehr oder minder dehnen kann, sagt genau gar nichts aus.

 

[BeBur]

Haha... :>

Wie oft wird in Deutschland denn Geld vom Girokonto geklaut, weil jemand gehackt worden ist?

Ja können sie. Was aber zur Folge hat, dass eine Session, die von 10.0.0.1 und UA Firefox 100 initiiert wurde, nicht von 10.0.0.2 und Edge 95 "kopiert" werden kann.

IP Bindung haben andere schon was zu gesagt, das ist schon wegen Mobilfunk nicht praktikabel. Zur anderen Sache siehe folgendes.

Da kann jeder kopieren wie er lustig ist und es passiert nichts, weil man clientseitig nicht einsehen kann, mit welchen Merkmalen der Server die Session härtet.

Welches Merkmal kann denn nicht zusammen mit der Session kopiert werden? Der User Agend ist wie gesagt einfach nur Text, der im HTTP Header mitgesendet wird und von jedem beliebig gewählt werden kann. Dein erwähntes curl bietet einen eigenen Parameter dafür.

 

[cruse]

Ich schreib mal ganz kurz wie es dazu gekommen ist. Wir nennen den Typ, der die E-Mail geöffnet hat einfach mal Linus^^

Also Linus bekommt eine Email, von einem "Sponsor". Einem neuen, er will also das Linus sein Produkt vorstellt.
Die ersten paar Emails waren noch ohne Anhang usw. Einfache Anfragen und Geplänkel. Und dann mit der X. ten Mail, kommt ein Vertrag zum Unterschreiben. (oder nähere Daten, etc - muss ja kein Vertrag sein) Das ist üblich.

Die .pdf.scr war über 700 mb groß und damit wandert sie bei den Live-Scannern auf Ignore. Sie wird also nicht gescannt. Die .scr war fast komplett mit Nullen gefüllt, damit diese 700 mb erreicht werden.

Soviel Dazu. Den Rest kann sich jeder vorstellen.

 

[Piktogramm]

Ja können sie. Was aber zur Folge hat, dass eine Session, die von 10.0.0.1 und UA Firefox 100 initiiert wurde, nicht von 10.0.0.2 und Edge 95 "kopiert" werden kann. Genau das sagen doch die OWASP Guides aus. Dass eben nicht einfach irgendwas kopiert werden kann und trotzdem gültig ist, weil eben auf Serverseite erweiterte Prüfungen zur Plausibilität der Daten bestehen. Wenn keine Merkmale vorhanden sind, wird eben keine längere Session erlaubt.

Dann die Frage, wie willst du verhindern, dass ein Angreifer, dessen Agent im Userspace sitzt nicht einfach alle Daten kopiert, die zum Emulieren aller notwendigen Clientdaten und Tokens notwendig ist?

Umso sinnvoller, dass nicht blindlings jede Session aufgegriffen wird, die der Client einfach so ausweist. Je nach Umfang des Tokens und etwas Bruteforce könnte man damit jede einzelne Session übernehmen, bis ich irgendwann beim Admin angekommen bin und ein paar Channel lösche, die mich nerven.

Das ist komplett unrealistisch. Meine Tokens bei Google sind haben alle eine geschätzte Entropie von >550bit[1]. Das ist kein Raum, wo über Netzwerk gegen einen Server mit Latenzen, Delay und sehr großzügigem Ratelimit Bruteforce auch nur im Ansatz wird. Die Sessiontokens sind dabei so groß, dass man sich nicht annähernd genügend IPv6 Blöcke beschaffen könnte um das Ratelimit sinnvoll zu umgehen[2]. Schon gar nicht um damit gezielt Accounts zu übernehmen. Diesem Token könnte man über Fingerprinting vom Client noch ein paar Bit extra Entropie spendieren, das ändert aber genau gar nichts. Die zusätzlichen paar Bits kopiert ein Angreifer einfach mit.

[1] Der Faulheit wegen nur ne Abschätzung des Passwortgenerators von KeePassXC
[2] Ja, da steht wirklich, dass der IPv6 Adressraum zu klein ist o.O

Aus dem Grund sollte die Session mindestens etwas gehärtet werden. Sonst kann ich als Session Token auch einfach den Usernamen verwenden, welcher genauso "sicher" wäre.

Sessionhandling verstanden?
[ ] Ja
[X] Nein

Es gibt ja immerhin bereits eine Abstraktionsschicht dazwischen, dass der Server dir eine ID erteilt und die Sessiondaten bei sich speichert, während der Client nur dessen ID übermittelt. Jede Verbindung, die aber rein auf Clientseite läuft ist prinzipiell als unsicher zu betrachten und muss vom Server geprüft. Selbes Schicksal wie SQL-Injections.

SQL Injections haben nicht viel mit Sessionhijacking zu tun, außer dass es unerwünschte Angriffe sind.. Sql-Server sollten nicht extern exponiert sein, Sessionhandling jedoch schon. Bei letzterem ist es "nur" wichtig, dass das ganze nur im gewünschtem/definiertem Umfang geschieht.

Deswegen rede ich davon, dass die Session serverseitig gehärtet wird.

Problem: Wir haben ne Client-Server-Verbindung, der Client wurde kompromittiert.
Lösung: Härtet den Server!!!!!!!!

Der Client bekommt weiterhin seinen Token zugespielt, auf Serverseite sollte diese aber genauso validiert werden. Da kann jeder kopieren wie er lustig ist und es passiert nichts, weil man clientseitig nicht einsehen kann, mit welchen Merkmalen der Server die Session härtet.

Als angreifer im Userspace kann ich wunderbar ALLE Daten einsehen, die zwischen Browser/berechtigtem Client und dem Server hin und hergehen. Mehr als diese Daten kann der Server nicht nutzen, um die Verbindung des Clients zu validieren. Wenn ich Datenverkehr und alle Datenquellen einsehen kann, kann ich sie auch kopieren/emulieren.
So oft, wie dir das hier mehrere Leute beschrieben haben, scheinst du es aber nicht verstehen zu wollen -.-.

In Zeiten von JWTs quasi unmöglich, da man diese eben ausgibt, damit man keine DB anfragen muss, aber eben auch ein eklatantes Problem, was es zudem unmöglich macht JWTs zurückzuziehen. Und wenn man JWTs zurückziehbar macht, landet man prinzipiell wieder bei herkömmlichen Cookies, hat aber einzig die Komplexität ins Unermessliche gesteigert. Quasi ein Baumhaus aus Carbon hergestellt. Schönes Proof of Concept. Ist halt trotzdem dumm.

Ich kenne diese Wörter, die Sprache auch, nur in dieser Zusammenstellung ergibt das keinen Sinn..

das = worüber wir uns hier gerade unterhalten

Das ist das Problem.. Sessionhijacking durch Übernahme von Sessiontokens ist das was bei LTT stattgefunden hat.
Du schmeißt (ohne Problemanalyse) komische Lösungansätze rein und schmeißt zusätzlich CSRF und zuletzt SQL-Injections in den Ring. So richtig kann nachvollziehbar sind deine Post daher nicht, es ist zu viel Raterei dabei, wo du dich gedanklich befindest.

Wir reden hier nicht vom Zugangs-PC für atomare Sprengköpfe, sondern von Google-Konten.

Das Erstellen von zusätzlichen Konten bei Google ist vergleichsweise simpel.
Zugegeben, die Rechteverwaltung seitens Google ist nicht so prall. Im Zweifelsfall muss man etwas umständlich die Emails von den Accounts, die bei LTT Zugang auf die YT-Kanäle haben hart auf andere Konten umleiten und auf den entsprechenden Accounts löschen.[1]

[1] Vielleicht weiß jemand mehr, wie Google Rechteverwaltung funktioniert, wenn man da Professionell agiert.

CSRF geht ausschließlich über POST.

Also außer den Fällen, wo es das nicht tut..
https://owasp.org/www-community/attacks/csrf
Alles was danach von dir beschrieben wird, leidet unglaublich darunter, dass die Einleitung schlicht falsch ist. Vielleicht liegt es in der Kürze, oder am mangelnden Verständnis, aber so richtig ergibt das Nachfolgende selbst mit Wohlwollen nicht so richtig Sinn.

 

[Yuuri]

Welches Merkmal kann denn nicht zusammen mit der Session kopiert werden?

Gar keines. Aber darum gehts nicht. Es geht darum, dass eine Session nicht einfach so durch ein simples Kopieren der ID übernommen werden kann. Wenn der Client 1:1 nachgebaut/geklont wird, sieht das natürlich anders aus, ist aber deswegen auch nicht unmöglich. Dann wird mit einer Fehlermeldung quittiert oder einem erneuten Login sichergestellt, dass das auch plausibel ist.

Schon gar nicht um damit gezielt Accounts zu übernehmen.

Wer sagt was von gezielt? Ich spreche doch explizit von "Probieren" und wenn ich was hab, kann ich ja alle Daten löschen. Wenn der Admin drunter ist, umso besser. LTT wurde auch nicht "gezielt" ausgesucht. Genauso wie Krankenhäuser u.ä. nicht gezielt "Opfer einer Cyberattacke" sind. Der Spam wird millionenfach versendet und wer drauf rein fällt, hat halt Pech.

"Gezielt" kann man in den Mund nehmen, wenn man von Stuxnet spricht.

Sessionhandling verstanden?
[ ] Ja
[X] Nein

Anscheinend du nicht, was OWASP mit entsprechendem Absatz (/entsprechenden Absätzen) mitzuteilen versucht. Aber gut, wenn du demnächst im Weißen Haus ein Namensschild "Barack Obama" trägst, wirst du mit Sicherheit rein kommen. Nein, die Plausibilität infrage stellen ist nicht...

Ich kenne diese Wörter, die Sprache auch, nur in dieser Zusammenstellung ergibt das keinen Sinn..

Dann kann ich dir auch nicht helfen.

Problem: Wir haben ne Client-Server-Verbindung, der Client wurde kompromittiert.
Lösung: Härtet den Server!!!!!!!!

Lächerlicher gehts nicht? Niemand spricht vom Server. Ich spreche davon, dass die sensibelsten Daten halbwegs durch weitere Faktoren gehärtet werden sollen. 🤦‍♂️ Und das betrifft Server sowie Client, keine einzelne Partei. Und da der Server die Tokens für den Client vergibt, hat er da auch für etwas Sicherheit zu sorgen und sei es nur für die mögliche Erkennung (und ggf. Auslieferung einer Fehlermeldung) eines "gefakten" Requests.

SQL Injections haben nicht viel mit Sessionhijacking zu tun

Nein. Aber hier steht die Prämisse "Ja, die ID stimmt, ist der Client" im Raum und man ignoriert vollkommen jeglichen Kontext. Kann man nichts machen. 🤷‍♂️

Genauso könnte ich bei SQL-Injections auch sagen, "Ja, Robert'); DROP TABLE Students; -- ist ein gültiger Name". Was, Eingabedaten überhaupt irgendwie auf Plausibilität validieren? Warum? Kommt doch so vom Client, muss stimmen!

Das ist genau die Parallele zu SQL-Injections, für die ihr hier argumentiert. Ist halt so, kann man nichts machen. Versuchen? Ach, klappt sowieso nicht. Lassen wirs komplett sein.

Also außer den Fällen, wo es das nicht tut..

Ok, für dich nochmal explizit und vollkommen korrekt: CSRF funktioniert ausschließlich über POST, PUT, DELETE und PATCH. Hab ich ein HTTP Verb vergessen, was ggf. noch in nem RFC Draft steckt?

Wie gesagt: etwas, womit Aktionen ausgeführt werden. Ein Aufruf/Abruf/Besuchen einer Seite (GET, HEAD, OPTIONS, CONNECT, TRACE) ist keine Aktion. Ein Aufruf von /user/logout entspricht nicht der Aktion "logge mich aus", ergo sollte das keinem GET entsprechen und auch mittels CSRF gesichert sein.

Man kann auch alles auf die Waagschale legen...

Mal abgesehen davon, dass es relativ sinnfrei ist APIs mit CSRF zu sichern, einfach weil dort keine Cookies existieren. Cookies existieren ausschließlich im Browser und typische Requests sind dort GET und POST. PATCH, PUT, DELETE u.ä. gibts dort nicht, außer man kommuniziert direkt mit einer RESTish API. Sonst überall werden Proxys davor gesetzt und die API in ihrer Funktion für die Kommunikation mit dem Browser eingeschränkt. Ein typischer Consumer einer API ist jedenfalls nicht der Browser. Und selbst dann nutzt man eher weniger die Session ID im Cookie, sondern andere Authentifizierungsmethoden (dedizierte API Keys, App Passwords, SQRL, Passkey, ggf. OAuth oder wie man es sonst noch so nennen mag).

Mich hat Google schon mehrfach aus Sessions geschmissen, als ich Zugriff aus "komischen" IPbereichen haben wollte.

Ich erinnere mich gerade an einen Fall (JDownloader und Google Drive). Dort meldet man sich an, kopiert einfach den Session Token aus den Cookies und kann dann ganz simpel mit der Browser Session Daten im JDownloader laden. Ja... Natürlich... Einfach so... Ich war etwas verdutzt.

Einigen wir uns doch einfach auf "ist halt so gewachsen, kann man nichts machen".

Ihr meint, dass das nicht geht. OWASP hat entsprechende Guides dafür, die man eigentlich befolgen sollte, immerhin zu nem gewissen Teil und welche selbst die schäbigsten Shopsysteme überhaupt umgesetzt haben, die für jedwede Art von SQL-Injection und XSS anfällig waren (und wenn im Einsatz auch potentiell noch sind).

Noch ne Frage: Warum sollte ich am Client überhaupt das Serverzertifikat prüfen? Der kann doch mindestens genauso manipuliert sein. 🤷‍♂️

 

[DFFVB]

Hallo zusammen,

danke abermals für die erhellende Diskussion, für einen normalen User sehr hilfreich. Habe das gestern auch mal probiert einfach %APPDATA% in ne VM kopiert, und ich war überall sofort drinnen - sehr erschrekcen.

Könnten die Experten ggf. noch ein zwei Worte über OAuth (Outlook / Thundebird) verlieren? Man fragt sich natürlich, wie man das Risiko minimieren kann. Für CB, das Backforum oder meinen OnlyFans Account natürlich egal, aber meinen E-Mail Account würd eich schon gerne so nutzen, dass man ihn nicht direkt übernehmen kann, aber auch nicht zwingend jedes Mal ein PW eingeben (Passkeys ick hör Dir trapsen).

Besten Dank vorab - und frohe Ostern