Memitigasi pembuatan skrip lintas situs (XSS) dengan Kebijakan Keamanan Konten (CSP) yang ketat

Lukas Weichselbaum

Browser Support

• 52
• 79
• 52
• 15.4

Perhatian: Satu atau beberapa demo di halaman ini tidak lagi berfungsi, karena Glitch telah mengakhiri hosting.

Pembuatan skrip lintas situs (XSS), kemampuan untuk menginjeksikan 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. Untuk mengonfigurasi CSP, tambahkan header HTTP Content-Security-Policy ke halaman web dan tetapkan nilai yang mengontrol resource yang dapat dimuat agen pengguna untuk halaman tersebut.

Halaman ini menjelaskan cara menggunakan CSP berdasarkan nonce atau hash untuk mengurangi XSS, bukan CSP berbasis daftar host yang diizinkan yang umum digunakan dan sering membuat halaman rentan terhadap XSS karena dapat diabaikan di sebagian besar konfigurasi.

Istilah utama: Nonce adalah angka acak yang hanya digunakan sekali dan dapat Anda gunakan untuk menandai tag <script> sebagai tepercaya.

Istilah kunci: Fungsi hash adalah fungsi matematika yang mengonversi nilai input menjadi nilai numerik terkompresi yang disebut hash. Anda dapat menggunakan hash (misalnya, SHA-256) untuk menandai tag <script> inline sebagai tepercaya.

Kebijakan Keamanan Konten yang didasarkan pada nonce atau hash sering disebut CSP ketat. Saat aplikasi menggunakan CSP yang ketat, penyerang yang menemukan kelemahan injeksi HTML umumnya tidak dapat menggunakannya untuk memaksa browser menjalankan skrip berbahaya dalam dokumen yang rentan. Hal ini karena CSP ketat hanya mengizinkan skrip yang di-hash atau skrip dengan nilai nonce yang benar yang dihasilkan di server, sehingga penyerang tidak dapat mengeksekusi skrip tanpa mengetahui nonce yang benar untuk respons tertentu.

Catatan: Untuk melindungi situs Anda dari XSS, pastikan untuk membersihkan input pengguna dan gunakan CSP sebagai lapisan keamanan tambahan. CSP adalah teknik defense-in-depth yang dapat mencegah eksekusi skrip berbahaya, tetapi bukan pengganti untuk menghindari dan segera memperbaiki bug XSS.

Mengapa Anda harus menggunakan CSP ketat?

Jika situs Anda sudah memiliki CSP yang terlihat seperti script-src www.googleapis.com, mungkin CSP tersebut tidak efektif terhadap cross-site. Jenis CSP ini disebut CSP daftar yang diizinkan. WAF memerlukan banyak penyesuaian dan dapat dilewati oleh penyerang.

CSP ketat yang didasarkan pada nonce atau hash kriptografis dapat menghindari masalah ini.

Struktur CSP ketat

Kebijakan Keamanan Konten ketat dasar menggunakan salah satu header respons HTTP berikut:

CSP ketat berbasis nonce

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

Cara kerja CSP ketat berbasis nonce.

CSP ketat berbasis hash

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

Catatan: CSP ketat dasar memerlukan beberapa penyesuaian agar efektif di berbagai browser. Lihat Menambahkan penggantian untuk mendukung Safari dan browser lama untuk mengetahui detailnya.

Properti berikut membuat CSP seperti ini "ketat" dan oleh karena itu aman:

• CSP menggunakan nonce 'nonce-{RANDOM}' atau hash 'sha256-{HASHED_INLINE_SCRIPT}' untuk menunjukkan tag <script> mana yang dipercaya oleh developer situs untuk dieksekusi di browser pengguna.
• 'strict-dynamic' mengurangi upaya men-deploy CSP berbasis nonce atau hash dengan otomatis mengizinkan eksekusi skrip yang dibuat oleh skrip tepercaya. Hal ini juga membuka blokir penggunaan sebagian besar library dan widget JavaScript pihak ketiga.
• Strict CSP tidak didasarkan pada daftar URL yang diizinkan, sehingga tidak mengalami bypass CSP umum.
• Kebijakan ini memblokir skrip inline yang tidak tepercaya seperti pengendali peristiwa inline atau URI javascript:.
• Kebijakan ini membatasi object-src untuk menonaktifkan plugin berbahaya seperti Flash.
• Setelan ini membatasi base-uri untuk memblokir injeksi tag <base>. Tindakan ini mencegah penyerang mengubah lokasi skrip yang dimuat dari URL relatif.

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

