Anda mungkin tidak mengenali istilah “OAuth” (Open Authorization), tetapi kemungkinan besar Anda telah menggunakannya tanpa menyadarinya. Setiap kali Anda masuk ke aplikasi atau situs web menggunakan akun Google, Facebook, atau lainnya, OAuth memberikan akses terbatas ke data Anda tanpa membagikan kata sandi. OAuth menyederhanakan proses autentikasi pengguna di berbagai platform, menjadikannya bagian penting dalam pengalaman online yang aman. Namun, di balik kesederhanaannya, terdapat sistem yang kompleks yang, jika tidak diterapkan dengan benar, dapat menyebabkan pengambilalihan akun.
Dalam postingan blog ini, kami akan membahas analisis kami terhadap implementasi OAuth di 100 situs web, menyoroti masalah keamanan umum, dan membahas teknik yang digunakan untuk mengidentifikasinya. Sebagai bagian dari penelitian ini, kami mengembangkan alat open-source bernama “oauth-hunter” untuk membantu menemukan kerentanan dan menyederhanakan proses penelitian kami.
tl;dr (Ringkasan Singkat)
- Kami menganalisis 100 situs web yang menggunakan OAuth, dari platform besar hingga situs yang lebih kecil.
- 28 situs web tidak memverifikasi parameter redirect_uri dengan benar, dan 18 di antaranya mengizinkan penambahan path apa pun setelah domain.
- 21 situs web tidak memverifikasi parameter state dengan benar, dan 8 di antaranya memungkinkan penyerang menipu korban agar menyelesaikan proses OAuth, sehingga memberikan akses ke sesi korban.
- 7 situs web memiliki kerentanan pre-account takeover.
Penelitian
Penelitian ini dilakukan untuk memahami bagaimana situs web menerapkan OAuth dan apakah mereka mengikuti praktik terbaik untuk mencegah pengambilalihan akun. Tujuan kami adalah menilai seberapa efektif berbagai situs web dalam mengamankan proses autentikasi mereka terhadap kerentanan terkait OAuth.
Selama penyelidikan, kami menganalisis 100 situs web, mulai dari yang besar dan populer hingga yang lebih kecil. Mayoritas situs menggunakan penyedia identitas (IdP) yang umum, seperti:
- Facebook (47%)
- GitHub (35%)
- GitLab (1%)
- Lainnya (17%)
Sebelum masuk ke hasil penelitian, mari kita tinjau dasar-dasar OAuth.
Bagaimana OAuth Bekerja?
Alur Authorization Code Flow dalam diagram di bawah ini (Gambar 1) menggambarkan proses OAuth. Metode ini adalah salah satu yang paling umum dan aman untuk memberikan akses, karena melibatkan pertukaran kode sementara dengan token akses, sehingga data sensitif seperti kredensial tidak terekspos ke klien.
Sebelum memulai, berikut adalah empat komponen utama dalam alur OAuth yang akan kami jelaskan melalui diagram ini:
- Resource owner → Pengguna yang memiliki data atau sumber daya, misalnya “John”.
- Client → Aplikasi atau situs web (contoh: example.com) yang meminta akses ke sumber daya atas nama pengguna (John), misalnya informasi profilnya.
- Authorization server (OAuth provider) → Layanan yang mengautentikasi pengguna dan memberikan token akses, seperti GitHub.
- Resource server → Server yang menyimpan sumber daya yang dilindungi (data atau layanan) yang ingin diakses oleh klien atas nama pemilik sumber daya. Dalam kasus ini, GitHub bertindak sebagai authorization server dan resource server, sehingga kami tidak membahasnya secara terpisah.

