Mencegah XSS dengan CSP atau Content-Security-Policy

Cara menerapkan CSP berdasarkan nonce skrip atau hash sebagai pertahanan mendalam terhadap skrip lintas situs.

Mengapa anda harus menerapkan Kebijakan Kemanan Konten (CSP) yang ketat?

Skrip lintas situs (XSS) —kemampuan untuk memasukkan skrip berbahaya ke dalam aplikasi web — telah menjadi salah satu kerentanan keamanan web terbesar selama lebih dari satu dekade.

Kebijakan Keamanan Konten (CSP) adalah lapisan keamanan tambahan yang membantu mengurangi XSS. Mengonfigurasi CSP melibatkan penambahan header HTTP Kebijakan Keamanan Konten ke halaman web dan nilai pengaturan untuk mengontrol sumber daya apa yang diizinkan untuk memuat agen pengguna untuk halaman itu. Artikel ini menjelaskan cara menggunakan CSP berdasarkan nonce atau hashes untuk mengurangi XSS, bukan CSP berbasis host-allowlist yang umum digunakan, yang sering kali membuat halaman terbuka ke XSS karena dapat dilewati di sebagian besar konfigurasi .

Kata Kunci : Nonce adalah nomor acak yang hanya digunakan sekali yang dapat digunakan untuk menandai <script>tag sebagai tepercaya.

Istilah Kunci :
Fungsi hash adalah fungsi matematika yang mengubah nilai input menjadi nilai numerik terkompresi — hash. Sebuah hash (seperti SHA-256 ) dapat digunakan untuk menandai inline <script>tag sebagai terpercaya.

Kebijakan Keamanan Konten berdasarkan nonce atau hashes sering disebut CSP ketat . Saat aplikasi menggunakan CSP yang ketat, penyerang yang menemukan kelemahan injeksi HTML umumnya tidak akan dapat menggunakannya untuk memaksa browser menjalankan skrip berbahaya dalam konteks dokumen yang rentan. Ini karena CSP yang ketat hanya mengizinkan skrip atau skrip yang di-hash dengan nilai nonce yang benar yang dibuat di server, sehingga penyerang tidak dapat mengeksekusi skrip tanpa mengetahui nonce yang benar untuk respons yang diberikan.

Untuk melindungi situs Anda dari XSS, pastikan untuk membersihkan masukan pengguna dan menggunakan CSP sebagai lapisan keamanan ekstra. CSP adalah teknik pertahanan mendalam yang dapat mencegah eksekusi skrip berbahaya, tetapi ini bukan pengganti untuk menghindari (dan segera memperbaiki) bug XSS.

Mengapa CSP ketat direkomendasikan daripada CSP yang diizinkan

Jika situs Anda sudah memiliki CSP yang terlihat seperti ini script-src www.googleapis.com:, mungkin tidak efektif melawan skrip lintas situs! Jenis CSP ini disebut CSP allowlist dan memiliki beberapa kelemahan:

• Ini membutuhkan banyak penyesuaian.
• Ini dapat dilewati di sebagian besar konfigurasi .

Hal ini membuat CSP allowlist umumnya tidak efektif dalam mencegah penyerang mengeksploitasi XSS. Itulah mengapa disarankan untuk menggunakan CSP yang ketat berdasarkan nonce atau hash kriptografi, yang menghindari perangkap yang diuraikan di atas.

Allowlist CSP

• Tidak melindungi situs Anda secara efektif. ❌ 
• Harus sangat disesuaikan. 😬

CSP yang ketat

• Secara efektif melindungi situs Anda. ✅
• Selalu memiliki struktur yang sama. 😌

Apa itu Kebijakan Keamanan Konten yang ketat? 👻

Kebijakan Keamanan Konten yang ketat memiliki struktur berikut dan diaktifkan dengan menyetel salah satu dari tajuk tanggapan HTTP berikut:

• CSP ketat berbasis nonce

Content-Security-Policy:
  script-src 'nonce-{RANDOM}' 'strict-dynamic';
  object-src 'none';
 base-uri 'none';

 

• CSP ketat berbasis hash

 

Content-Security-Policy:

  script-src 'sha256-{HASHED_INLINE_SCRIPT}' 'strict-dynamic';

  object-src 'none'; 

