Kerentanan Otentikasi OAuth 2.0

Saat menjelajahi web, Anda hampir pasti akan menemukan situs tempat Anda dapat masuk menggunakan akun media sosial Anda. Fitur ini mungkin dibuat menggunakan kerangka kerja OAuth 2.0 yang populer. OAuth 2.0 sangat umum dan sangat menarik bagi penyerang karena pada dasarnya rawan kesalahan. Ini dapat menyebabkan banyak kerentanan yang memungkinkan penyerang memperoleh data pengguna yang sensitif dan sepenuhnya mengabaikan otentikasi.

Bagian ini menjelaskan cara mengidentifikasi dan mengeksploitasi beberapa kerentanan utama yang ditemukan dalam mekanisme autentikasi OAuth 2.0. Jangan khawatir jika Anda tidak terlalu paham dengan autentikasi OAuth. Ada banyak informasi latar belakang untuk membantu Anda memahami konsep-konsep kunci yang Anda butuhkan. Ini juga menjelaskan beberapa kerentanan dalam ekstensi OpenID Connect OAuth. Terakhir, kami telah menyertakan beberapa panduan tentang cara melindungi aplikasi Anda dari jenis serangan ini.

LAB Jika Anda sudah terbiasa dengan konsep dasar di balik kerentanan OAuth dan ingin berlatih mengeksploitasinya dengan target yang realistis dan sengaja dibuat rentan, ikuti tautan di bawah ke semua lab tentang topik ini. Anda dapat mengaksesnya.
Lihat semua lab OAuth

Apa itu OAuth?

OAuth adalah kerangka kerja otorisasi yang umum digunakan yang memungkinkan situs web dan aplikasi web meminta akses terbatas ke akun pengguna di aplikasi lain. Yang penting, OAuth memungkinkan pengguna untuk memberikan akses ini tanpa memperlihatkan kredensial login mereka ke aplikasi yang meminta. Ini berarti pengguna dapat menyempurnakan data yang mereka bagikan tanpa harus memberikan kontrol penuh atas akun mereka kepada pihak ketiga.

Proses OAuth dasar banyak digunakan untuk mengintegrasikan fitur pihak ketiga yang memerlukan akses ke data tertentu dari akun pengguna. Misalnya, aplikasi mungkin dapat menggunakan OAuth untuk meminta akses ke daftar kontak email dan menyarankan pengguna untuk terhubung. Namun, ia menggunakan mekanisme yang sama untuk menyediakan layanan otentikasi pihak ketiga yang memungkinkan pengguna untuk masuk dengan akun yang dimiliki oleh situs web lain.

Catatan
OAuth 2.0 adalah standar saat ini, tetapi beberapa situs web terus menggunakan versi lama 1a. OAuth 2.0 dibuat dari awal, bukan dikembangkan langsung dari OAuth 1.0. Akibatnya, keduanya sangat berbeda. Perhatikan bahwa istilah "OAuth" hanya mengacu pada OAuth 2.0 di seluruh materi ini.

Bagaimana cara kerja OAuth 2.0?

OAuth 2.0 awalnya dikembangkan sebagai cara untuk berbagi akses ke data tertentu antar aplikasi. Ia bekerja dengan mendefinisikan serangkaian interaksi antara tiga pihak yang berbeda: aplikasi client, pemilik sumber daya, dan penyedia layanan OAuth.

Aplikasi client - Situs web atau aplikasi web tempat Anda ingin mengakses data Anda.
Resource Owner - Pengguna yang aplikasi clientnya ingin mengakses data.
Penyedia Layanan OAuth - Situs web atau aplikasi yang mengontrol data pengguna dan akses ke data tersebut. Mereka mendukung OAuth dengan menyediakan API untuk berinteraksi dengan server otorisasi dan server sumber daya.

Ada banyak cara untuk mengimplementasikan proses OAuth yang sebenarnya. Ini disebut "flow" atau "grant types" OAuth. Topik ini berfokus pada grant types "kode otentikasi" dan "implisit". Ini jauh lebih umum. Secara garis besar, kedua grant types tersebut meliputi langkah-langkah sebagai berikut:

