Kerentanan OAuth dan Pola Serangan

Server otorisasi OAuth harus memvalidasi parameter redirect_uri secara ketat. Jika server mengizinkan pencocokan awalan atau pencocokan wildcard (misalnya menerima URL apa pun yang dimulai dengan "https://app.example.com"), penyerang membuat permintaan otorisasi yang mengalihkan ke "https://app.example.com.attacker.com/steal" atau ke pengalihan terbuka pada domain yang sah, lalu mencuri kode otorisasi.

Tanpa perlindungan CSRF, penyerang dapat memulai alur OAuth dan mengelabui peramban korban agar menyelesaikan otorisasi. Korban tanpa sengaja memberikan otorisasi kepada klien penyerang. Parameter "state" (RFC 6749) mencegahnya: klien membuat state acak, menyertakannya dalam permintaan, dan memverifikasi bahwa nilainya cocok pada panggilan balik. Ketidakcocokan membatalkan alur.

Pada platform seluler, aplikasi berbahaya dapat mendaftarkan skema URI khusus yang sama dengan klien OAuth yang sah dan menyadap kode otorisasi yang dialihkan setelah autentikasi pengguna. PKCE (RFC 7636) merupakan pertahanan lengkap: kode yang disadap tidak berguna tanpa pemverifikasi kode yang hanya dibuat oleh aplikasi sah pada awal alur.

Ketika token ID atau token akses disertakan dalam fragmen URL atau parameter kueri, navigasi berikutnya dari halaman tersebut menyertakan URL dalam header Referer, yang berpotensi membocorkan token kepada skrip analitik pihak ketiga atau penyedia CDN. Selalu gunakan alur kode otorisasi dengan pengiriman token melalui kanal belakang agar token tidak muncul dalam URL.

Ketika klien mendukung beberapa penyedia OAuth, serangan kekacauan mengelabui klien agar mengirimkan kode otorisasi yang diperoleh dari Penyedia A ke titik akhir token Penyedia B. Klien harus memvalidasi klaim "iss" dalam token ID dan mengikat panggilan balik ke penyedia tertentu yang memulai alur menggunakan parameter state atau JARM (Mode Respons Otorisasi yang Diamankan dengan JWT).

Serangan pemalsuan permintaan sisi server (SSRF) menargetkan implementasi OAuth yang melakukan permintaan HTTP sisi server ke redirect_uri. Jika server otorisasi mengambil redirect_uri untuk memverifikasinya, penyerang memasok alamat IP internal (misalnya, http://169.254.169.254/latest/meta-data/) untuk mengakses metadata instans awan atau layanan internal. Validasi redirect_uri yang ketat dan berbasis daftar izin mencegah hal ini.

Banyak aplikasi menggunakan klaim email dari token ID OIDC untuk menautkan akun di berbagai penyedia. Jika penyerang mengendalikan alamat email yang cocok dengan akun korban di penyedia lain, penyerang dapat mendaftar melalui penyedia yang berbeda menggunakan email tersebut dan memperoleh akses ke akun korban. Pertahanan: tautkan akun hanya berdasarkan pasangan (iss, sub), jangan pernah berdasarkan email saja.

Serangan kekacauan algoritme JWT mengeksploitasi implementasi yang mempercayai header "alg" untuk memilih algoritme verifikasi. Serangan: ubah "alg" dari "RS256" menjadi "HS256" dan tanda tangani token menggunakan kunci publik server sebagai rahasia HMAC (karena kunci publik bersifat publik). Pertahanan: selalu tentukan algoritme yang diharapkan secara eksplisit dalam kode verifikasi, jangan pernah mempercayai klaim alg pada header token.

Penyerang mendaftarkan klien OAuth berbahaya dengan nama dan logo yang tampak sah, lalu mengirim tautan penipuan kepada target. Korban melihat layar persetujuan OAuth yang asli (disediakan oleh Google, Microsoft, dan sebagainya) untuk aplikasi berbahaya dan memberikan akses. Pertahanan: pastikan client_id sesuai dengan aplikasi yang diharapkan; Google dan Microsoft menyediakan program verifikasi klien untuk aplikasi yang sah.

Eskalasi ruang lingkup terjadi ketika klien memperoleh token dengan izin yang lebih luas daripada yang diotorisasi pengguna. Cacat implementasi yang melewati validasi ruang lingkup pada titik akhir token, menyimpan token dengan ruang lingkup gabungan dari berbagai permintaan, atau gagal memvalidasi bahwa ruang lingkup dalam token yang diterbitkan tidak melebihi ruang lingkup yang diotorisasi, semuanya dapat menyebabkan eskalasi hak istimewa melalui OAuth.

Lindungi implementasi OAuth dengan: menggunakan validasi redirect_uri yang mencocokkan secara tepat, mewajibkan PKCE untuk semua klien publik, memvalidasi parameter state untuk perlindungan CSRF, mengikat token ID berdasarkan (iss, sub), bukan email, menentukan algoritme JWT yang diharapkan secara eksplisit, meminta ruang lingkup minimal, menggunakan token akses berumur pendek dengan rotasi token penyegaran, serta mengaudit tampilan layar persetujuan untuk mengetahui risiko peniruan merek.

Serangan utama OAuth: pengalihan terbuka melalui validasi redirect_uri yang longgar (gunakan pencocokan tepat), CSRF melalui parameter state yang tidak ada, penyadapan kode di perangkat seluler (dikurangi dengan PKCE), kebocoran token dalam URL, kekacauan dalam penyiapan multi-penyedia (validasi iss), SSRF melalui redirect_uri yang diambil server, benturan klaim email (gunakan iss+sub), kekacauan algoritme JWT (tetapkan alg yang diharapkan), dan penipuan melalui layar persetujuan palsu.