Menerapkan CSP ketat

Untuk menerapkan CSP ketat, Anda harus:

1. Tentukan apakah aplikasi Anda harus menetapkan CSP berbasis nonce atau hash.
2. Salin CSP dari bagian Struktur CSP ketat dan tetapkan sebagai header respons di seluruh aplikasi Anda.
3. Lakukan pemfaktoran ulang template HTML dan kode sisi klien untuk menghapus pola yang tidak kompatibel dengan CSP.
4. Deploy CSP Anda.

Anda dapat menggunakan audit Praktik Terbaik Lighthouse (v7.3.0 dan yang lebih tinggi dengan flag --preset=experimental) selama proses ini untuk memeriksa apakah situs Anda memiliki CSP, dan apakah CSP tersebut cukup ketat untuk efektif terhadap XSS.

Jika situs Anda tidak memiliki CSP, Lighthouse akan menampilkan peringatan ini.

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

Berikut cara kerja kedua jenis CSP ketat:

CSP berbasis nonce

Dengan CSP berbasis nonce, Anda membuat angka acak saat runtime, menyertakannya dalam CSP, dan mengaitkannya dengan setiap tag skrip di halaman Anda. Penyerang tidak dapat menyertakan atau menjalankan skrip berbahaya di halaman Anda, karena mereka harus menebak angka acak yang benar untuk skrip tersebut. Hal ini hanya berfungsi jika angkanya tidak dapat ditebak, dan baru dibuat saat runtime untuk setiap respons.

Gunakan CSP berbasis nonce untuk halaman HTML yang dirender di server. Untuk halaman ini, Anda dapat membuat angka acak baru untuk setiap respons.

CSP berbasis hash

Untuk CSP berbasis hash, hash setiap tag skrip inline ditambahkan ke CSP. Setiap skrip memiliki hash yang berbeda. Penyerang tidak dapat menyertakan atau menjalankan skrip berbahaya di halaman Anda, karena hash skrip tersebut harus ada di CSP Anda agar dapat dijalankan.

Gunakan CSP berbasis hash untuk halaman HTML yang disajikan secara statis, atau halaman yang perlu di-cache. Misalnya, Anda dapat menggunakan CSP berbasis hash untuk aplikasi web satu halaman yang dibuat dengan framework seperti Angular, React, atau lainnya, yang disajikan secara statis tanpa rendering sisi server.

Langkah 2: Tetapkan CSP yang ketat dan siapkan skrip Anda

Saat menetapkan CSP, Anda memiliki beberapa opsi:

• Mode hanya laporan (Content-Security-Policy-Report-Only) atau mode diterapkan (Content-Security-Policy). Dalam mode hanya laporan, CSP belum akan memblokir resource, sehingga tidak ada yang rusak di situs Anda, tetapi Anda dapat melihat error dan mendapatkan laporan untuk apa pun yang seharusnya diblokir. Secara lokal, saat Anda menetapkan CSP, hal ini tidak terlalu penting, karena kedua mode menampilkan error di konsol browser. Mode penerapan dapat membantu Anda menemukan resource yang diblokir oleh draf CSP, karena pemblokiran resource dapat membuat halaman Anda terlihat rusak. Mode hanya laporan akan menjadi paling berguna nanti dalam prosesnya (lihat Langkah 5).
• Header atau tag <meta> HTML. Untuk pengembangan lokal, tag <meta> dapat lebih mudah digunakan untuk menyesuaikan CSP dan melihat pengaruhnya terhadap situs Anda dengan cepat. Namun:
  • Nantinya, saat men-deploy CSP dalam produksi, sebaiknya tetapkan sebagai header HTTP.
  • Jika ingin menetapkan CSP dalam mode hanya laporan, Anda harus menetapkannya sebagai header, karena tag meta CSP tidak mendukung mode hanya laporan.

Opsi A: CSP berbasis nonce

