security - Clientgeheimnis in OAuth 2.0




google-api oauth-2.0 (4)

Ich hatte die gleiche Frage wie die Frage 1 hier und habe kürzlich selbst recherchiert, und meine Schlussfolgerung ist, dass es in Ordnung ist, "Kundengeheimnis" nicht geheim zu halten. Der Typ der Clients, die die Vertraulichkeit des Clientgeheimnisses nicht wahren, wird in der OAuth2-Spezifikation als "öffentlicher Client" bezeichnet. Die Möglichkeit, dass jemand böswillig in der Lage ist, Autorisierungscode zu erhalten und dann auf Token zuzugreifen, wird durch die folgenden Fakten verhindert.

1. Der Client muss den Autorisierungscode direkt vom Benutzer erhalten, nicht vom Dienst

Selbst wenn der Benutzer den Dienst angibt, dem er den Client vertraut, kann der Client keinen Autorisierungscode von dem Dienst erhalten, indem er lediglich die Client-ID und das Client-Geheimnis anzeigt. Stattdessen muss der Client den Autorisierungscode direkt vom Benutzer erhalten. (Dies geschieht normalerweise durch URL-Umleitung, über die ich später sprechen werde.) Für den bösartigen Client reicht es also nicht aus, die vom Benutzer vertrauenswürdige Client-ID / geheime Adresse zu kennen. Es muss irgendwie Benutzer einbeziehen oder vortäuschen, um ihm den Autorisierungscode zu geben, der härter sein sollte, als nur Klient ID / Geheimnis zu kennen.

2. Die Weiterleitungs-URL ist mit der Client-ID / secret registriert

Angenommen, der bösartige Client hat es irgendwie geschafft, den Benutzer zu involvieren und ihn auf die Schaltfläche "Autorisieren Sie diese App" auf der Serviceseite zu klicken. Dadurch wird die URL-Weiterleitungsantwort vom Dienst an den Browser des Benutzers mit dem Autorisierungscode ausgelöst. Dann wird der Autorisierungscode vom Browser des Benutzers an die Weiterleitungs-URL gesendet, und der Client sollte an der Weiterleitungs-URL abhören, um den Autorisierungscode zu erhalten. (Die Umleitungs-URL kann auch localhost sein, und ich dachte, dass dies ein typischer Weg ist, dass ein "öffentlicher Client" Autorisierungscode erhält.) Da diese Weiterleitungs-URL beim Dienst mit der Client-ID / secret registriert ist, tut dies der böswillige Client nicht habe eine Möglichkeit zu steuern, wo der Autorisierungscode angegeben wird. Dies bedeutet, dass der böswillige Client mit Ihrer Client-ID / Secret ein anderes Hindernis hat, um den Autorisierungscode des Benutzers zu erhalten.

Um Google Drive API zu verwenden, muss ich mit der Authentifizierung mit OAuth2.0 spielen. Und ich habe ein paar Fragen dazu.

  1. Client ID und Client Secret werden verwendet, um zu identifizieren, was meine App ist. Sie müssen jedoch fest codiert sein, wenn es sich um eine Client-Anwendung handelt. So kann jeder meine App dekompilieren und aus dem Quellcode extrahieren. Bedeutet es, dass eine schlechte App sich als gute App ausgeben kann, indem sie die Client-ID und das Geheimnis der guten App verwendet? Der Benutzer würde also einen Bildschirm anzeigen, der nach einer guten App fragt, obwohl er tatsächlich von einer schlechten App gefragt wird? Wenn ja, was soll ich tun? Oder sollte ich mir eigentlich keine Sorgen machen?

  2. In der mobilen Anwendung können wir eine Webansicht in unsere App einbetten. Und es ist einfach, das Passwortfeld in der Webansicht zu extrahieren, da die App, die um Erlaubnis bittet, tatsächlich ein "Browser" ist. OAuth in der mobilen Anwendung hat also nicht den Vorteil, dass die Clientanwendung nicht auf die Anmeldeinformationen des Dienstanbieters zugreifen kann?


Ich fing an, einen Kommentar zu deiner Frage zu schreiben, aber dann fand ich heraus, dass es zu viel zu sagen gibt. Hier sind meine Ansichten zu dem Thema in der Antwort.

  1. Ja, es gibt eine echte Möglichkeit dafür und es gab einige Exploits, die darauf basieren. Vorschlag ist nicht, die App in Ihrer App geheim zu halten. Es gibt sogar einen Teil in der Spezifikation, dass verteilte Apps dieses Token nicht verwenden sollten. Jetzt könnten Sie fragen, aber XYZ benötigt es, um zu arbeiten. In diesem Fall implementieren sie die Spezifikation nicht ordnungsgemäß und Sie sollten A nicht verwenden (nicht wahrscheinlich) oder B versuchen, das Token mithilfe einiger verschleiernder Methoden zu sichern, damit es schwieriger wird, Ihren Server als Proxy zu finden oder zu verwenden.

    Zum Beispiel gab es ein paar Bugs in der Facebook-Bibliothek für Android, wo Token zu Logs ausgelaufen sind, du kannst hier mehr darüber erfahren http://attack-secure.com/all-your-facebook-access-tokens-are-belong-to-us und hier https://www.youtube.com/watch?v=twyL7Uxe6sk . Alles in allem seien Sie besonders vorsichtig mit Ihrer Verwendung von Bibliotheken von Drittanbietern (gesunder Menschenverstand eigentlich, aber wenn Token Hijacking ist Ihr großes Anliegen hinzufügen ein weiteres Extra zu vorsichtig).

  2. Ich habe schon seit geraumer Zeit über den Punkt 2 geschimpft. Ich habe sogar einige Workarounds in meinen Apps durchgeführt, um die Zustimmungsseiten zu ändern (z. B. Zoom und Design an die App anpassen), aber nichts hinderte mich daran, Werte aus Feldern innerhalb der Webansicht mit Benutzernamen und Passwort zu lesen. Daher stimme ich deinem zweiten Punkt vollkommen zu und finde einen großen "Bug" in OAuth spec. Punkt zu sein "App bekommt nicht Zugriff auf Benutzer Anmeldeinformationen" in der Spezifikation ist nur ein Traum und gibt Benutzern ein falsches Gefühl der Sicherheit ... Auch ich denke, Menschen sind in der Regel Verdacht, wenn App fragt sie für ihre Facebook, Twitter, Dropbox oder andere Anmeldeinformationen. Ich bezweifle, dass viele gewöhnliche Leute OAuth-Spezifikationen lesen und sagen "Jetzt bin ich sicher", sondern benutze den gesunden Menschenverstand und benutze im Allgemeinen keine Apps, denen sie nicht vertrauen.







security oauth google-api oauth-2.0