Mengapa perlindungan CSRF dan CORS digunakan bersamaan?

 (smagin.fyi)
33 poin oleh GN⁺ 2025-03-04 | 1 komentar | Bagikan ke WhatsApp
  • Saat memikirkan Cross-Site Request, pada awalnya sulit memahami mengapa perlindungan CSRF dan CORS sama-sama diperlukan. Namun, untuk menjelaskannya dibutuhkan cukup banyak kata.

CSRF dan CORS

  • CSRF (Cross-Site Request Forgery)
    • Dulu cukup umum, tetapi sekarang hampir tidak lagi menjadi masalah karena sebagian besar framework web secara default menyediakan perlindungan
    • Cara serangan: pengguna dibuat mengklik formulir tertentu di situs berbahaya sehingga terdorong mengirim permintaan lintas situs
    • Cara pertahanan: memeriksa apakah permintaan tersebut berasal dari situs lain atau tidak
  • CORS (Cross-Origin Resource Sharing)
    • Bagian dari spesifikasi HTTP yang mendefinisikan cara mengizinkan permintaan lintas situs tertentu
    • Menggunakan preflight request dan header respons untuk menentukan origin mana yang boleh mengirim permintaan

Lalu, apakah permintaan lintas situs pada dasarnya diizinkan sehingga perlindungan CSRF diperlukan, atau justru pada dasarnya diblokir sehingga perlu CORS untuk mengizinkannya? Jawabannya adalah keduanya.

Cara kerja dasar

  • Kebijakan same-origin (Same-origin policy)
    • Kebijakan keamanan yang dipaksakan oleh browser
    • Secara umum, penulisan (Write) lintas situs diizinkan, tetapi pembacaan (Read) dilarang
    • Misalnya, browser mengizinkan permintaan POST melalui formulir, tetapi tidak mengizinkan responsnya dibaca
  • Kebijakan cookie SameSite
    • Pada 2019, perilaku default cookie berubah
    • Sebelumnya, cookie selalu dikirim bahkan pada permintaan lintas situs
    • Atribut SameSite baru ditambahkan, dan nilai default berubah menjadi Lax
    • Per 2025, 96% browser mendukung atribut SameSite, dan 75% mendukung nilai default baru (Lax)
    • Namun, Safari tidak menerapkannya sebagai nilai default, dan UCBrowser masih belum mendukungnya
  • Perbedaan antara site dan origin
    • Origin: kombinasi protokol + hostname + port
    • Site: kombinasi protokol + top-level domain + 1 (subdomain dan port diabaikan)

CORS

  • CORS adalah cara memberikan pengecualian pada kebijakan same-origin untuk origin tertentu
  • Sebelum mengirim permintaan, browser mengirim preflight request bertipe OPTIONS
  • Server mendefinisikan aturan izin melalui header respons (menggunakan header Access-Control-*)
  • Jenis permintaan yang dikenai CORS:
    • fetch dan XMLHttpRequest
    • web font
    • tekstur WebGL
    • gambar/frame video yang digambar dengan drawImage di canvas
    • gambar yang digunakan pada properti CSS shape-outside
  • Namun, pengiriman formulir merupakan pengecualian yang tidak dikenai CORS
    • Tag <form> pada HTML 4.0 sudah sejak lama mengizinkan permintaan lintas situs
    • Karena itu, server lama seharusnya memang sudah dirancang untuk bertahan dari serangan CSRF
    • Server harus menetapkan Access-Control-Allow-Origin untuk membagikan respons, tetapi permintaannya sendiri tetap diterima bahkan tanpa preflight request

Pertanyaan: bagaimana kebijakan SameSite dan cara ini menjaga konsistensi?

Metode perlindungan CSRF

  • Permintaan penulisan lintas situs diizinkan, tetapi responsnya tidak dibagikan
    • Sebagian besar situs web tidak ingin mengizinkan penulisan lintas situs
  • Metode pertahanan CSRF standar
    • Memasukkan token CSRF per pengguna ke dalam permintaan untuk diverifikasi
    • Cara:
      • Pengiriman formulir: tambahkan token sebagai hidden input
      • Permintaan JS: simpan di cookie atau tag meta, lalu sertakan di header atau parameter permintaan
  • Permintaan JS pada dasarnya memang diblokir secara default untuk lintas situs
    • Namun, tetap diizinkan untuk same-site request
    • Dengan menyertakan token CSRF, semua permintaan dapat diverifikasi dengan cara yang sama
  • Keuntungan keamanan tambahan
    • Bekerja dengan asumsi bahwa browser secara default harus memblokir pembacaan respons
    • Lebih aman daripada memeriksa header Origin

Pertanyaan: di beberapa framework, token CSRF diubah secara berkala. Mengapa demikian?

Peran browser

  • Inti keamanan web bergantung pada apakah browser dapat dipercaya
  • Browser:
    • menegakkan kebijakan same-origin
    • memblokir pembacaan respons jika tidak diizinkan
    • memutuskan apakah nilai default SameSite=Lax diterapkan
    • mengimplementasikan CORS dan mengirim preflight request yang aman