Tetapkan header respons HTTP Content-Security-Policy berikut di aplikasi Anda:

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

Perhatian: Ganti placeholder {RANDOM} dengan nonce acak yang dibuat ulang pada setiap respons server.

Membuat nonce untuk CSP

Nonce adalah angka acak yang hanya digunakan sekali per pemuatan halaman. CSP berbasis nonce hanya dapat mengurangi XSS jika penyerang tidak dapat menebak nilai nonce. Nonce CSP harus:

• Nilai acak yang kuat secara kriptografis (idealnya panjangnya 128+ bit)
• Dibuat baru untuk setiap respons
• Dienkode dengan base64

Berikut beberapa contoh cara menambahkan nonce CSP dalam framework sisi server:

• Django (python)
• Express (JavaScript):

const app = express();

app.get('/', function(request, response) {
  // Generate a new random nonce value for every response.
  const nonce = crypto.randomBytes(16).toString("base64");

  // Set the strict nonce-based CSP response header
  const csp = `script-src 'nonce-${nonce}' 'strict-dynamic'; object-src 'none'; base-uri 'none';`;
  response.set("Content-Security-Policy", csp);

  // Every <script> tag in your application should set the `nonce` attribute to this value.
  response.render(template, { nonce: nonce });
});

Menambahkan atribut nonce ke elemen <script>

Dengan CSP berbasis nonce, setiap elemen <script> harus memiliki atribut nonce yang cocok dengan nilai nonce acak yang ditentukan di header CSP. Semua skrip dapat memiliki nonce yang sama. Langkah pertama adalah menambahkan atribut ini ke semua skrip agar CSP mengizinkannya.

Opsi B: Header Respons CSP Berbasis Hash

Tetapkan header respons HTTP Content-Security-Policy berikut di aplikasi Anda:

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

Untuk beberapa skrip inline, sintaksisnya adalah sebagai berikut: 'sha256-{HASHED_INLINE_SCRIPT_1}' 'sha256-{HASHED_INLINE_SCRIPT_2}'.

Perhatian: Anda harus mengganti placeholder {HASHED_INLINE_SCRIPT} dengan hash SHA-256 berenkode base64 dari skrip inline yang dapat digunakan untuk memuat skrip lain (lihat bagian berikutnya). Anda dapat menghitung hash SHA dari blok <script> inline statis dengan alat ini. Alternatifnya adalah memeriksa peringatan pelanggaran CSP di Chrome DevTools, yang berisi hash skrip yang diblokir, dan menambahkan hash ini ke kebijakan sebagai 'sha256-…'. Browser kini dapat memblokir skrip apa pun yang dimasukkan penyerang, karena hanya mengizinkan skrip inline yang di-hash dan skrip apa pun yang ditambahkan secara dinamis.

Memuat skrip bersumber secara dinamis

Anda dapat memuat skrip pihak ketiga secara dinamis menggunakan skrip inline.

Contoh cara menyisipkan skrip.

Diizinkan oleh CSP

<script>
  var scripts = [ 'https://example.org/foo.js', 'https://example.org/bar.js'];

  scripts.forEach(function(scriptUrl) {
    var s = document.createElement('script');
    s.src = scriptUrl;
    s.async = false; // to preserve execution order
    document.head.appendChild(s);
  });
</script>

Agar skrip ini dapat berjalan, Anda harus menghitung hash skrip inline dan menambahkannya ke header respons CSP, menggantikan placeholder {HASHED_INLINE_SCRIPT}. Untuk mengurangi jumlah hash, Anda dapat menggabungkan semua skrip inline menjadi satu skrip. Untuk melihat cara kerjanya, lihat contoh ini dan kode-nya.

Diblokir oleh CSP

<script src="https://example.org/foo.js"></script>
<script src="https://example.org/bar.js"></script>

CSP memblokir skrip ini karena tidak ditambahkan secara dinamis dan tidak memiliki atribut integrity yang cocok dengan sumber yang diizinkan.

Catatan: Saat menghitung hash CSP untuk skrip inline, karakter spasi kosong antara tag <script> pembuka dan penutup berpengaruh. Anda dapat menghitung hash CSP untuk skrip inline menggunakan alat ini.

