Pengantar

Content Security Policy (CSP) adalah mekanisme keamanan browser yang membantu mengurangi risiko serangan seperti Cross-Site Scripting (XSS). CSP bekerja dengan menentukan sumber konten yang boleh dijalankan oleh browser.

Namun, konfigurasi CSP yang lemah dapat membuka peluang terjadinya CSP bypass. Kondisi ini terjadi ketika attacker menemukan cara agar payload tetap dapat dijalankan meskipun aplikasi telah menggunakan CSP.

Apa Itu Content Security Policy?

CSP merupakan security policy yang dikirimkan website melalui HTTP response header atau elemen <meta>. Policy tersebut memberi tahu browser sumber konten yang diperbolehkan.

Contohnya, administrator dapat membatasi JavaScript agar hanya berasal dari domain tertentu.

CSP membantu mengurangi dampak XSS dengan membatasi sumber script, object, frame, dan resource lainnya. MDN menjelaskan bahwa CSP digunakan untuk mengontrol resource yang dapat dimuat atau dieksekusi browser dan menjadi salah satu lapisan perlindungan terhadap XSS (dikutip dari: MDN Web Docs – Content Security Policy).

baca juga : Software-Defined Perimeter (SDP): Cara Kerja dan Perannya dalam Keamanan Zero Trust

Apa Itu CSP Bypass?

CSP Bypass adalah kondisi ketika aturan CSP yang diterapkan tidak cukup kuat untuk mencegah eksekusi konten berbahaya.

Bypass tidak selalu berarti CSP memiliki bug. Sering kali, masalah berasal dari konfigurasi yang terlalu longgar atau penggunaan sumber yang sebenarnya dapat dipercaya tetapi memiliki fitur yang dapat disalahgunakan.

Beberapa penyebab umum meliputi:

  • Penggunaan 'unsafe-inline'.
  • Penggunaan 'unsafe-eval'.
  • Penggunaan wildcard seperti *.
  • Terlalu banyak domain pada script-src.
  • Trusted domain yang memiliki konten yang dapat dikontrol pengguna.
  • Policy yang tidak membatasi sumber script dengan baik.

Mengapa CSP Bisa Di-bypass?

CSP hanya efektif jika policy dirancang dengan tepat.

Penggunaan unsafe-inline

Directive 'unsafe-inline' mengizinkan inline JavaScript tertentu. Kondisi tersebut dapat mengurangi perlindungan CSP terhadap serangan XSS.

Karena itu, penggunaan inline script sebaiknya diganti dengan mekanisme yang lebih aman seperti nonce atau hash.

Penggunaan unsafe-eval

Directive 'unsafe-eval' mengizinkan penggunaan mekanisme evaluasi kode tertentu yang biasanya dibatasi CSP.

Jika tidak benar-benar dibutuhkan, directive ini sebaiknya dihindari.

Wildcard yang Terlalu Luas

Policy seperti:

script-src *

memberikan ruang yang sangat luas untuk sumber JavaScript.

Konfigurasi tersebut tentu lebih lemah dibandingkan policy yang hanya mengizinkan sumber yang benar-benar diperlukan.

Trusted Domain Tidak Selalu Aman

Salah satu kesalahan dalam membuat CSP adalah menganggap semua resource dari domain terpercaya pasti aman.

Misalnya, sebuah aplikasi mengizinkan JavaScript dari domain tertentu. Jika domain tersebut memiliki fitur yang memungkinkan konten pengguna disajikan sebagai JavaScript, policy dapat menjadi lebih lemah.

Dengan demikian, trusted source harus benar-benar dipercaya. OWASP merekomendasikan penggunaan CSP yang ketat dan menjelaskan bahwa konfigurasi berbasis nonce atau hash dapat memberikan perlindungan yang lebih baik dibandingkan allowlist yang terlalu luas (dikutip dari: OWASP – Content Security Policy Cheat Sheet).

Nonce dan Hash untuk CSP

Salah satu cara memperkuat CSP adalah menggunakan nonce.

Nonce merupakan nilai acak yang dibuat untuk setiap response. Script inline hanya dapat dijalankan jika memiliki nonce yang sesuai dengan policy.

Contoh sederhana:

Content-Security-Policy:
script-src 'nonce-randomValue'

HTML kemudian menggunakan nonce yang sama:

<script nonce="randomValue">
    // trusted script
</script>

Browser hanya menjalankan script yang memiliki nonce valid.

Selain nonce, CSP juga dapat menggunakan hash untuk menentukan script inline tertentu yang diizinkan.

Pendekatan ini lebih ketat karena browser tidak hanya mempercayai seluruh domain.

baca juga : Pass-the-Ticket (PtT) Attack: Cara Kerja dan Ancaman terhadap Keamanan Kerberos

CSP Bypass vs XSS

CSP bypass dan XSS merupakan dua hal yang berbeda.

XSS adalah kerentanan yang memungkinkan script berbahaya dijalankan dalam konteks aplikasi.

Sementara itu, CSP bypass adalah teknik atau kondisi yang memungkinkan pembatasan CSP dilewati sehingga script dapat dieksekusi meskipun terdapat policy.

Dengan kata lain, CSP seharusnya menjadi lapisan pertahanan tambahan, bukan pengganti sanitasi dan validasi input.

Cara Memperkuat CSP

Beberapa praktik berikut dapat diterapkan untuk mengurangi risiko CSP bypass.

Gunakan Policy yang Ketat

Batasi sumber script hanya pada resource yang benar-benar diperlukan.

Hindari unsafe-inline

Gunakan nonce atau hash jika aplikasi membutuhkan inline script.

Hindari unsafe-eval

Jangan mengaktifkannya jika tidak diperlukan oleh aplikasi.

Batasi Trusted Sources

Jangan memasukkan terlalu banyak domain ke dalam script-src.

Gunakan Reporting

CSP menyediakan mekanisme pelaporan yang dapat membantu administrator mengetahui pelanggaran policy.

Tetap Lakukan Input Sanitization

CSP bukan pengganti validasi dan sanitasi input. Aplikasi tetap harus memperbaiki sumber XSS secara langsung.

Cara Menguji CSP

Pengujian CSP dapat dilakukan dengan melihat response header website.

Contohnya:

Content-Security-Policy:
default-src 'self';
script-src 'self';
object-src 'none';

Periksa apakah policy terlalu longgar atau memiliki directive yang tidak diperlukan.

Developer juga dapat menggunakan CSP violation reports untuk melihat resource yang diblokir browser.

Pengujian sebaiknya dilakukan pada staging environment terlebih dahulu agar perubahan policy tidak mengganggu aplikasi production.

baca juga : Master File Table (MFT) Forensics: Mengungkap Jejak File yang Tersembunyi di NTFS

Kesimpulan

Content Security Policy (CSP) Bypass terjadi ketika aturan CSP yang diterapkan tidak cukup kuat untuk mencegah eksekusi konten yang tidak diinginkan.

Penyebabnya dapat berasal dari penggunaan 'unsafe-inline', 'unsafe-eval', wildcard, atau trusted source yang terlalu luas.

CSP sebaiknya digunakan sebagai defense-in-depth bersama validasi input, output encoding, dan proteksi XSS lainnya. Penggunaan nonce atau hash juga dapat membantu membuat policy lebih ketat.

Dengan konfigurasi yang tepat, CSP dapat menjadi lapisan keamanan penting untuk melindungi aplikasi web dari berbagai risiko XSS.

Related Posts: