{"id":410,"date":"2009-04-23T14:50:17","date_gmt":"2009-04-23T13:50:17","guid":{"rendered":"http:\/\/blog.adrianlang.de\/?p=410"},"modified":"2009-04-23T14:54:44","modified_gmt":"2009-04-23T13:54:44","slug":"oauth-20091-%e2%80%93-der-ernstfall","status":"publish","type":"post","link":"https:\/\/blog.adrianheine.de\/?p=410","title":{"rendered":"OAuth 2009.1 \u2013 Der Ernstfall?"},"content":{"rendered":"

Heute ist die erste \u201eSicherheitsl\u00fccke<\/a>\u201c in dem Protokoll OAuth<\/a> bekanntgeworden. Da OAuth auch die Grundlage f\u00fcr OpenMicroBlogging<\/a> und entsprechend wichtig f\u00fcr identi.ca<\/a>, Laconica<\/a> und mnw<\/a> ist, habe ich mich n\u00e4her mit dem Problem besch\u00e4ftigt.<\/p>\n

Wozu OAuth?<\/h3>\n

Ein Beispiel: Wir stellen uns eine Webanwendung \u201eimgPusher\u201c vor. Sie soll Benutzern beim Hochladen von Bildern in die Wikipedia helfen, in dem sie bsw. mehrere Bilder zusammen hochl\u00e4dt, die Beschreibung besonders einfach eingeben l\u00e4sst oder was auch immer. Zum Hochladen muss der Benutzer in der Wikipedia angemeldet sein \u2013 einerseits, weil er das Bild unter seinem Namen hochladen m\u00f6chte, andererseits, weil die Wikipedia kein anonymes Hochladen von Dateien erlaubt. Das klassische Vorgehen w\u00fcrde darin bestehen, dass der Benutzer seinen Namen und sein Passwort bei \u201eimgPusher\u201c hinterlegt, so dass sich \u201eimgPusher\u201c unter seinem Namen in der Wikipedia einloggen und die Dateien hochladen kann. Dieses Vorgehen stellt jedoch ein Sicherheitsproblem dar; der Benutzer muss einem wahrscheinlich unbekannten Programm sein Passwort anvertrauen, er kann nicht nachvollziehen, ob das Passwort nicht bsw. gespeichert und dem Betreiber der Anwendung zug\u00e4nglich gemacht wird.<\/p>\n

An dieser Stelle setzt OAuth an. Wenn die Wikipedia und \u201eimgPusher\u201c OAuth verwenden w\u00fcrden, m\u00fcsste der Benutzer sein Passwort nicht weitergeben. Stattdessen w\u00fcrde \u201eimgPusher\u201c den Benutzer nur nach seinem Benutzernamen fragen. Danach w\u00fcrde ein Request token generiert und der Benutzer auf eine Wikipedia-Seite weitergeleitet werden. Dort w\u00fcrde sichergestellt werden, dass der Benutzer gerade eingeloggt ist; danach w\u00fcrde Wikipedia ihn fragen, ob er \u201eimgPusher\u201c wirklich die Erlaubnis erteilen m\u00f6chte, Bilder unter seinem Namen hochzuladen. Wenn er diese Frage bejahen w\u00fcrde, w\u00fcrde der Benutzer zur\u00fcck zu \u201eimgPusher\u201c geleitet werden. Nun k\u00f6nnte \u201eimgPusher\u201c den Request token in einem Access token umwandeln und mit diesem unter dem angegebenen Benutzernamen Bilder hochladen, ohne dass der Benutzer das Passwort auf einer dritten Seite h\u00e4tte eingeben m\u00fcssen. (Leider unterst\u00fctzt Mediawiki OAuth noch nicht und dieses Beispiel ist rein fiktional.)<\/p>\n

Zusammengefasst: OAuth erm\u00f6glicht Benutzern, Drittanwendungen bestimmte Aktivit\u00e4ten mit ihrem Account zu erlauben. Dabei muss der Benutzer sein Passwort nicht rumgeben und kann \u2013 so der Hauptdienst es vorsieht \u2013 sogar genau festlegen, was die Drittanwendung darf und was nicht.<\/p>\n

Das Problem<\/h3>\n

Eran Hammer-Lahav hat die heute bekanntgewordene Sicherheitsl\u00fccke detailliert in seinem Blog beschrieben<\/a>. Es wird deutlich, dass kein technisches, sondern ein Design-Problem besteht. Eine kurze technische Beschreibung des Problems soweit ich es verstanden habe: Ein Benutzer A, der Angreifer, verwendet \u201eimgPusher\u201c aus dem obigen Beispiel. \u201eimgPusher\u201c verlangt eine Authorisierung und leitet zur Wikipedia weiter. Diese URL wird von A an Person B, das Opfer, weitergegeben \u2013 m\u00f6glich ist das bsw. durch einen Blogbeitrag, der eine Anwendung empfielt. B ist in der Wikipedia angemeldet oder wird jetzt dazu aufgefordert. Danach wird sie von der Wikipedia gefragt, ob sie der Anwendung \u201eimgPusher\u201c wirklich erlauben m\u00f6chte, Bilder unter ihrem Benutzernamen hochzuladen. B best\u00e4tigt dies und wird zur\u00fcck zu \u201eimgPusher\u201c gelenkt. An dieser Stelle kann A den vorher an B \u00fcbergebenen Request token in einen Access token umwandeln lassen und hat damit eine \u201eimgPusher\u201c-Sitzung, die einen g\u00fcltigen Access token f\u00fcr B\u2018s Wikipedia-Account hat. <\/p>\n

Einfluss auf OpenMicroBlogging<\/h3>\n

OAuth ist Grundlage f\u00fcr OMB. Alle OMB-Nachrichten sind auch OAuth-Nachrichten. Wenn ein Benutzer die Nachrichten einer anderen Person abonniert, durchl\u00e4uft er einen kompletten OAuth-Prozess. Dabei gibt er der anderen Person das Recht, auf die OAuth-Ressource \u201eNachricht versenden\u201c zuzugreifen. Ein konkretes Beispiel: Person A von Dienst X m\u00f6chte die Nachrichten von Person B vom Dienst Y empfangen. Sie gibt also die Adresse ihres Profils, abstrakt \u201ehttp:\/\/X\/A\u201c, auf dem Profil von B ein. Dienst Y leitet Person A auf den eigenen Server X weiter, wo sie gefragt wird, ob sie wirklich Person B vom Dienst Y abonnieren m\u00f6chte. Wenn sie best\u00e4tigt, erteilt X dem Dienst Y die Erlaubnis, auf die OAuth-Ressource \u201eNachricht versenden\u201c von Person A zuzugreifen.<\/p>\n

Die aufgedeckte Angriffsm\u00f6glichkeit stellt bei dieser Verwendung von OAuth keine Gefahr dar. Ein analoges Angriffs-Beispiel sieht wie folgt aus: Ein Benutzer C vom Dienst Y gibt Profil \u201ehttp:\/\/X\/A\u201c auf Y ein und erh\u00e4lt damit eine URL. Diese schiebt er X unter \u2013 hier wird bereits das erste Problem deutlich: OMB speichert in dieser URL, welcher Benutzer abonnieren m\u00f6chte. Daher muss der Angriff auf eine konkrete Person ausgerichtet sein. Hat X nun diese URL aufgerufen, kommt sie zu einer Seite, auf der Dienst X (ihr eigener) sie fragt, ob sie wirklich den Benutzer C abonnieren m\u00f6chte. Damit ist der Angriff gescheitert, denn X sieht, wen sie abonnieren \u2013 technisch gesprochen Zugriff auf ihre Ressourcen erlauben \u2013 soll. Aus meiner Sicht hat OAuth 2009.1 daher keinen Einfluss auf OpenMicroBlogging. <\/p>\n","protected":false},"excerpt":{"rendered":"

Heute ist die erste \u201eSicherheitsl\u00fccke\u201c in dem Protokoll OAuth bekanntgeworden. Da OAuth auch die Grundlage f\u00fcr OpenMicroBlogging und entsprechend wichtig f\u00fcr identi.ca, Laconica und mnw ist, habe ich mich n\u00e4her mit dem Problem besch\u00e4ftigt.<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[16,22],"tags":[24,132,128,224,127,126,173],"_links":{"self":[{"href":"https:\/\/blog.adrianheine.de\/index.php?rest_route=\/wp\/v2\/posts\/410"}],"collection":[{"href":"https:\/\/blog.adrianheine.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.adrianheine.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.adrianheine.de\/index.php?rest_route=\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.adrianheine.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=410"}],"version-history":[{"count":7,"href":"https:\/\/blog.adrianheine.de\/index.php?rest_route=\/wp\/v2\/posts\/410\/revisions"}],"predecessor-version":[{"id":417,"href":"https:\/\/blog.adrianheine.de\/index.php?rest_route=\/wp\/v2\/posts\/410\/revisions\/417"}],"wp:attachment":[{"href":"https:\/\/blog.adrianheine.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=410"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.adrianheine.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=410"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.adrianheine.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=410"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}