Oauthlib: Client_secret und code_verifier (PKCE) sollten sicher übertragen werden

Hallo @polamayster , du hast vollkommen recht.

Ich füge die Abschnitte von RFC hinzu, die angeben, wie es implementiert werden muss:

Abschnitt von OAuth2.0 RFC:

https://tools.ietf.org/html/rfc6749#section -2.3.1

2.3.1.  Client Password
   Clients in possession of a client password
   MAY use the HTTP Basic authentication scheme (..) 

   Alternatively, the authorization server
   MAY support including the client credentials in the request-body (..)

   The parameters can only be transmitted in the request-body and
   MUST NOT be included in the request URI.

Abschnitt von PKCE RFC:

https://tools.ietf.org/html/rfc7636#section -4.5

4.5.  Client Sends the Authorization Code and the Code Verifier to the
      Token Endpoint
    In addition to the parameters defined in the OAuth 2.0 Access
    Token Request (Section 4.1.3 of [RFC6749]), it sends the following parameter:

   code_verifier
      REQUIRED.  Code verifier

https://tools.ietf.org/html/rfc6749#section -4.1.3

4.1.3.  Access Token Request

   The client makes a request to the token endpoint by sending the
   following parameters (..) in the HTTP request entity-body:

Ich habe also keine Zweifel an der Relevanz des Themas. Alle PRs sind willkommen!

Ich bin daran interessiert, das zu übernehmen. Werde in Kürze eine Pull-Anfrage stellen.

Sollte dieses Verhalten nur für Anforderungen erzwungen werden, die Anmeldeinformationen erwarten, oder für alle Anforderungen im Allgemeinen?

Nach meinem Verständnis hat die oauthlib.common.Request Klasse eine __getattr__ Methode und ein _params Wörterbuch (aktualisiert aus der Abfragezeichenfolge und den Textkörperparametern) und jede Anforderung , die versucht, auf client_secret zuzugreifen/diese code_verifier sollten nur im Hauptteil und/oder in den Kopfzeilen suchen (vielleicht wäre eine separate Eigenschaft für die Suche nach sensiblen Daten sinnvoll)

Ich sehe, ich werde heute eine PR dafür einreichen

Am Sa, 20.04.2019, 12:38 Uhr schrieb Bohdan < [email protected] :

Nach meinem Verständnis hat die Klasse oauthlib.common.Request eine __getattr__
-Methode und _params-Wörterbuch (aktualisiert aus Abfragezeichenfolge und Hauptteil)
Parameter) und jede Anfrage , die versucht, auf client_secret zuzugreifen/ es abzurufen oder
code_verifier sollte nur im Body und/oder Header nachschlagen (vielleicht mit
separate Eigenschaft für die Suche nach sensiblen Daten wäre sinnvoll)

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/oauthlib/oauthlib/issues/666#issuecomment-485157051 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ABKEVQNFJUFGDB5X24JBOJDPRNWKBANCNFSM4HHD7NNQ
.

Nach meinem Verständnis hat die oauthlib.common.Request Klasse eine __getattr__ Methode und ein _params Wörterbuch (aktualisiert aus der Abfragezeichenfolge und den Textkörperparametern) und jede Anforderung , die versucht, auf client_secret zuzugreifen/diese code_verifier sollten nur im Hauptteil und/oder in den Kopfzeilen suchen (vielleicht wäre eine separate Eigenschaft für die Suche nach sensiblen Daten sinnvoll)

Die Überprüfungen sollten also zum Zeitpunkt des Attributzugriffs erfolgen, anstatt wenn die URL festgelegt ist? Wenn Anforderungsattribute nur einmal bei der Initialisierung gesetzt werden, können wir die Prüfungen direkt dann statt bei jedem Attributzugriff durchführen. Lassen Sie es mich wissen, wenn Sie der Meinung sind, dass wir die Prüfungen bei jedem Attributzugriff weiterhin durchführen sollten.

Mir ist klar, dass dieses Problem größer ist und für den gesamten /token Endpunkt gilt. Dieser Endpunkt DARF KEINE Parameter in der URL akzeptieren. Das darf NICHT erlaubt sein.

Ich denke, der Endpunkt der Introspektion ist ebenfalls geeignet. IIRC, nach
HTTP-Spezifikationen müssen POST-Anforderungen Abfrageparameter immer ignorieren. Ob
wir erzwingen das, wir lösen automatisch alle Probleme ohne Auswirkungen
gültige Anwendungsfälle. Ich bin mir nicht sicher, wie sich andere HTTP-Verben verhalten sollen
aber bei POST bin ich mir ziemlich sicher. Kann mir jemand bestätigen ob das richtig ist
Richtung zu gehen?