base-uri 'none'; 

 

Ini adalah versi CSP ketat yang paling dilucuti. Anda harus menyesuaikannya agar efektif di seluruh browser.

Properti berikut membuat CSP seperti di atas "ketat" dan karenanya aman:

• Menggunakan nonce 'nonce-{RANDOM}'atau hashes 'sha256-{HASHED_INLINE_SCRIPT}'untuk menunjukkan <script>tag mana yang dipercaya oleh pengembang situs dan harus diizinkan untuk dijalankan di browser pengguna.

• Menyetel 'strict-dynamic'untuk mengurangi upaya penerapan CSP berbasis nonce atau hash dengan secara otomatis mengizinkan eksekusi skrip yang dibuat oleh skrip yang sudah tepercaya. Ini juga membuka blokir penggunaan sebagian besar pustaka dan widget JavaScript pihak ketiga.

• Tidak berdasarkan pada daftar yang diizinkan URL dan oleh karena itu tidak mengalami pengabaian CSP yang umum .

• Memblokir skrip inline yang tidak tepercaya seperti inline event handler atau javascript:URI.

• Membatasi object-srcuntuk menonaktifkan plugin berbahaya seperti Flash.

• Membatasi base-uriuntuk memblokir injeksi <base>tag. Ini mencegah penyerang mengubah lokasi skrip yang dimuat dari URL relatif.

Keuntungan lain dari CSP yang ketat adalah CSP selalu memiliki struktur yang sama dan tidak perlu disesuaikan untuk aplikasi Anda.

Mengadopsi CSP yang ketat

Untuk mengadopsi CSP yang ketat, Anda perlu:

1. Putuskan apakah aplikasi Anda harus menyetel CSP berbasis nonce atau hash.
2. Salin CSP dari bagian Apa itu Kebijakan Keamanan Konten yang ketat dan setel sebagai header respons di seluruh aplikasi Anda.
3. Template HTML Refactor dan kode sisi klien untuk menghapus pola yang tidak kompatibel dengan CSP.
4. Tambahkan fallback untuk mendukung Safari dan browser lama.
5. Terapkan CSP Anda.

Anda dapat menggunakan audit Praktik Terbaik Lighthouse (v7.3.0 dan yang lebih baru) selama proses ini untuk memeriksa apakah situs Anda memiliki CSP, dan apakah cukup ketat untuk menjadi efektif terhadap XSS.

Langkah 1: Putuskan apakah Anda memerlukan CSP berbasis nonce atau hash

Ada dua jenis CSP yang ketat, nonce- dan berbasis hash. Begini cara kerjanya:

• CSP berbasis nonce : Anda membuat nomor acak pada waktu proses , memasukkannya ke dalam CSP, dan mengaitkannya dengan setiap tag skrip di halaman Anda. Penyerang tidak dapat menyertakan dan menjalankan skrip berbahaya di halaman Anda, karena mereka perlu menebak nomor acak yang benar untuk skrip tersebut. Ini hanya berfungsi jika nomor tersebut tidak dapat ditebak dan baru dibuat saat runtime untuk setiap respons.
• CSP berbasis hash: Hash dari setiap tag skrip sebaris ditambahkan ke CSP. Perhatikan bahwa setiap skrip memiliki hash yang berbeda. Penyerang tidak dapat menyertakan dan menjalankan skrip berbahaya di halaman Anda, karena hash skrip tersebut harus ada di CSP Anda.

Kriteria untuk memilih pendekatan CSP yang ketat:

Kriteria untuk memilih pendekatan CSP yang ketat

CSP berbasis nonce	Untuk halaman HTML yang dirender di server tempat Anda dapat membuat token acak baru (nonce) untuk setiap respons.
CSP berbasis hash	Untuk halaman HTML disajikan secara statis atau yang perlu di-cache. Misalnya, aplikasi web satu halaman yang dibuat dengan kerangka kerja seperti Angular, React, atau lainnya, yang disajikan secara statis tanpa rendering sisi servernya.

Langkah 2: Tetapkan CSP yang ketat dan siapkan skrip Anda

Saat mengatur CSP, Anda memiliki beberapa opsi:

