FixVibe
Covered by FixVibehigh

Kesalahan Konfigurasi CORS: Risiko Kebijakan yang Terlalu Permisif

Berbagi Sumber Daya Lintas Asal (CORS) adalah mekanisme browser yang dirancang untuk melonggarkan Kebijakan Asal yang Sama (SOP). Meskipun diperlukan untuk aplikasi web modern, penerapan yang tidak tepat—seperti mengulangi header Asal pemohon atau memasukkan asal 'null' ke dalam daftar putih—dapat memungkinkan situs jahat mengambil data pribadi pengguna.

CWE-942

Dampak

Penyerang dapat mencuri data sensitif dan terautentikasi dari pengguna aplikasi rentan [S2]. Jika pengguna mengunjungi situs web jahat saat masuk ke aplikasi yang rentan, situs jahat tersebut dapat membuat permintaan lintas asal ke API aplikasi dan membaca respons [S1][S2]. Hal ini dapat menyebabkan pencurian informasi pribadi, termasuk profil pengguna, token CSRF, atau pesan pribadi [S2].

Akar Penyebab

CORS adalah mekanisme berbasis header HTTP yang memungkinkan server menentukan asal (domain, skema, atau port) mana yang diizinkan untuk memuat sumber daya [S1]. Kerentanan biasanya muncul ketika kebijakan CORS server terlalu fleksibel atau [S2] diterapkan dengan buruk:

  • Reflected Origin Header: Beberapa server membaca header Origin dari permintaan klien dan mengulanginya kembali di header respons Access-Control-Allow-Origin (ACAO) [S2]. Ini secara efektif memungkinkan situs web mana pun mengakses sumber daya [S2].
  • Wildcard yang Salah Konfigurasi: Meskipun wildcard * mengizinkan asal mana pun untuk mengakses sumber daya, wildcard tersebut tidak dapat digunakan untuk permintaan yang memerlukan kredensial (seperti cookie atau header Otorisasi) [S3]. Pengembang sering kali mencoba menyiasatinya dengan membuat header ACAO secara dinamis berdasarkan permintaan [S2].
  • Memasukkan 'null' ke dalam daftar putih: Beberapa aplikasi memasukkan asal null ke dalam daftar putih, yang dapat dipicu oleh permintaan yang dialihkan atau file lokal, sehingga situs jahat dapat menyamar sebagai asal null untuk mendapatkan akses [S2][S3].
  • Kesalahan Parsing: Kesalahan dalam pencocokan regex atau string saat memvalidasi header Origin dapat memungkinkan penyerang menggunakan domain seperti trusted-domain.com.attacker.com [S2].

Penting untuk dicatat bahwa CORS bukan perlindungan terhadap Pemalsuan Permintaan Lintas Situs (CSRF) [S2].

Perbaikan Beton

  • Gunakan Daftar Putih Statis: Hindari membuat header Access-Control-Allow-Origin secara dinamis dari header Origin permintaan [S2]. Sebagai gantinya, bandingkan asal permintaan dengan daftar domain tepercaya [S3] yang dikodekan secara hardcode.
  • Hindari Asal 'null': Jangan pernah menyertakan null dalam daftar putih asal yang diizinkan [S2].
  • Batasi Kredensial: Hanya setel Access-Control-Allow-Credentials: true jika benar-benar diperlukan untuk interaksi lintas asal tertentu [S3].
  • Gunakan Validasi yang Tepat: Jika Anda harus mendukung beberapa asal, pastikan logika validasi untuk header Origin kuat dan tidak dapat dilewati oleh subdomain atau domain yang tampak serupa [S2].

Bagaimana FixVibe mengujinya

FixVibe sekarang menyertakan ini sebagai pemeriksaan aktif yang terjaga keamanannya. Setelah verifikasi domain, active.cors mengirimkan permintaan API asal yang sama dengan asal penyerang sintetis dan meninjau header respons CORS. Laporan ini mencerminkan asal usul yang sewenang-wenang, CORS dengan kredensial wildcard, dan CORS terbuka lebar pada titik akhir API non-publik sekaligus menghindari gangguan aset publik.