Kerentanan OAuth dan Corak Serangan

Pelayan kebenaran OAuth mesti mengesahkan parameter redirect_uri dengan ketat. Jika pelayan membenarkan padanan awalan atau padanan kad bebas (contohnya, menerima sebarang URL yang bermula dengan "https://app.example.com"), penyerang boleh membina permintaan kebenaran yang mengalih ke "https://app.example.com.attacker.com/steal" atau pengalihan terbuka pada domain sah, lalu mencuri kod kebenaran.

Tanpa perlindungan CSRF, penyerang boleh memulakan aliran OAuth dan memperdaya pelayar mangsa supaya menyelesaikan proses kebenaran. Mangsa secara tidak sengaja memberikan kebenaran kepada klien penyerang. Parameter "state" (RFC 6749) mencegah perkara ini: klien menjana state rawak, menyertakannya dalam permintaan, dan mengesahkan bahawa nilainya sepadan dalam panggilan balik. Ketidakpadanan membatalkan aliran.

Pada platform mudah alih, aplikasi berniat jahat boleh mendaftarkan skema URI tersuai yang sama seperti klien OAuth yang sah dan memintas kod kebenaran yang dialihkan selepas pengesahan pengguna. PKCE (RFC 7636) ialah pertahanan lengkap: kod yang dipintas tidak berguna tanpa pengesah kod yang hanya dijana oleh aplikasi sah pada permulaan aliran.

Apabila token ID atau token akses disertakan dalam serpihan URL atau parameter pertanyaan, navigasi seterusnya dari halaman itu menyertakan URL dalam pengepala Referer, yang berpotensi membocorkan token kepada skrip analitis pihak ketiga atau pembekal CDN. Sentiasa gunakan aliran kod kebenaran dengan penghantaran token melalui saluran belakang untuk mengelakkan token muncul dalam URL.

Apabila klien menyokong berbilang pembekal OAuth, serangan kekeliruan memperdaya klien supaya menghantar kod kebenaran yang diperoleh daripada Pembekal A ke titik akhir token Pembekal B. Klien mesti mengesahkan tuntutan "iss" dalam token ID dan mengikat panggilan balik kepada pembekal tertentu yang memulakan aliran menggunakan parameter state atau JARM (Mod Respons Kebenaran Terjamin JWT).

Serangan pemalsuan permintaan sisi pelayan (SSRF) menyasarkan pelaksanaan OAuth yang membuat permintaan HTTP sisi pelayan ke redirect_uri. Jika pelayan kebenaran mendapatkan redirect_uri untuk mengesahkannya, penyerang membekalkan alamat IP dalaman (contohnya, http://169.254.169.254/latest/meta-data/) untuk mengakses metadata tika awan atau perkhidmatan dalaman. Pengesahan redirect_uri berasaskan senarai yang dibenarkan dengan ketat mencegah perkara ini.

Banyak aplikasi menggunakan tuntutan e-mel daripada token ID OIDC untuk memautkan akaun merentas pembekal. Jika penyerang mengawal alamat e-mel yang sepadan dengan akaun mangsa pada pembekal lain, mereka boleh mendaftar dengan pembekal berbeza menggunakan e-mel itu dan mendapat akses kepada akaun mangsa. Pertahanan: pautkan akaun berdasarkan pasangan (iss, sub) sahaja, jangan sekali-kali berdasarkan e-mel sahaja.

Serangan kekeliruan algoritma JWT mengeksploitasi pelaksanaan yang mempercayai pengepala "alg" untuk memilih algoritma pengesahan. Serangan: ubah "alg" daripada "RS256" kepada "HS256" dan tandatangani token dengan kunci awam pelayan sebagai rahsia HMAC (kerana kunci awam itu memang umum). Pertahanan: sentiasa tentukan algoritma yang dijangka secara jelas dalam kod pengesahan, jangan sekali-kali mempercayai tuntutan alg pada pengepala token.

Penyerang mendaftarkan klien OAuth berniat jahat dengan nama dan logo yang kelihatan sah, kemudian menghantar pautan pancingan data kepada sasaran. Mangsa melihat skrin persetujuan OAuth yang tulen (dihoskan oleh Google, Microsoft dan sebagainya) untuk aplikasi berniat jahat lalu memberikan akses. Pertahanan: sahkan bahawa client_id sepadan dengan aplikasi yang dijangka; Google dan Microsoft menyediakan program pengesahan klien untuk aplikasi yang sah.

Peningkatan skop berlaku apabila klien memperoleh token dengan keizinan yang lebih luas daripada yang dibenarkan oleh pengguna. Kecacatan pelaksanaan yang melangkau pengesahan skop pada titik akhir token, menyimpan token dengan skop yang digabungkan daripada permintaan yang berbeza, atau gagal mengesahkan bahawa skop dalam token yang dikeluarkan tidak melebihi skop yang dibenarkan, semuanya boleh membawa kepada peningkatan keistimewaan melalui OAuth.

Lindungi pelaksanaan OAuth dengan: menggunakan pengesahan redirect_uri padanan tepat, mewajibkan PKCE untuk semua klien awam, mengesahkan parameter state untuk perlindungan CSRF, mengikat token ID berdasarkan (iss, sub) dan bukan e-mel, menentukan algoritma JWT yang dijangka secara jelas, meminta skop minimum, menggunakan token akses berjangka hayat pendek dengan penggiliran token penyegaran, dan mengaudit rupa skrin persetujuan untuk menilai risiko penyamaran jenama.

Serangan utama OAuth: pengalihan terbuka melalui pengesahan redirect_uri yang longgar (gunakan padanan tepat), CSRF melalui ketiadaan parameter state, pemintasan kod pada peranti mudah alih (dikurangkan dengan PKCE), kebocoran token dalam URL, kekeliruan dalam persediaan berbilang pembekal (sahkan iss), SSRF melalui redirect_uri yang diambil oleh pelayan, pertembungan tuntutan e-mel (gunakan iss+sub), kekeliruan algoritma JWT (tetapkan alg yang dijangka), dan pancingan data melalui skrin persetujuan palsu.