Aplikasi client meminta akses ke subset data pengguna dan menentukan jenis otorisasi dan jenis akses yang akan digunakan.
Pengguna diminta untuk masuk ke layanan OAuth dan secara eksplisit menyetujui akses yang diminta.
Aplikasi client menerima token akses unik yang membuktikan bahwa pengguna memiliki izin untuk mengakses data yang diminta. Bagaimana hal ini dilakukan sangat tergantung pada grant types.
Aplikasi client menggunakan token akses ini untuk membuat panggilan API guna mengambil data yang relevan dari server sumber daya.

Sebelum mempelajari bagaimana OAuth digunakan untuk autentikasi, penting untuk memahami dasar-dasar proses OAuth dasar ini. Jika Anda belum pernah menggunakan OAuth sama sekali, ada baiknya Anda membiasakan diri dengan detail kedua grant types yang dijelaskan di bawah ini. membaca lebih lanjut.

Otentikasi OAuth

Meskipun awalnya tidak dimaksudkan untuk tujuan ini, OAuth juga telah berkembang menjadi sarana untuk mengautentikasi pengguna. Misalnya, Anda mungkin akrab dengan opsi yang ditawarkan banyak situs web untuk masuk menggunakan akun media sosial Anda yang ada alih-alih mendaftar ke situs web yang dimaksud. Setiap kali Anda melihat opsi ini, opsi ini mungkin dibuat di OAuth 2.0.

Untuk mekanisme autentikasi OAuth, alur dasar OAuth hampir sama. Perbedaan utama adalah bagaimana aplikasi client menggunakan data yang diterima. Dari perspektif pengguna akhir, hasil autentikasi OAuth secara umum mirip dengan sistem masuk tunggal (SSO) berbasis SAML. Artikel ini hanya akan fokus pada kerentanan dalam kasus penggunaan seperti SSO ini. Otentikasi OAuth biasanya diterapkan sebagai berikut:

Pengguna memilih opsi untuk masuk dengan akun media sosial mereka. Aplikasi client kemudian menggunakan layanan OAuth situs media sosial untuk meminta akses ke data yang dapat digunakan untuk mengidentifikasi pengguna. Ini bisa berupa, misalnya, alamat email yang terdaftar di akun Anda.
Setelah menerima token akses, aplikasi client meminta data ini dari server sumber daya (biasanya titik akhir khusus /userinfo).
Setelah menerima data, aplikasi client mencatat pengguna menggunakan data tersebut alih-alih nama pengguna. Token akses yang diterima dari server otentikasi sering digunakan sebagai pengganti kata sandi tradisional.

Di lab berikutnya Anda dapat melihat contoh sederhana tentang tampilannya. Saat melakukan proxy lalu lintas melalui Burp, Anda cukup menyelesaikan opsi Masuk dengan Media Sosial untuk melihat serangkaian interaksi OAuth dalam riwayat proxy Anda. Anda dapat masuk menggunakan kredensial Wiener:peter. Perhatikan bahwa implementasi ini sengaja dibuat rentan. Saya akan menunjukkan cara memanfaatkan ini nanti.

LAB Autentikasi bypass menggunakan OAuth implicit flow

Bagaimana kerentanan otentikasi OAuth terjadi?

Kerentanan otentikasi OAuth sebagian disebabkan oleh spesifikasi OAuth yang relatif ambigu dan fleksibilitas desain. Ada beberapa komponen yang diperlukan untuk fungsionalitas dasar setiap grant types, tetapi sebagian besar implementasi sepenuhnya opsional. Ini mencakup banyak pengaturan konfigurasi yang diperlukan untuk menjaga keamanan data Anda. Singkatnya, ada banyak peluang bagi kebiasaan buruk untuk masuk.

Salah satu masalah penting lainnya dengan OAuth adalah kurangnya fitur keamanan bawaan. Keamanan hampir seluruhnya bergantung pada pengembang yang menggunakan kombinasi opsi konfigurasi yang tepat dan menerapkan langkah-langkah keamanan tambahan mereka sendiri seperti validasi input yang kuat. Karena Anda mungkin berkumpul, ada banyak hal yang harus diperhatikan, dan jika Anda baru mengenal OAuth, ini mudah untuk membuat kesalahan.

Bergantung pada grant types, data sensitif juga dikirim melalui browser, memberikan berbagai peluang bagi penyerang untuk mencegatnya.

Identifikasi otentikasi OAuth