Pertimbangan pemuatan skrip

Contoh skrip inline menambahkan s.async = falseuntuk memastikan bahwa foo dieksekusi sebelum bar, meskipun bar dimuat terlebih dahulu. Dalam cuplikan ini, s.async = false tidak memblokir parser saat skrip dimuat, karena skrip ditambahkan secara dinamis. Parser hanya berhenti saat skrip dieksekusi, seperti yang akan terjadi pada skrip async. Namun, dengan cuplikan ini, perlu diingat:

• Satu atau kedua skrip mungkin dijalankan sebelum dokumen selesai didownload. Jika Anda ingin dokumen siap saat skrip dijalankan, tunggu peristiwa DOMContentLoaded sebelum menambahkan skrip. Jika hal ini menyebabkan masalah performa karena skrip tidak mulai didownload cukup awal, gunakan tag pramuat lebih awal di halaman.
• defer = true tidak melakukan apa pun. Jika Anda memerlukan perilaku tersebut, jalankan skrip secara manual saat diperlukan.

Langkah 3: Merefaktorisasi template HTML dan kode sisi klien

Pengendali peristiwa inline (seperti onclick="…", onerror="…") dan URI JavaScript (<a href="javascript:…">) dapat digunakan untuk menjalankan skrip. Artinya, penyerang yang menemukan bug XSS dapat memasukkan HTML semacam ini dan mengeksekusi JavaScript berbahaya. CSP berbasis nonce atau hash melarang penggunaan markup semacam ini. Jika situs Anda menggunakan salah satu pola ini, Anda harus memfaktorkan ulang pola tersebut menjadi alternatif yang lebih aman.

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

Error konsol untuk kode yang diblokir.

Biasanya, perbaikannya mudah:

Merefaktorisasi pengendali peristiwa inline

Diizinkan oleh CSP

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

CSP mengizinkan pengendali peristiwa yang didaftarkan menggunakan JavaScript.

Diblokir oleh CSP

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

CSP memblokir pengendali peristiwa inline.

Merefaktorisasi javascript: URI

Diizinkan oleh CSP

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

CSP mengizinkan pengendali peristiwa yang didaftarkan menggunakan JavaScript.

Diblokir oleh CSP

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

CSP memblokir URI javascript:.

Menghapus eval() dari JavaScript Anda

Jika aplikasi Anda menggunakan eval() untuk mengonversi serialisasi string JSON menjadi objek JS, Anda harus merefaktorisasi instance tersebut ke 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 kata kunci CSP 'unsafe-eval', yang membuat kebijakan Anda sedikit kurang aman.

Anda dapat menemukan contoh refaktorisasi ini dan contoh lainnya dalam codelab CSP ketat ini:

Langkah 4 (Opsional): Tambahkan penggantian untuk mendukung versi browser lama

Perhatian: Karena semua mesin browser modern mendukung CSP ketat menggunakan strict-dynamic, Anda tidak perlu menambahkan penggantian ke CSP kecuali jika Anda perlu mendukung pengguna di versi browser yang sudah tidak berlaku. Menetapkan penggantian tidak mengurangi keamanan kebijakan Anda di browser modern, tetapi dapat menyebabkan kebingungan karena banyak developer tidak memahami mekanisme penggantian CSP yang kompleks.

Browser Support

• 52
• 79
• 52
• 15.4

Jika Anda perlu mendukung versi browser yang lebih lama:

• Penggunaan strict-dynamic memerlukan penambahan https: sebagai penggantian untuk versi Safari yang lebih lama. Jika Anda melakukannya:
  • Semua browser yang mendukung strict-dynamic akan mengabaikan penggantian https:, sehingga hal ini tidak akan mengurangi kekuatan kebijakan.
  • Di browser lama, skrip yang bersumber dari eksternal hanya dapat dimuat jika berasal dari origin HTTPS. Cara ini kurang aman dibandingkan CSP yang ketat, tetapi masih mencegah beberapa penyebab XSS umum seperti injeksi URI javascript:.
• Untuk memastikan kompatibilitas dengan versi browser yang sangat lama (4+ tahun), Anda dapat menambahkan unsafe-inline sebagai pengganti. Semua browser terbaru mengabaikan unsafe-inline jika nonce atau hash CSP ada.