Gambar 1 – OAuth Authorization Code Flow
Mari kita bahas alur authorization code (Gambar 1):
- John, sebagai pemilik sumber daya, mengunjungi situs web example.com (OAuth Client) dan memulai proses login dengan memilih opsi GitHub.
- Karena example.com tidak mengenali John, situs tersebut meminta bukti identitasnya.
- John kemudian dialihkan ke GitHub, yang bertindak sebagai authorization server, dan GitHub meminta izin dari John untuk mengizinkan example.com mengakses data GitHub miliknya.
- GitHub mengirimkan kode otorisasi unik kepada John untuk dibagikan ke example.com.
- John memberikan kode otorisasi tersebut kepada example.com.
- Example.com meneruskan kode otorisasi John ke GitHub dan meminta access token.
- Setelah GitHub memverifikasi kode otorisasi, GitHub mengirimkan access token ke example.com.
- Example.com menggunakan access token tersebut untuk meminta informasi pengguna (misalnya identitas John) dari GitHub.
- GitHub memvalidasi access token dan mengembalikan informasi identitas pengguna (misalnya, “John”).
- Example.com mengautentikasi John berdasarkan identitas yang diterima dan memberikan akses ke sumber dayanya.
Alur OAuth dapat bervariasi tergantung pada parameter OAuth yang digunakan dalam implementasi yang berbeda.
Memahami Parameter Kunci OAuth
Sekarang setelah kita memahami alur dasar OAuth Authorization Code, mari kita lihat beberapa parameter OAuth yang penting untuk memahami potensi vektor serangan:
- redirect_uri: URI tempat penyedia OAuth akan mengarahkan pengguna (dalam hal ini, John) setelah mereka menyetujui atau menolak otorisasi. URI ini harus terdaftar sebelumnya dengan penyedia OAuth sebagai bagian dari proses registrasi aplikasi klien.
- response_type: Menentukan jenis respons yang diharapkan oleh aplikasi klien dari penyedia OAuth. Jenis yang umum meliputi:
- code:
- Flow: Authorization Code Grant.
- Deskripsi: Klien mengharapkan pemilik sumber daya (pengguna) memberikan otorisasi, sehingga penyedia OAuth mengeluarkan kode otorisasi yang kemudian dapat ditukar dengan token akses. Metode ini paling umum digunakan untuk aplikasi web berbasis server.
- token:
- Flow: Implicit Grant.
- Deskripsi: Klien menerima token akses secara langsung dari pemilik sumber daya. Biasanya digunakan dalam aplikasi klien berbasis JavaScript seperti Single Page Applications (SPA).
- code:
- client_id: Identifikasi unik yang diberikan oleh penyedia OAuth (misalnya, GitHub) kepada aplikasi klien (contohnya, example.com).
- scope: Menentukan izin spesifik yang diminta oleh klien dalam alur OAuth.
- state: Fitur keamanan untuk mencegah Cross-Site Request Forgery (CSRF).
- prompt: Parameter yang mengontrol bagaimana penyedia otorisasi meminta otentikasi pengguna. Beberapa opsi umum:
- none: Tidak ada interaksi pengguna, gagal jika diperlukan otentikasi atau persetujuan.
- login: Memaksa pengguna untuk login ulang.
- consent: Memaksa pengguna untuk memberikan izin lagi, meskipun sudah pernah diberikan.
- select_account: Memungkinkan pengguna memilih akun jika memiliki lebih dari satu akun yang masuk.
- response_mode: Menentukan bagaimana respons otorisasi dikirimkan ke klien. Opsi umum meliputi:
- query: Respons dikirim sebagai parameter kueri dalam URL.
- fragment: Respons dikirim sebagai parameter fragment (#) dalam URL.
- form_post: Respons dikirim sebagai form submission (lebih aman untuk server yang menangani POST requests).
Eksploitasi Parameter OAuth dalam Serangan
Meskipun parameter-parameter ini penting dalam proses OAuth, jika tidak divalidasi dengan benar, mereka dapat menjadi celah keamanan. Beberapa contoh eksploitasi:
- Bypass Patch CVE-2023-6291:
- Penyerang berhasil melewati patch dengan mengganti response_mode=fragment menjadi response_mode=form_post, memungkinkan mereka untuk mengubah redirect menggunakan form HTML, sehingga pengguna diarahkan ke situs berbahaya.
- Eksploitasi prompt=none:
- Dengan menyetel parameter prompt=none, penyerang dapat menghindari layar persetujuan pengguna. Jika korban sudah masuk sebelumnya, server otorisasi akan langsung mengeluarkan kode otorisasi tanpa persetujuan pengguna.

Eksploitasi redirect_uri untuk Pengambilalihan Akun
Salah satu metode serangan paling umum dalam OAuth adalah penyalahgunaan redirect_uri, yang dapat mengarahkan korban ke situs milik penyerang dengan kode otorisasi mereka.
Jika aplikasi tidak menerapkan validasi ketat pada redirect_uri, penyerang dapat mengubah URL tujuan agar mengarah ke situs mereka sendiri.
Contoh skenario serangan:
- Penyerang mengirimkan tautan OAuth yang telah dimodifikasi melalui email phishing:
- https://github.com/login/oauth/authorize?redirect_uri=https://attacker.com
- Korban mengklik tautan tersebut, tidak menyadari bahwa redirect_uri mengarah ke situs berbahaya.
- Setelah korban mengotorisasi akses, GitHub mengirimkan kode otorisasi ke https://attacker.com.
- Penyerang kemudian menukarkan kode ini dengan access token, yang dapat digunakan untuk mengakses akun korban.
Serangan ini menunjukkan pentingnya validasi yang ketat terhadap redirect_uri untuk mencegah penyalahgunaan dan pengambilalihan akun.
Eksploitasi redirect_uri: Open Redirect Vulnerability dan Pengambilalihan Akun
Pada diagram contoh berikut (Figure 2), kita akan melihat bagaimana penyerang dapat mengeksploitasi parameter redirect_uri untuk mengarahkan korban ke URL berbahaya tanpa validasi yang tepat—kerentanan ini dikenal sebagai Open Redirect Vulnerability.
Langkah-Langkah Serangan
- Penyerang membuat tautan berbahaya yang mengeksploitasi Open Redirect dengan menyisipkan URL tujuan berbahaya di parameter redirect_uri, misalnya:
- ?to=https://attacker.com
- Korban mengklik tautan berbahaya dan meminta kode otorisasi dari GitHub (authorization server).
- GitHub mengeluarkan kode otorisasi dan mengirimkannya ke korban.
- Korban diarahkan ke aplikasi OAuth klien (contohnya, example.com).
- example.com mengikuti redirect dan mengirimkan korban tautan baru.
- Korban tanpa sadar mengikuti tautan baru, yang mengarah ke situs penyerang dengan kode otorisasi yang tersisip di dalamnya.
- Penyerang menangkap kode otorisasi dan meneruskannya ke endpoint callback example.com (redirect_uri yang asli).
- example.com mengirimkan kode otorisasi ke GitHub untuk ditukarkan dengan access token.
- GitHub memverifikasi kode otorisasi dan mengirimkan access token ke example.com.
- example.com menggunakan access token untuk meminta informasi pengguna (misalnya, identitas korban) dari GitHub.
- GitHub memvalidasi access token dan mengembalikan identitas pengguna (misalnya, “Victim”).
- example.com mengotentikasi korban berdasarkan identitas yang diterima dan memberikan akses ke sumber daya mereka.
Hasil akhirnya: Penyerang berhasil masuk ke akun korban tanpa kredensial aslinya.
Cara Mencegah Serangan Ini: Implementasi PKCE
Serangan ini dapat dicegah dengan menggunakan Proof Key for Code Exchange (PKCE), sebuah ekstensi pada protokol OAuth 2.0 yang menambahkan lapisan keamanan tambahan.
Bagaimana PKCE Mencegah Serangan?
- PKCE mengharuskan klien untuk menghasilkan kode unik (verifier) dan tantangan kode (code challenge) selama proses otorisasi.
- Jika penyerang mendapatkan kode otorisasi, mereka tidak dapat menukarkannya dengan access token tanpa kode verifier yang benar.
- Dengan demikian, meskipun kode otorisasi dicegat, itu menjadi tidak berguna tanpa verifier yang sah.
Fakta Menarik
Dalam penelitian ini, sebagian besar situs web yang diuji tidak menggunakan PKCE, sehingga masih rentan terhadap serangan seperti OAuth token theft melalui open redirect.
Oleh karena itu, implementasi PKCE sangat direkomendasikan untuk meningkatkan keamanan OAuth dan mencegah serangan pengambilalihan akun (account takeover).
Melindungi Kode Otorisasi Setelah Redirection
Dalam banyak kasus berdasarkan penelitian kami, meskipun penyerang berhasil mengarahkan pengguna ke server berbahaya, kode otorisasi sering kali tidak diteruskan. Hal ini terjadi karena kode otorisasi biasanya disertakan sebagai parameter query (misalnya, ?code=) yang tidak selalu dipertahankan dalam beberapa jenis redirect.
Perilaku ini bisa menjadi lapisan keamanan tambahan, karena mencegah penyerang menangkap kode otorisasi, meskipun mereka berhasil mengalihkan pengguna.
Bagaimana Penyerang Mengatasi Kendala Ini?
Untuk mengatasi masalah ini, penyerang bisa memanfaatkan hash fragment (URI fragment)—bagian dari URI yang mengikuti simbol #.
Mengapa hash fragment efektif?
- Saat redirect terjadi dan URI mengandung #, bagian setelah (termasuk) simbol hash tidak dikirim ke server dalam HTTP request.
- Namun, bagian ini tetap terlihat di bilah alamat browser, yang berarti JavaScript di situs penyerang bisa mengaksesnya menggunakan window.location.hash.
- Sesuai dengan RFC 3986 (halaman 24):
“…fragmen identifier tidak digunakan dalam pemrosesan URI secara spesifik; sebagai gantinya, fragmen dipisahkan dari URI sebelum dereference, sehingga informasi dalam fragmen hanya dapat diakses oleh user agent, terlepas dari skema URI.”
Dengan menyimpan kode otorisasi dalam hash fragment, penyerang dapat mengekstrak kode ini langsung dari browser dan menggunakannya untuk mengambil alih akun korban.
Cara Penyerang Memanfaatkan Hash Fragment dalam Redirection
Ada beberapa metode yang dapat digunakan untuk membuat redirection menyertakan hash fragment:
- Mengubah parameter response_mode menjadi fragment
- Cara ini didemonstrasikan oleh Frans Rosen, di mana kode otorisasi dapat dimasukkan dalam hash fragment menggunakan response_mode=fragment.
- Mengubah parameter response_type menjadi token
- Cara ini mengembalikan access token langsung dalam URI fragment (#), bukan melalui parameter query.
- Eksploitasi pada Facebook: Menggunakan response_type=code%20token
- Cara ini ditemukan oleh Aviad Carmel, di mana OAuth Facebook mengembalikan kode otorisasi dan access token dalam hash fragment secara bersamaan.
Apakah Semua Implementasi OAuth Rentan?
Tidak semua implementasi OAuth rentan terhadap metode ini.
- Beberapa klien OAuth menangani parameter ini secara berbeda, misalnya dengan membatasi mode respons hanya pada query atau form_post, sehingga metode ini tidak dapat digunakan.
- Validasi redirect_uri yang ketat juga bisa mencegah eksploitasi ini dengan hanya mengizinkan domain yang telah terdaftar sebelumnya.
- Menggunakan Proof Key for Code Exchange (PKCE) juga dapat membantu mencegah eksploitasi kode otorisasi meskipun kode tersebut berhasil dicegat.
Kesimpulan
Serangan berbasis hash fragment adalah teknik canggih yang memanfaatkan sifat browser dalam menangani URL fragment. Organisasi yang menggunakan OAuth harus memastikan bahwa implementasi mereka tidak mengizinkan mode respons yang rentan serta menggunakan mekanisme keamanan seperti PKCE dan validasi ketat pada redirect_uri untuk melindungi pengguna dari pengambilalihan akun.
Infrastruktur IT yang kuat adalah kunci pertumbuhan bisnis. cyberark indonesia menyediakan solusi terbaik, mulai dari jaringan, storage, cloud, hingga keamanan siber, yang diintegrasikan oleh iLogo Indonesia agar sesuai dengan kebutuhan bisnis Anda.
Pelajari lebih lanjut di cyberark.ilogoindonesia.id dan konsultasikan kebutuhan IT Anda dengan kami!