Mengenali bahwa aplikasi Anda menggunakan autentikasi OAuth relatif mudah. Jika Anda mendapatkan opsi untuk masuk menggunakan akun Anda dari situs web lain, ini merupakan indikasi kuat bahwa OAuth sedang digunakan.

Cara paling andal untuk mengidentifikasi autentikasi OAuth adalah dengan lalu lintas proxy melalui Burp dan melihat pesan HTTP yang sesuai saat menggunakan opsi masuk ini. Terlepas dari jenis pemberian OAuth yang digunakan, permintaan pertama untuk alur akan selalu berupa permintaan ke titik akhir/otorisasi yang berisi beberapa parameter kueri yang digunakan secara eksklusif untuk OAuth. Berikan perhatian khusus pada parameter client_id, redirect_uri, dan response_type. Misalnya, permintaan persetujuan biasanya terlihat seperti ini:

GET /authorization?client_id=12345&redirect_uri=https://client-app.com/callback&response_type=token&scope=openid%20profile&state=ae13d489bd00e3c24 HTTP/1.1
Host: oauth-authorization-server.com

pengintaian

Dengan melakukan penyesuaian dasar pada layanan OAuth yang digunakan, Anda dapat menunjukkan arah yang benar dalam mengidentifikasi kerentanan.

Tak perlu dikatakan, kita perlu menyelidiki berbagai interaksi HTTP yang membentuk flow OAuth. Untuk perhatian Anda nanti, saya akan membahas beberapa hal khusus. Jika Anda menggunakan layanan OAuth eksternal, Anda harus dapat mengidentifikasi penyedia tertentu dari nama host yang Anda kirimi permintaan otorisasi. Karena layanan ini menyediakan API publik, dokumentasi terperinci sering kali tersedia yang menyediakan semua jenis informasi berguna, seperti nama pasti titik akhir dan opsi konfigurasi yang digunakan.

Setelah Anda mengetahui nama host dari server otorisasi, selalu coba kirim permintaan GET ke titik akhir standar berikutnya.

/.well-known/oauth-authorization-server
/.well-known/openid-configuration

Mereka sering mengembalikan file konfigurasi JSON yang berisi informasi penting seperti detail fitur tambahan yang mungkin didukung. Ini mungkin memberi Anda petunjuk tentang permukaan serangan yang lebih luas dan fitur yang didukung yang mungkin tidak didokumentasikan.

Memanfaatkan Kerentanan Otentikasi OAuth

Kerentanan dapat terjadi dalam penerapan OAuth aplikasi client dan dalam konfigurasi layanan OAuth itu sendiri. Bagian ini menunjukkan cara mengeksploitasi beberapa kerentanan paling umum di kedua konteks ini.

Kerentanan aplikasi client

Kerentanan layanan OAuth

Kerentanan Aplikasi client OAuth

Aplikasi client sering kali menggunakan layanan OAuth yang bereputasi baik dan tahan pertempuran yang terlindungi dengan baik dari eksploitasi yang terkenal. Namun, aspek unik dari implementasi bisa jadi kurang aman.

Seperti disebutkan sebelumnya, spesifikasi OAuth didefinisikan secara relatif longgar. Hal ini terutama berlaku untuk implementasi aplikasi client. Ada banyak bagian yang bergerak dalam alur OAuth, dan setiap jenis pemberian memiliki banyak parameter opsional dan pengaturan konfigurasi. Dengan kata lain, ada kemungkinan salah konfigurasi.

Implementasi yang tidak tepat dari grant types implisit

Jenis izin implisit terutama direkomendasikan untuk aplikasi satu halaman karena risiko yang ditimbulkan dengan mengirimkan token akses melalui browser. Namun, karena relatif sederhana, sering digunakan dalam aplikasi web client-server tradisional.

Dalam alur ini, token akses dikirim dari layanan OAuth melalui browser pengguna sebagai fragmen URL ke aplikasi client. Aplikasi client kemudian menggunakan JavaScript untuk mengakses token. Masalahnya adalah jika aplikasi ingin mempertahankan sesi setelah pengguna menutup halaman, data pengguna saat ini (biasanya ID pengguna dan token akses) perlu disimpan di suatu tempat.