• Mode hanya laporan ( Content-Security-Policy-Report-Only) atau mode penerapan ( Content-Security-Policy). Dalam hanya laporan, CSP belum akan memblokir sumber daya — tidak ada yang akan rusak — tetapi Anda akan dapat melihat kesalahan dan menerima laporan tentang apa yang akan diblokir. Secara lokal, saat Anda sedang dalam proses menyetel CSP, ini tidak terlalu penting, karena kedua mode akan menampilkan kesalahan di konsol browser. Jika ada, mode penegakan akan mempermudah Anda untuk melihat sumber daya yang diblokir dan mengubah CSP Anda, karena halaman Anda akan terlihat rusak. Mode hanya laporan menjadi paling berguna nanti dalam proses (lihat Langkah 5 ).
• Header atau <meta>tag HTML . Untuk pengembangan lokal, <meta>tag mungkin lebih nyaman untuk menyesuaikan CSP Anda dan dengan cepat melihat bagaimana pengaruhnya terhadap situs Anda. Namun:
• Nanti, saat menerapkan CSP Anda dalam produksi, disarankan untuk menyetelnya sebagai header HTTP.
• Jika Anda ingin menyetel CSP dalam mode hanya laporan, Anda harus menyetelnya sebagai tajuk — tag meta CSP tidak mendukung mode hanya laporan.

Langkah 3: Refactor template HTML dan kode sisi klien untuk menghapus pola yang tidak kompatibel dengan CSP

Penangan kejadian sebaris (seperti onclick="…", onerror="…") dan JavaScript URI ( <a href="javascript:…">) bisa digunakan untuk menjalankan skrip. Ini berarti bahwa penyerang yang menemukan bug XSS dapat menginjeksi HTML jenis ini dan mengeksekusi JavaScript berbahaya. CSP berbasis nonce atau hash melarang penggunaan markup tersebut. Jika situs Anda menggunakan salah satu pola yang dijelaskan di atas, Anda harus mengubah pola tersebut menjadi alternatif yang lebih aman.

Jika Anda mengaktifkan CSP di langkah sebelumnya, Anda akan dapat melihat pelanggaran CSP di konsol setiap kali CSP memblokir pola yang tidak kompatibel.

Dalam kebanyakan kasus, perbaikannya langsung:

Untuk memfaktor ulang penangan kejadian sebaris, tulis ulang untuk ditambahkan dari blok JavaScript

Diblokir oleh CSP

<span onclick="doThings();">A thing.</span>

CSP akan memblokir penangan kejadian sebaris.

Diizinkan oleh CSP

<span id="things">A thing.</span>
<script nonce="${nonce}">
  document.getElementById('things')
          .addEventListener('click', doThings);
</script>

CSP akan mengizinkan penangan acara yang didaftarkan melalui JavaScript.

Untuk javascript:URI, Anda dapat menggunakan pola yang serupa

Diblokir oleh CSP

<a href="javascript:linkClicked()">rootsec</a>

CSP akan memblokir javascript: URI.

Diizinkan oleh CSP

<a id="rootsec">rootsec</a>
<script nonce="${nonce}">
  document.getElementById('rootsec')
          .addEventListener('click', linkClicked);
</script>

CSP akan mengizinkan penangan acara yang didaftarkan melalui JavaScript.

Penggunaan eval()di JavaScript

Jika aplikasi Anda menggunakan eval()untuk mengonversi serialisasi string JSON menjadi objek JS, Anda harus memfaktor ulang instance tersebut menjadi JSON.parse(), yang juga lebih cepat .

Jika Anda tidak dapat menghapus semua penggunaan eval(), Anda masih dapat menetapkan CSP berbasis nonce yang ketat, tetapi Anda harus menggunakan 'unsafe-eval'kata kunci CSP yang akan membuat kebijakan Anda sedikit kurang aman.

Anda dapat menemukan ini dan lebih banyak contoh pemfaktoran ulang semacam itu di Codelab CSP yang ketat ini: CLICK HERE

Langkah 4: Tambahkan fallback untuk mendukung Safari dan browser lama

CSP didukung oleh semua browser utama, tetapi Anda memerlukan dua fallback:

