[NEWS] versteckte Umleitungssicherheitslücke in Websites mit OAuth und OpenID

dbarthel

Lounge-Member
Ende letzter Woche veröffentlichte ein Doktorand der Nanyang Technological University namens Wang Jing einen Bericht über eine Sicherheitslücke, die er „Covert Direct“ („versteckte Umleitung“) nannte.
Dabei handelt es sich um eine Sicherheitslücke, die Websites betrifft, die OAuth und OpenID zur Überprüfung der Identität nutzen.
[...]
Auf vielen Websites kommen OAuth und OpenID zur Identitätsüberprüfung zum Einsatz, wobei sich Nutzer mit den Zugangsdaten anderer großer Websites anmelden können.
[...]
Covert Direct stellt ein Problem bei den internen Sicherheitsvorkehrungen von Websites dar, die auf OAuth und OpenID bauen. [...] Eine offene Umleitung tritt auf, wenn eine Website einen Fehler im Aufbau aufweist, durch welchen Angreifer den Code ändern können, der Nutzer auf andere Websites weiterleitet. Diese Umleitungen werden oft von Hackern genutzt, um Zugangs-Tokens zu stehlen [...]

mehr Infos auf Versteckte Umleitungssicherheitslücke in Websites mit OAuth und OpenID | Emsisoft Blog
 
Zuletzt bearbeitet von einem Moderator:
Ich nutze in meinen Projekten nichts von dem Angesprochenen. Und als Benutzer weiss ich es vermutlich nicht, wo es benutzt wird, wäre mir auch egal, hab überall ein anderes Passwort.
 
Ich verwende es ebenfalls gar nicht - ich bin kein Freund von "zentralen Zugängen". Nämlich genau aus DEM Grund ... ^^
 
Und als Benutzer weiss ich es vermutlich nicht, wo es benutzt wird
Doch, das weißt du, da dort ja dann steht, dass man sich mit seinem Facebook-, Google-, was-auch-immer-Account anmelden kann und deswegen auch zu der jeweiligen Seite geleitet wird.
hab überall ein anderes Passwort.
Es geht dabei gar nicht um dein Passwort, das du vergeben hast. So ein Token ist wie ein Passwort für Programm, das auf deinen Account zugreifen will. Wenn jemand das hat, kannst du dein Passwort so oft ändern, wie du willst - das Token wird erst dann ungültig, wenn du es wiederufst.

"zentralen Zugängen".
Das ist gar nicht die Hauptidee von OAuth. Obwohl es dafür genutzt werden kann.
 
Doch, das weißt du, da dort ja dann steht, dass man sich mit seinem Facebook-, Google-, was-auch-immer-Account anmelden kann
Achso, darum dreht es sich. Nein, auch das nutze ich als User nicht. Hab ich noch nie gemacht, weil mir das immer unheimlich war, dass Anbieter so eng zusammenarbeiten, dass die selbe Authentifizierung funktionieren soll. Außerdem wollte ich nie, dass die Anbieter meine verschiedensten Benutzernamen auf mich als selbe Person zurückführen können. Ich mache lieber überall einen eigenen User und ein eigenes Passwort. Verknüpft ist da bisher nichts, zumindest nicht über mich. Was die da jetzt mit Canvas anstellen ist natürlich eine andere Kiste, da hab ich ja nur bedingt und nicht dediziert Einfluss drauf.
 
Die gemeinsame Authentifizierung ist, wie gesagt, gar nicht das Hauptfeld dafür.
Für manche Dienste muss man das machen, da es anders nicht funktioniert kann - außer du gibst dem Dienst deine Nutzername und Passwort. Stell' dir vor, du hast irgendeine Seite, die irgendwas Tolles mit deinem Facebook-Account machen kann (z.B. wenn dieses Forum dir keine Email senden würde, wenn ein neuer Beitrag da ist, sondern eine Facebooknachricht). Damit das funktioniert, muss diese Seite sich bei Facebook so Authentifizieren, dass Facebook weiß, dass du das zugelassen hast. Und genau dafür sind die Token da.
 
Im Grunde genommen ist Token-Diebstahl ja nichts anderes als Session-Hijacking bzw. Spoofing. Und da finde ich es Wahnsinn, wie viele User sich nicht der Gefahr in Hotspots - z.B. durch Droidsheep, was die Übernahme von Cookies enorm(!) leicht macht - bewusst sind...
 
Ist auf der einen Seite schlimmer, da die Token nicht ablaufen, und auf der anderen Seite weniger schlimm, da der Token (normalerweise) keinen Vollzugriff auf den Account zulässt und die Übertragung nur ein einziges Mal (beim Einrichten) über den Client des Nutzers stattfindet (wenn man keine sein clientseitige App hat).
 
Zurück
Oben