Untuk mengatasi masalah ini, aplikasi client sering mengirim data ini ke server dalam permintaan POST, menetapkan cookie sesi kepada pengguna, dan masuk secara efektif. Permintaan ini mirip dengan permintaan pengiriman formulir yang dapat diajukan sebagai bagian. Login berbasis sandi tradisional Namun, dalam skenario ini, server tidak memiliki rahasia atau sandi untuk dibandingkan dengan data yang dikirim. Artinya, server secara implisit dipercaya.

Dalam flow implisit, permintaan POST ini diekspos ke penyerang melalui browser. Akibatnya, perilaku ini dapat menyebabkan kerentanan serius jika aplikasi client tidak memeriksa dengan benar apakah token akses cocok dengan data lain dalam permintaan. Dalam hal ini, penyerang dapat menyamar sebagai pengguna mana pun hanya dengan mengubah parameter yang dikirim ke server.

Lab Autentikasi melewati flow implisit OAuth

Perlindungan CSRF yang rusak

Banyak komponen alur OAuth bersifat opsional, tetapi beberapa sangat disarankan kecuali Anda memiliki alasan yang signifikan untuk tidak menggunakannya. Salah satu contohnya adalah parameter status.

Idealnya, parameter status harus berisi nilai yang tidak dapat diprediksi, seperti hash dari apa yang dikaitkan saat sesi pengguna pertama kali memulai flow OAuth. Nilai ini kemudian dipertukarkan antara aplikasi client dan layanan OAuth dalam bentuk token CSRF aplikasi client. Oleh karena itu, ini sangat menarik dari sudut pandang penyerang jika Anda melihat bahwa permintaan otorisasi tidak mengirimkan parameter status. Ini bisa berarti bahwa Anda dapat memulai sendiri alur OAuth sebelum mengelabui browser pengguna agar menyelesaikannya, mirip dengan serangan CSRF tradisional. Ini dapat memiliki konsekuensi serius, tergantung pada bagaimana OAuth digunakan oleh aplikasi client.

Pertimbangkan situs web tempat pengguna dapat masuk dengan menggunakan mekanisme berbasis kata sandi tradisional atau dengan menggunakan OAuth untuk menautkan akun mereka ke profil media sosial. Dalam hal ini, jika aplikasi gagal menggunakan parameter status, penyerang dapat membajak akun pengguna korban di aplikasi client dengan mengikatnya ke akun media sosial mereka.

LAB Tautan profil OAuth paksa

Perhatikan bahwa parameter status mungkin kurang penting jika situs Anda mengizinkan pengguna untuk masuk secara eksklusif melalui OAuth. Namun, tanpa parameter status, penyerang dapat membuat serangan CSRF login dan pengguna dapat ditipu untuk login ke akun penyerang.

Kebocoran kode otorisasi dan token akses

Mungkin kerentanan berbasis OAuth yang paling terkenal adalah ketika konfigurasi layanan OAuth itu sendiri memungkinkan penyerang mencuri kode otorisasi atau mengakses token yang terkait dengan akun pengguna lain. Penyerang dapat memperoleh akses ke data korban dengan mencuri kode atau token yang valid. Pada akhirnya, ini benar-benar dapat membahayakan akun Anda. Penyerang dapat masuk sebagai pengguna korban ke aplikasi client yang terdaftar dengan layanan OAuth ini.

Tergantung pada grant types, baik kode atau token akan dikirim melalui browser korban ke titik akhir / callback yang ditentukan oleh parameter redirect_uri dalam permintaan otorisasi. Jika layanan OAuth tidak dapat memvalidasi URI ini dengan benar, penyerang membuat serangan mirip CSRF yang mengelabui browser korban agar meluncurkan flow OAuth dan mengirimkan kode atau token ke redirect_uri yang dikendalikan penyerang. Ada kemungkinan.

Dalam kasus flow kode otentikasi, penyerang dapat mencuri kode korban sebelum digunakan. Anda kemudian dapat mengirim kode ini ke endpoint/callback yang sah (redirect_uri asli) dari aplikasi client untuk mengakses akun pengguna. Dalam skenario ini, penyerang bahkan tidak perlu mengetahui rahasia client atau token akses yang dihasilkan. Selama korban memiliki sesi yang valid dengan layanan OAuth, aplikasi client hanya akan menyelesaikan pertukaran kode/token atas nama penyerang sebelum masuk ke akun korban.

Ingatlah bahwa perlindungan negara atau perlindungan nonce tidak selalu mencegah serangan ini, karena penyerang dapat menghasilkan nilai baru dari browser mereka.