Kita harus mempercayai browser yang kita gunakan.

Kesimpulan

  • Jika SameSite=Lax didukung oleh 100% browser, keamanan akan lebih kuat,
    tetapi saat ini masih ada pengecualian di mana hanya permintaan POST lintas situs yang tetap diizinkan
  • Karena itu, developer tetap perlu terus mempertimbangkan perlindungan CSRF

"Internet makin aman, tetapi seiring itu kompatibilitas dengan masa lalu juga makin berkurang."

Sumber

  1. Same-origin policy
  2. caniuse SameSite cookie attribute
  3. OWASP CSRF cheatsheet
  4. CORS wiki with requirements
  5. CORS spec
  6. CORS on MDN
  7. Preflight request
  8. Origin request header
  9. Origin and Site

Bacaan terkait

1 komentar

 
GN⁺ 2025-03-04
Komentar Hacker News

  • CORS adalah mekanisme yang secara eksplisit memberi tahu browser permintaan lintas origin mana yang boleh membaca respons dari server

    • Secara default, browser memblokir skrip lintas origin untuk membaca respons
    • Jika tidak diizinkan secara eksplisit, domain peminta tidak dapat membaca respons
    • Misalnya, skrip dari evil.com dapat mengirim permintaan ke bank.com/transactions untuk mencoba membaca riwayat transaksi korban
    • Browser mengizinkan permintaan mencapai bank.com, tetapi memblokir evil.com agar tidak bisa membaca responsnya

  • Perlindungan CSRF mencegah permintaan lintas origin yang berbahaya melakukan tindakan tanpa izin atas nama pengguna yang sudah terautentikasi

    • Misalnya, skrip dari evil.com dapat mengirim permintaan agar tindakan dijalankan di bank.com (contoh: mentransfer uang ke bank.com/transfer?from=victim&to=hacker)
    • Perlindungan CSRF di sisi server bank.com akan menolaknya (kemungkinan karena permintaan tersebut tidak menyertakan token CSRF rahasia)

  • Perlindungan CSRF berkaitan dengan perlindungan tulis, sedangkan CORS berkaitan dengan perlindungan baca

  • Permintaan yang dimulai dari JS pada dasarnya tidak diizinkan lintas situs

    • Dengan menggunakan fetch() dan hanya memakai header yang diizinkan, permintaan lintas situs bisa dimulai

  • Saya rasa ada penjelasan yang lebih baik untuk topik ini

    • Menyediakan tautan blog terkait

  • Tanggapan terhadap pertanyaan di postingan blog

    • Elemen <form> di HTML 4.0 dapat mengirimkan simple request ke origin mana pun
    • Ada pertanyaan tentang bagaimana hal ini selaras dengan inisiatif SameSite

  • Pada 2022, sebuah paragraf ditambahkan ke artikel MDN tentang CORS untuk memperjelas asal-usul istilah "simple request"

    • Sebelumnya hanya disebutkan bahwa istilah itu tidak dirujuk dalam spesifikasi fetch
    • Pada 2019 belum ada penyebutan tentang perlindungan CSRF browser saat SameSite=Lax didukung atau dijadikan default

  • Membingungkan bahwa SameSite ditambahkan secara terpisah dari preflight CORS

    • Saya penasaran mengapa pembuat browser tidak mewajibkan preflight untuk semua permintaan POST lintas origin

  • Anda mungkin mengira tetap aman tanpa menggunakan csrf, tetapi beberapa library (misalnya django rest framework) dapat memproses form HTML jika header content type disetel

    • Ini memungkinkan seseorang mem-posting form ke situs pengguna dan mengirim permintaan atas nama pengguna tersebut

  • Pertanyaan tentang alasan token CSRF dirotasi

    • OWASP mengatakan ini lebih aman, tetapi saya kurang paham alasannya

  • Meminta flowchart untuk topik yang kompleks ini

    • Menginginkan platform aplikasi dan seperangkat standar yang baru

  • Hal-hal seperti ini tidak mendukung jejak diagnostik yang mudah

    • Saya berkali-kali mengalami error yang tidak transparan pada kasus penggunaan sah yang tidak dikonfigurasi dengan benar

  • Saya tidak mengerti mengapa sebelum CORS ada permintaan yang bisa dikirim ke endpoint arbitrer selain origin halaman tetapi responsnya tidak bisa dilihat

    • Saya penasaran apakah ini kebetulan masuk ke spesifikasi, sengaja dibuat dengan mengantisipasi XSS, atau browser dominan saat itu melakukannya lalu browser lain mengikuti

  • Kebingungan tentang perlindungan CSRF

    • Saya penasaran apa yang mencegah penyerang mendapatkan token CSRF dari goodsite.com, menaruhnya di badsite.com, lalu menipu Alice agar mengirim permintaan dari badsite.com ke goodsite.com