>

Alle Abfrageparameter für alle POST zu verweigern ist eine nette Abkürzung, die attraktiv ist! Ich mache mir jedoch Sorgen um den ResourceEndpoint der oauthlib und die Tatsache, dass einige Benutzer der URL immer noch Abfrageargumente hinzufügen können (obwohl dies nicht empfohlen wird, ist dies technisch immer noch möglich).

Können Sie Ihre Bedenken bezüglich des Ressourcenendpunkts etwas näher erläutern?

POST-Anfragen werden meiner Meinung nach entweder über Formulareinreichungen oder api . gestellt
Aufrufe (Schreiben von explizitem Code). Ich verstehe nicht, warum jemand teilweise hinzufügen sollte
Daten als Abfrageparameter und teilweise als Postdaten. Tatsächlich ist es einfacher,
verpflichten sich vollständig zu entweder.
Tatsächlich ist es viel einfacher, wenn Sie eine Bibliothek verwenden, um Anfragen zu stellen
füge alles als Post-Body hinzu, anstatt die Dinge aufzuteilen.

Benutzer, die dem POST Abfrageparameter hinzufügen, wenn ein erklärender Fehler angezeigt wird,
sollte sich schnell selbst korrigieren können.

Oder vielleicht können wir einen Mixin oder Dekorateur erstellen, der, wenn er angewendet wird, aufsteigen würde
Fehler für POST-Anfragen mit Abfrageparametern.

Hier ist eine andere mögliche Lösung dafür. Für die Endpunkte ( AuthorizationEndpoint , IntrospectEndpoint , RevocationEndpoint ); Wenn die Anfragemethode POST , können wir die Prüfung auf Abfrageparameter in ihren jeweiligen Anfragevalidierungsmethoden hinzufügen. Für ( TokenEndpoint , MetadataEndpoint ) können wir die Methoden zum Einchecken von Antworten hinzufügen.
ODER wir können der Konsistenz halber den Prüfmechanismus innerhalb der Antwortgenerierungsmethode von allen hinzufügen. Klingt das nach einer guten Idee?

Ich denke, es ist vorzuziehen, die Validierungsmethoden _request_ zu verwenden.
Zu wissen, dass POST nur für TokenEndpoint , IntrospectEndpoint und RevocationEndpoint . Andere sind GET : AuthorizationEndpoint , MetadataEndpoint .

Ein allgemeiner Kommentar jedoch: Sollten wir uns auf sensible Felder konzentrieren (z. B. eine Blacklist führen) oder sollten wir alle OAuth2-Parameter verweigern (wir möchten, dass NONE in der Abfrage-URI enthalten ist, richtig?)

Idealerweise möchte ich NONE in der Abfrage-URI. Ich habe mich für eine schwarze Liste entschieden, weil ich es nicht war
sicher, ob ich einige bestehende Anwendungsfälle brechen könnte. Nicht nur kein OAuth2
Parameter erlaubt, aber überhaupt keine Abfrageparameter.

>

Wenn Sie die Prüfungen von Request auf die Endpunkte verschieben, sehe ich keine Probleme beim Deaktivieren aller Abfrageparameter für diese Endpunkte!

In Ordnung, dann werde ich alle Abfrageparameter auf genau diesen Endpunkten deaktivieren. Und
Wir beschränken auch die http-Methode auf POST, richtig?

Behoben in https://github.com/oauthlib/oauthlib/pull/667

Obwohl ich die Gründe für diese Änderung verstehe, scheint dies eine entscheidende Änderung für Clients zu sein, die client_secret als Abfrageparameter senden. Ich hätte Abwärtskompatibilität oder einen größeren Versionssprung erwartet. Ist dieses Verhalten beabsichtigt?

Wir verwenden derzeit django-oauth-toolkit und Kunden senden username , password , client_secret , client_id und grant_type als Abfrage Parameter. Wenn sie dazu wechseln, alles als Parameter POST zu senden, erhalten sie den Fehler unsupported_grant_type .

Die Unterstützung von Abfragen für POST ist eher ein Nebeneffekt als das gewünschte Verhalten. Ich verstehe, dass es Ihren Client kaputt macht, daher würde ich vorschlagen, auf <3.1 . zu verweisen
Denken Sie auch daran, so schnell wie möglich ein Upgrade durchzuführen, da dies Sicherheitsbedenken beinhaltet (Geheimnisse werden in Protokollen, im Proxy, über mehrere unbeabsichtigte Standorte hinweg angezeigt).