LAB Membajak akun OAuth melalui redirect_uri

Server autentikasi yang lebih aman juga harus mengirimkan parameter redirect_uri saat bertukar kode. Server dapat memeriksa apakah ini cocok dengan apa yang diterima dalam permintaan persetujuan pertama dan menolak pertukaran jika tidak. Ini terjadi dalam permintaan server-ke-server melalui saluran belakang yang aman, sehingga penyerang tidak memiliki kendali atas parameter redirect_uri kedua ini.

Validasi redirect_uri rusak

Karena jenis serangan yang terlihat di lab sebelumnya, praktik terbaik bagi aplikasi client adalah memberikan daftar putih URI panggilan balik asli saat mendaftar di layanan OAuth. Dengan cara ini, layanan OAuth dapat memvalidasi parameter redirect_uri terhadap daftar putih ini saat menerima permintaan baru. Dalam hal ini, menentukan URI eksternal dapat menyebabkan kesalahan. Namun, mungkin masih ada cara untuk melewati validasi ini.

Saat mengaudit alur OAuth, Anda harus mencoba parameter redirect_uri untuk memahami cara memvalidasinya. Misalnya:

Dalam beberapa implementasi, subdirektori yang berbeda dapat digunakan dengan memeriksa bahwa string dimulai dengan urutan karakter yang benar, yaitu hanya domain yang disetujui. Untuk melihat apa yang dapat Anda ubah tanpa memicu kesalahan, coba hapus atau tambahkan jalur, parameter kueri, dan fragmen apa pun.
If you can append extra values to the default redirect_uri parameter, you might be able to exploit discrepancies between the parsing of the URI by the different components of the OAuth service. For example, you can try techniques seperti:
```
https://default-host.com & @ foo.evil-user.net # @ bar.evil-user.net/
      
```
Jika Anda baru mengenal teknik ini, kami sarankan untuk membaca konten tentang perlindungan SSRF umum dan cara menghindari CORS.
Anda mungkin mengalami kerentanan polusi parameter sisi server. Untuk jaga-jaga, coba kirimkan parameter redirect_uri duplikat seperti ini:
```
https://oauth-authorization-server.com/?client_id=123&redirect_uri=client-app.com/callback&redirect_uri=evil-user.net
```
Beberapa server juga melakukan pemrosesan khusus untuk URI localhost yang sering digunakan selama pengembangan. Dalam beberapa kasus, redirect URI yang dimulai dengan localhost mungkin salah diizinkan dalam produksi. Ini memungkinkan Anda untuk melewati validasi dengan mendaftarkan nama domain seperti localhost.evil-user.net.

Penting untuk dicatat bahwa pengujian tidak boleh dibatasi hanya dengan menyelidiki parameter redirect_uri saja. Di alam liar, Anda sering harus mencoba berbagai kombinasi perubahan pada beberapa parameter. Mengubah satu parameter dapat mempengaruhi validasi parameter lainnya. Misalnya, mengubah response_mode dari query ke fragmen dapat sepenuhnya mengubah penguraian redirect_uri, memungkinkan Anda mengirim URI yang seharusnya diblokir. Demikian pula, jika Anda melihat bahwa mode respons web_message didukung, ini sering memungkinkan redirect_uri untuk memungkinkan jangkauan subdomain yang lebih luas.

Curi kode dan akses token melalui halaman proxy

Untuk target yang lebih kuat, apa pun yang Anda coba, Anda mungkin tidak berhasil mengirim domain eksternal sebagai redirect_uri. Tapi bukan berarti sudah waktunya untuk menyerah.

Pada tahap ini, Anda harus memiliki pemahaman yang relatif baik tentang bagian URI mana yang dapat diubah. Kuncinya di sini adalah menggunakan pengetahuan ini untuk mencoba mengakses permukaan serangan yang lebih luas dari aplikasi client itu sendiri. Artinya, pertimbangkan untuk mengubah parameter redirect_uri agar mengarah ke halaman lain di domain yang masuk daftar putih.

Temukan cara untuk berhasil mengakses subdomain atau jalur yang berbeda. Misalnya, URI default sering kali berada di jalur khusus OAuth seperti /oauth/callback, yang mungkin tidak memiliki subdirektori yang menarik. Namun, Anda mungkin dapat menggunakan trik traversal direktori untuk menentukan jalur apa pun di domain Anda. Sesuatu seperti:

