Oauthlib: Client_secret dan code_verifier (PKCE) harus ditransmisikan dengan aman

Hai @polamayster , Anda benar sekali.

Saya menambahkan bagian RFC yang menentukan bagaimana itu harus diterapkan:

Bagian dari 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.

Bagian 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:

Jadi saya tidak ragu tentang relevansi masalah ini. Setiap PR dipersilakan!

Saya akan tertarik untuk mengambil ini. Akan segera mengajukan permintaan tarik.

Haruskah perilaku ini diterapkan hanya untuk permintaan yang mengharapkan kredensial atau permintaan apa pun secara umum?

Untuk pemahaman saya oauthlib.common.Request kelas memiliki __getattr__ metode dan _params kamus (diperbarui dari string kueri dan parameter tubuh) dan setiap permintaan yang mencoba mengakses/mendapatkan client_secret atau code_verifier harus dicari hanya di badan dan/atau header (mungkin memiliki properti terpisah untuk pencarian data sensitif akan masuk akal)

Begitu, saya akan mengirimkan PR untuk itu hari ini

Pada Sabtu, 20 April 2019, 12:38 Bohdan < [email protected] menulis:

Untuk pemahaman saya oauthlib.common.Request kelas memiliki __getattr__
metode dan kamus _params (diperbarui dari string kueri dan badan
parameter) dan permintaan apa pun yang mencoba mengakses/mendapatkan client_secret atau
code_verifier seharusnya hanya mencari di badan dan/atau header (mungkin memiliki
properti terpisah untuk pencarian data sensitif akan masuk akal)

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/oauthlib/oauthlib/issues/666#issuecomment-485157051 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ABKEVQNFJUFGDB5X24JBOJDPRNWKBANCNFSM4HHD7NNQ
.

Untuk pemahaman saya oauthlib.common.Request kelas memiliki __getattr__ metode dan _params kamus (diperbarui dari string kueri dan parameter tubuh) dan setiap permintaan yang mencoba mengakses/mendapatkan client_secret atau code_verifier harus dicari hanya di badan dan/atau header (mungkin memiliki properti terpisah untuk pencarian data sensitif akan masuk akal)

Jadi pemeriksaan harus dilakukan pada waktu akses atribut alih-alih ketika url disetel? Jika atribut permintaan ditetapkan hanya sekali pada inisialisasi, kita dapat melakukan pemeriksaan saat itu juga, bukan pada setiap akses atribut. Beri tahu saya jika menurut Anda kami masih harus melakukan pemeriksaan di setiap akses atribut.

Saya menyadari masalah ini lebih besar dan berlaku untuk seluruh titik akhir /token . Titik akhir ini TIDAK HARUS menerima parameter apa pun di URL. Itu TIDAK HARUS diizinkan.

Saya pikir titik akhir introspeksi juga memenuhi syarat. IIRC, menurut
Spesifikasi HTTP, permintaan POST harus selalu mengabaikan parameter kueri. Jika
kami menegakkan itu, kami secara otomatis menyelesaikan semua masalah tanpa mempengaruhi
kasus penggunaan yang valid. Saya tidak yakin bagaimana kata kerja HTTP lainnya seharusnya berperilaku
tapi saya cukup yakin pada POST satu. Adakah yang bisa mengkonfirmasi jika itu benar?
arah yang harus dituju?

>

Menolak semua parameter kueri untuk semua POST adalah jalan pintas yang bagus dan menarik! Namun saya khawatir tentang ResourceEndpoint oauthlib dan fakta bahwa beberapa pengguna masih dapat menambahkan argumen kueri ke URL (meskipun tidak disarankan, itu masih memungkinkan secara teknis).

Bisakah Anda menjelaskan lebih lanjut tentang masalah Anda dengan titik akhir sumber daya?

Cara saya melihatnya, permintaan POST dibuat baik melalui pengiriman formulir atau api
panggilan (menulis kode eksplisit). Saya tidak mengerti mengapa seseorang menambahkan sebagian
data sebagai parameter kueri dan parsial sebagai data pos. Bahkan, lebih mudah untuk
berkomitmen sepenuhnya untuk keduanya.
Sebenarnya jika Anda menggunakan perpustakaan untuk membuat permintaan, jauh lebih mudah untuk
tambahkan semuanya sebagai badan pos alih-alih membaginya.

Pengguna menambahkan parameter kueri ke POST jika disajikan dengan kesalahan penjelasan,
harus bisa mengoreksi diri dengan cepat.

Atau mungkin kita bisa membuat mixin atau dekorator yang ketika diaplikasikan akan menaikkan
kesalahan untuk permintaan POST dengan parameter kueri.

Inilah solusi lain yang mungkin untuk itu. Untuk titik akhir ( AuthorizationEndpoint , IntrospectEndpoint , RevocationEndpoint ); Jika metode permintaan adalah POST kita dapat menambahkan pemeriksaan parameter kueri dalam metode validasi permintaan masing-masing. Untuk ( TokenEndpoint , MetadataEndpoint ) kita dapat menambahkan metode pembuatan respons check-in.
ATAU kita dapat menambahkan mekanisme pemeriksaan di dalam metode pembangkitan respons dari semuanya, demi konsistensi. Apakah itu terdengar seperti ide yang bagus?

Saya pikir lebih baik menggunakan metode validasi _request_.
Mengetahui bahwa POST hanya untuk TokenEndpoint , IntrospectEndpoint dan RevocationEndpoint . Lainnya adalah GET : AuthorizationEndpoint , MetadataEndpoint .

Namun komentar umum: haruskah kita fokus pada bidang sensitif (misalnya mempertahankan daftar hitam) atau haruskah kita menolak semua parameter OAuth2 (kita ingin NONE berada di URI Kueri, bukan?)

Idealnya saya ingin NONE di Query URI. Saya pergi untuk daftar hitam karena saya tidak
yakin apakah saya mungkin melanggar beberapa kasus penggunaan yang ada. Tidak hanya tidak ada OAuth2
parameter diizinkan, tetapi tidak ada parameter kueri yang diizinkan sama sekali.

>

Jika Anda memindahkan pemeriksaan dari Permintaan ke Titik Akhir, saya tidak melihat masalah dalam menonaktifkan semua parameter kueri untuk Titik Akhir tersebut!

Baiklah, saya akan menonaktifkan semua parameter kueri pada titik akhir yang tepat itu. Dan
kami juga membatasi metode http untuk POST, benar?

Diperbaiki di https://github.com/oauthlib/oauthlib/pull/667

Meskipun saya memahami alasan perubahan ini, ini tampaknya merupakan perubahan yang melanggar untuk klien yang mengirim client_secret sebagai parameter kueri. Saya akan mengharapkan kompatibilitas mundur atau benjolan versi utama. Apakah perilaku ini dimaksudkan?

Kami saat ini menggunakan Django-oauth-toolkit dan klien mengirim username , password , client_secret , client_id dan grant_type sebagai kueri parameter. Jika mereka beralih untuk mengirim semuanya sebagai parameter POST , mereka mendapatkan kesalahan unsupported_grant_type .

Dukungan kueri untuk POST lebih merupakan efek samping daripada perilaku yang diinginkan. Saya mengerti itu merusak klien Anda, jadi saya sarankan untuk menunjukkan dengan tepat ke <3.1
Juga, harap pertimbangkan untuk memutakhirkan secepatnya karena ini melibatkan masalah keamanan (rahasia ditampilkan di log, di proxy, di beberapa lokasi yang tidak diinginkan).