Content-Security-Policy:
  script-src 'nonce-{random}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

Catatan: https: dan unsafe-inline tidak membuat kebijakan Anda menjadi kurang aman. Browser apa pun yang mendukung strict-dynamic akan mengabaikannya.

Langkah 5: Deploy CSP Anda

Setelah mengonfirmasi bahwa CSP Anda tidak memblokir skrip yang sah di lingkungan pengembangan lokal, Anda dapat men-deploy CSP ke staging, lalu ke lingkungan produksi:

1. (Opsional) Deploy CSP Anda dalam mode khusus laporan menggunakan header Content-Security-Policy-Report-Only. Mode khusus laporan berguna untuk menguji perubahan yang berpotensi menyebabkan gangguan seperti CSP baru dalam produksi sebelum Anda mulai menerapkan batasan CSP. Dalam mode hanya laporan, CSP Anda tidak memengaruhi perilaku aplikasi, tetapi browser tetap menghasilkan error konsol dan laporan pelanggaran saat menemukan pola yang tidak kompatibel dengan CSP Anda, sehingga Anda dapat melihat apa yang akan rusak bagi pengguna akhir. Untuk informasi selengkapnya, lihat Reporting API.
2. Jika Anda yakin bahwa CSP tidak akan merusak situs bagi pengguna akhir, deploy CSP menggunakan header respons Content-Security-Policy. Sebaiknya tetapkan CSP Anda menggunakan header HTTP sisi server karena lebih aman daripada tag <meta>. Setelah Anda menyelesaikan langkah ini, CSP akan mulai melindungi aplikasi Anda dari XSS.

Catatan: Pastikan CSP yang Anda gunakan "ketat" dengan memeriksanya menggunakan CSP Evaluator atau Lighthouse. Hal ini sangat penting karena perubahan kecil pada kebijakan dapat menyebabkan masalah keamanan.

Perhatian: Saat mengaktifkan CSP untuk traffic produksi, Anda mungkin melihat beberapa gangguan dalam laporan pelanggaran CSP dari ekstensi browser dan malware.

Batasan

CSP yang ketat umumnya memberikan lapisan keamanan tambahan yang kuat untuk membantu mengurangi XSS. Pada umumnya, CSP mengurangi permukaan serangan secara signifikan, dengan menolak pola berbahaya seperti URI javascript:. Namun, berdasarkan jenis CSP yang Anda gunakan (nonce, hash, dengan atau tanpa 'strict-dynamic'), ada kasus saat CSP tidak melindungi aplikasi Anda dengan baik:

• Jika Anda menggunakan nonce pada skrip, tetapi ada injeksi langsung ke isi atau parameter src dari elemen <script> tersebut.
• Jika ada injeksi ke lokasi skrip yang dibuat secara dinamis (document.createElement('script')), termasuk ke dalam fungsi library apa pun yang membuat node DOM script berdasarkan nilai argumennya. Hal ini mencakup beberapa API umum seperti .html() jQuery, serta .get() dan .post() di jQuery < 3.0.
• Jika ada injeksi template di aplikasi AngularJS lama. Penyerang yang dapat memasukkan kode ke dalam template AngularJS dapat menggunakannya untuk mengeksekusi JavaScript arbitrer.
• Jika kebijakan berisi 'unsafe-eval', injeksi ke eval(), setTimeout(), dan beberapa API lain yang jarang digunakan.

Developer dan engineer keamanan harus memberikan perhatian khusus pada pola tersebut selama peninjauan kode dan audit keamanan. Anda dapat menemukan detail selengkapnya tentang kasus ini di Kebijakan Keamanan Konten: Kekacauan yang Berhasil Antara Penguatan dan Mitigasi.

Catatan: Trusted Types melengkapi CSP ketat dengan sangat baik dan dapat secara efisien melindungi dari beberapa batasannya. Pelajari lebih lanjut cara menggunakan Trusted Types di web.dev.

Bacaan lebih lanjut

• CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content Security Policy
• CSP Evaluator
• LocoMoco Conference: Content Security Policy - A successful mess between hardening and mitigation
• Diskusi Google I/O: Mengamankan Aplikasi Web dengan Fitur Platform Modern