https://client-app.com/oauth/callback/../../example/path

Backend dapat menafsirkannya sebagai berikut:

https://client-app.com/example/path

Setelah Anda mengidentifikasi halaman lain yang dapat dikonfigurasi sebagai URI pengalihan, Anda perlu mengauditnya untuk kerentanan tambahan yang dapat digunakan untuk membocorkan kode atau token Anda. Untuk alur kode otorisasi, Anda perlu menemukan kerentanan yang dapat mengakses parameter query, tetapi untuk jenis pemberian implisit, Anda perlu mengekstrak fragmen URL.

Salah satu kerentanan yang paling berguna untuk tujuan ini adalah pengalihan terbuka. Ini dapat digunakan sebagai proxy untuk mentransfer korban, bersama dengan kode atau token, ke domain yang dikendalikan penyerang, tempat skrip berbahaya apa pun dapat dihosting.

Perhatikan bahwa untuk jenis izin implisit, mencuri token akses tidak hanya mengizinkan aplikasi client untuk masuk ke akun korban. Karena seluruh flow implisit dilakukan melalui browser, Anda juga dapat menggunakan token untuk membuat panggilan API Anda sendiri ke server sumber daya layanan OAuth. Ini memungkinkan Anda untuk mengambil data pengguna sensitif yang biasanya tidak dapat diakses dari UI Web aplikasi client.

LAB Curi token akses OAuth melalui open redirect

Selain pengalihan terbuka, kita perlu mencari kerentanan lain yang dapat mengekstrak kode atau token dan mengirimkannya ke domain eksternal. Tergantungmasuk beberapa contoh bagus:

JavaScript berbahaya yang menangani parameter kueri dan fragmen URL Misalnya, skrip perpesanan web yang tidak aman sangat cocok untuk ini. Dalam beberapa skenario, Anda mungkin perlu mengidentifikasi rantai gadget yang lebih panjang yang dapat meneruskan token melalui serangkaian skrip sebelum akhirnya bocor ke domain eksternal.
Kerentanan XSS Serangan XSS dapat memiliki dampak yang signifikan pada mereka sendiri, tetapi mereka biasanya memiliki kerangka waktu yang singkat di mana penyerang dapat mengakses sesi pengguna sebelum menutup atau meninggalkan tab. Karena atribut HTTPOnly biasanya digunakan untuk cookie sesi, penyerang sering kali tidak dapat menggunakan XSS untuk mengakses cookie secara langsung. Namun, penyerang dapat mengakses akun Anda di browser dengan mencuri kode atau token OAuth Anda. Ini secara signifikan meningkatkan waktu yang diperlukan untuk menyelidiki data pengguna dan melakukan tindakan berbahaya, secara signifikan meningkatkan tingkat keparahan kerentanan XSS.
Kerentanan injeksi HTML Meskipun Anda tidak dapat menyisipkan JavaScript (misalnya, karena kendala CSP atau penyaringan ketat), Anda mungkin masih dapat menggunakan penyisipan HTML sederhana untuk mencuri kode otorisasi Anda. Jika Anda dapat menentukan parameter redirect_uri pada halaman tempat Anda dapat menyisipkan konten HTML Anda sendiri, Anda mungkin dapat membocorkan kode Anda melalui header Referer. Misalnya, perhatikan elemen img berikut: . Saat mencoba mendapatkan gambar ini, beberapa browser (seperti Firefox) akan mengirimkan URL lengkap yang berisi string kueri di header Referer dari permintaan tersebut.

LAB Curi token akses OAuth melalui halaman proxy

Verifikasi cakupan yang rusak

Alur OAuth mengharuskan pengguna untuk menyetujui akses yang diminta berdasarkan cakupan yang ditentukan dalam permintaan otorisasi. Token yang dihasilkan memungkinkan aplikasi client untuk mengakses hanya lingkup yang disetujui oleh pengguna. Namun, dalam beberapa kasus, verifikasi oleh layanan OAuth cacat, sehingga penyerang "meningkatkan" token akses (yang dicuri atau diperoleh menggunakan aplikasi client jahat) dengan izin tambahan. Ada kemungkinan. Proses melakukan ini tergantung pada grant types.