• Penggunaan 'strict-dynamic'memerlukan penambahan https:sebagai cadangan untuk Safari, satu-satunya browser utama yang tidak mendukung 'strict-dynamic'. Dengan melakukan itu:

  • Semua browser yang mendukung 'strict-dynamic'akan mengabaikan https:fallback, jadi ini tidak akan mengurangi kekuatan kebijakan.
  • Di Safari, skrip yang bersumber dari luar akan diizinkan untuk dimuat hanya jika berasal dari HTTPS. Ini kurang aman daripada CSP ketat – ini adalah fallback – tetapi masih akan mencegah penyebab XSS umum tertentu seperti injeksi javascript:URI karena 'unsafe-inline'tidak ada atau diabaikan jika ada hash atau nonce.

• Untuk memastikan kompatibilitas dengan versi browser yang sangat lama (4+ tahun), Anda dapat menambahkan 'unsafe-inline'sebagai fallback. Semua browser terbaru akan mengabaikan 'unsafe-inline'jika ada nonce atau hash CSP.

Langkah 5: Terapkan CSP Anda

Setelah mengonfirmasi bahwa tidak ada skrip sah yang diblokir oleh CSP di lingkungan pengembangan lokal, Anda dapat melanjutkan dengan menerapkan CSP ke lingkungan produksi (pementasan, lalu) Anda:

1. (Opsional) Terapkan CSP Anda dalam mode hanya laporan menggunakan Content-Security-Policy-Report-Onlyheader. Pelajari lebih lanjut tentang API Pelaporan . Mode hanya laporan berguna untuk menguji perubahan yang berpotensi merusak seperti CSP baru dalam produksi, sebelum benar-benar menerapkan pembatasan CSP. Dalam mode hanya laporan, CSP Anda tidak memengaruhi perilaku aplikasi Anda (tidak ada yang benar-benar rusak). Namun browser masih akan menghasilkan kesalahan konsol dan laporan pelanggaran ketika pola yang tidak kompatibel dengan CSP ditemukan (sehingga Anda dapat melihat apa yang mungkin rusak untuk pengguna akhir Anda).
2. Setelah Anda yakin bahwa CSP Anda tidak akan menyebabkan kerusakan bagi pengguna akhir Anda, terapkan CSP Anda menggunakan Content-Security-Policyheader respons. Hanya setelah Anda menyelesaikan langkah ini, CSP akan mulai melindungi aplikasi Anda dari XSS . Menyetel CSP Anda melalui sisi server header HTTP lebih aman daripada menyetelnya sebagai <meta>tag; gunakan tajuk jika Anda bisa.

Gotchas!

Pastikan CSP yang Anda gunakan "ketat" dengan memeriksanya di CSP Service Checker atau Lighthouse. Ini sangat penting, karena bahkan perubahan kecil pada suatu kebijakan dapat secara signifikan mengurangi keamanannya.

 

Batasan

Secara umum, CSP yang ketat memberikan lapisan keamanan tambahan yang kuat yang membantu mengurangi XSS. Dalam kebanyakan kasus, CSP mengurangi permukaan serangan secara signifikan (pola berbahaya seperti javascript:URI benar-benar dimatikan). Namun, berdasarkan jenis CSP yang Anda gunakan (nonce, hashes, dengan atau tanpa 'strict-dynamic'), ada kasus di mana CSP tidak melindungi:

• Jika Anda nonce skrip, tetapi ada injeksi langsung ke dalam tubuh atau ke srcparameter <script>elemen itu.
• Jika ada suntikan ke lokasi skrip yang dibuat secara dinamis ( document.createElement('script')), termasuk ke dalam fungsi pustaka apa pun yang membuat scriptsimpul DOM berdasarkan nilai argumennya. Ini termasuk beberapa API umum seperti jQuery .html(), serta .get()dan .post()di jQuery <3.0.
• Jika ada suntikan template di aplikasi AngularJS lama. Penyerang yang dapat memasukkan template AngularJS dapat menggunakannya untuk mengeksekusi JavaScript sewenang-wenang .
• Jika kebijakan berisi 'unsafe-eval', injeksi ke eval(), setTimeout()dan beberapa API lain yang jarang digunakan.

PENUTUP

Pengembang dan teknisi keamanan harus memberikan perhatian khusus pada pola tersebut selama tinjauan kode dan audit keamanan. Anda dapat menemukan detail selengkapnya tentang kasus yang dijelaskan di atas dalam presentasi CSP ini .