Peningkatan cakupan: Alur kode otentikasi

Dengan jenis pemberian kode otorisasi, data pengguna diminta dan dikirim melalui komunikasi server-ke-server yang aman. Ini biasanya tidak dapat diakses langsung oleh penyerang pihak ketiga. Namun, Anda mungkin mendapatkan hasil yang sama dengan mendaftarkan aplikasi client Anda sendiri ke layanan OAuth.

Misalnya, aplikasi client jahat penyerang pertama-tama meminta akses ke alamat email pengguna menggunakan cakupan email openid. Setelah pengguna menyetujui permintaan ini, aplikasi client jahat menerima kode otorisasi. Setelah penyerang mengontrol aplikasi client, ia dapat menambahkan parameter cakupan lainnya ke permintaan pertukaran kode/token, termasuk cakupan profil tambahan.

POST /token
Host: oauth-authorization-server.com
…
client_id=12345&client_secret=SECRET&redirect_uri=https://client-app.com/callback&grant_type=authorization_code&code=a1b2c3d4e5f6g7h8&scope=openid%20 email%20profile

Jika server tidak memvalidasi ini terhadap lingkup dari permintaan otorisasi pertama, server dapat menggunakan lingkup baru untuk menghasilkan token akses dan mengirimkannya ke aplikasi client penyerang.

{
    "access_token": "z0y9x8w7v6u5",
    "token_type": "Bearer",
    "expires_in": 3600,
    "scope": "openid email profile",
    …
}

Penyerang kemudian dapat menggunakan aplikasi untuk membuat panggilan API yang diperlukan untuk mengakses data profil pengguna.

Peningkatan cakupan: flow implisit

Untuk tipe izin implisit, token akses dikirim melalui browser. Artinya, penyerang dapat mencuri token yang terkait dengan aplikasi client yang tidak bersalah dan menggunakannya secara langsung. Setelah mencuri token akses, Anda dapat mengirim permintaan berbasis browser biasa ke titik akhir layanan OAuth /userinfo dan secara manual menambahkan parameter cakupan baru ke proses.

Idealnya, layanan OAuth harus memvalidasi nilai cakupan ini terhadap nilai cakupan yang digunakan saat membuat token, tetapi hal ini tidak selalu terjadi. Penyerang dapat memperoleh akses ke data tambahan tanpa memerlukan otorisasi tambahan dari pengguna, selama izin yang disesuaikan tidak melebihi tingkat akses yang sebelumnya diberikan ke aplikasi client ini.

Pendaftaran pengguna yang belum dikonfirmasi

Saat mengautentikasi pengguna melalui OAuth, aplikasi client secara implisit mengasumsikan bahwa informasi yang disimpan oleh penyedia OAuth benar. Ini bisa menjadi asumsi yang berbahaya.

Beberapa situs web yang menawarkan layanan OAuth memungkinkan pengguna untuk mendaftar akun tanpa harus melalui semua detail, termasuk alamat email mereka dalam beberapa kasus. Penyerang dapat memanfaatkan ini dengan mendaftarkan akun ke penyedia OAuth menggunakan detail yang sama dengan pengguna target, seperti alamat email yang diketahui. Aplikasi client dapat mengizinkan penyerang untuk masuk sebagai korban melalui akun nakal penyedia OAuth ini.

Memperluas OAuth dengan OpenID Connect

Saat digunakan untuk otentikasi, OAuth sering diperluas pada lapisan OpenID Connect untuk menyediakan beberapa fungsionalitas tambahan yang terkait dengan identifikasi dan otentikasi pengguna. Lihat topik OpenID Connect untuk deskripsi mendetail tentang fitur ini dan lab lain yang terkait dengan kerentanan yang mungkin ditimbulkannya.

baca selengkapnya Koneksi OpenID

Pencegahan kerentanan otentikasi OAuth

Kami memberikan panduan bagi pengembang tentang cara mencegah kerentanan ini diperkenalkan ke situs web dan aplikasi mereka.

baca selengkapnya Bagaimana mencegah kerentanan otentikasi OAuth

sumber : https://portswigger.net/web-security/oauth

Artikel Laravel Lainnya :

Bug HTTP Request Smuggling dan Antisipasinya

Penyerangan Pada Bug HTTP Host Header

Plugin Tambahan Puppeteer Stealth