CONTENT SECURITY POLICY

A. PENGENALAN CONTENT SECURITY POLICY

Content Security Policy (CSP) atau dalam Bahasa Indonesia dikenal dengan Kebijakan Keamanan Konten, adalah lapisan keamanan tambahan yang membantu mendeteksi dan mengurangi jenis serangan tertentu, seperti Cross Site Scripting (XSS), serangan injeksi data, pencurian data, perusakan situs, hingga distribusi malware.

Untuk mengaktifkan Content Security Policy (CSP), kita bisa melakukan konfigurasi pada webserver seperti Apache, Nginx, dan semisalnya. Selain webserver, kita juga bisa menentukan CSP melalui tag HTML dan pada bahasa pemrograman backend yang digunakan, seperti PHP dan sejenisnya (akan dibahas kemudian).

Adapun ilustrasi dari penerapan CSP dan pengaruhnya terhadap client dapat dilihat pada gambar berikut (Gambar 1). Pada gambar tersebut disimulasikan client mengakses website http://example.com  yang memiliki aset berupa javascript ‘file.js’ dan css‘file.css’. Lalu peretas menyisipkan script jahat berupa javascript dari website http://malicious.com bernama xss.js. Sementara webserver menerapkan CSP default-src http://www.example.com.

Maka yang akan ditampilkan pada client dan dieksekusi oleh browser hanyalah file.js dan file.css karena kedua file tersebut berasal dari server yang sama. Sedangkan file xss.js yang disisipkan oleh peretas, akan diblokir oleh browser yang membaca respon dari HTTP Header Content Security Policy karena bersumber dari website yang berbeda.

Gambar 1 – Bagaimana CSP Bekerja

Gambar 2 – Contoh Penerapan CSP

Sebelum menerapkan Content Security Policy pada server, ada beberapa istilah yang harus kita kenali dan beberapa kondisi pada website/aplikasi yang harus kita pahami. Teknologi yang digunakan pada website atau aplikasi akan mempengaruhi konfigurasi dari CSP itu sendiri. Demikian juga sebaliknya. Adapun istilah-istilah yang harus kita pahami kegunaannya pada konfigurasi CSP bisa dilihat pada tabel berikut.

Directives pada CSP berfungsi sebagai penentu kebijakan yang akan diterapkan. Contoh, kita ingin menerapkan directive script-src, maka artinya kita akan menentukan script yang bersumber dari mana saja yang akan diizinkan untuk dieksekusi. Perlu diperhatikan bahwa directive default-src wajib ada dalam konfigurasi CSP untuk menyesuaikan dengan kompatibilitas browser karena masih ada beberapa browser yang mungkin belum mendukung directive tersebut. Misal, jika browser tidak mendukung directive object src, maka kebijakan sumber konten akan ditentukan oleh directive default-src. Atau jika object-src tidak dideklarasikan pada CSP, maka konten yang terkait dengan object seperti tag HTML sejenisnya, kebijakannya akan dikembalikan pada default-src. Namun perlu digarisbawahi bahwa tidak semua directive akan dikembalikan kepada default-src. Selanjutnya, directive pada CSP harus diikuti dengan source list karena di sinilah ditentukan sumber-sumber konten yang akan diizinkan.

a. Macam-macam Directive pada CSP dan Penjelasannya

b. Referensi Source List

Semua arahan yang diakhiri dengan -src mendukung nilai serupa yang dikenal sebagai source list. Beberapa nilai source list dapat dipisahkan spasi dengan pengecualian 'none' yang seharusnya menjadi satu-satunya value.

B. IMPLEMENTASI CONTENT SECURITY POLICY

1. Contoh Konfigurasi Dasar dan Sederhana

Contoh konfigurasi CSP pada Nginx.

Contoh konfigurasi CSP pada Apache.

Contoh konfigurasi CSP dengan <meta> tag HTML.

Contoh konfigurasi CSP pada pemrograman PHP.

Konfigurasi di atas akan menghasilkan kebijakan konten sebagai berikut:

• default-src ‘self’ https://cdn.bootstrap.com artinya konten dan resource yang ditampilkan berupa gambar, font style, css, koneksi, media, objek hanya yang berasal dari website kita sendiri dan https://cdn.bootstrap.com.
• script-src ‘self’ https://cdn.bootstrap.com; artinya konten dan resource yang ditampilkan berupa javascript hanya yang berasal dari website kita sendiri dan https://cdn.bootstrap.com. Jika directive ini tidak dideklarasikan, maka kebijakan akan dikembalikan pada directive default-src.
• style-src ‘self’ https://cdn.bootstrap.com; artinya konten dan resource yang ditampilkan berupa CSS hanya yang berasal dari website kita sendiri dan https://cdn.bootstrap.com. Jika directive ini tidak dideklarasikan, maka kebijakan akan dikembalikan pada directive default-src.
• img-src ‘self’ artinya konten dan resource yang ditampilkan berupa gambar hanya yang berasal dari website kita sendiri. Jika directive ini tidak dideklarasikan, maka kebijakan akan dikembalikan pada directive default-src.

2. Penerapan Source dengan Skema (Scheme)

Konfigurasi di atas akan menghasilkan kebijakan konten sebagai berikut:

• default-src ‘self’ https://cdn.bootstrap.com; artinya konten dan resource yang ditampilkan berupa gambar, font style, css, koneksi, media, objek hanya yang berasal dari website kita sendiri dan https://cdn.bootstrap.com.
• script-src ‘self’ https://cdn.bootstrap.com; artinya konten dan resource yang ditampilkan berupa javascript hanya yang berasal dari website kita sendiri dan https://cdn.bootstrap.com. Jika directive ini tidak dideklarasikan, maka kebijakan akan dikembalikan pada directive default-src.
• style-src ‘self’ https://cdn.bootstrap.com; artinya konten dan resource yang ditampilkan berupa CSS hanya yang berasal dari website kita sendiri dan https://cdn.bootstrap.com. Jika directive ini tidak dideklarasikan, maka kebijakan akan dikembalikan pada directive default-src.
• img-src ‘self’ data: artinya konten dan resource yang ditampilkan berupa gambar hanya yang berasal dari website kita sendir dan mengizinkan memuat gambar yang di-encoding dengan base64() seperti format data:image/webp;base64,/b4s364ImAgeEnc0dinG==. Jika directive ini tidak dideklarasikan, maka kebijakan akan dikembalikan pada directive default-src.
• object-src ‘self’ blob: artinya konten dan resource yang ditampilkan berupa object baik itu yang dimuat dengan frame, object, atau applet harus bersumber dari website kita sendiri dan mengizinkan tipe data object dengan bentuk blob. Seperti blob:https://website.com/123-45jhjfg-123btnbg1-345345.

3. Penerapan Hash dan Nonce

Jika ada penerapan inline script atau inline style pada website kita, kita harus menyertakan ‘unsafe-inline’ pada directive script-src atau style-src. Namun cara demikian menyebabkan kemanan website kita akan lebih rentan terhadap serangan. Sebagai alternatifnya, CSP menyediakan fitur nonce atau hash. Nonce adalah karakter acak sekali pakai berbentuk base64 yang digunakan pada tag script atau style dan nonce tersebut nantinya didaftarkan pada Rule CSP. Sedangkan hash adalah hasil hashing dari inline script tanpa menyertakan tag script atau style.

Gambar 3 – Penerapan Inline Script yang ditolak oleh browser karena Konfigurasi CSP

Ketika ‘unsafe-inline’ tidak diterapkan pada CSP sedangkan website anda menggunakan inline style atau inline script, maka pada console browser akan tampil error seperti di atas. Pada console akan ditampilan nilai hash dari script yang diblokir atau saran menggunakan nonce.

Misal, website kita menerapkan inline script sebagai berikut.

Solusinya menambahkan atribut nonce pada tag script.

Kemudian menambahkan nonce value tersebut pada rule CSP kita.

Atau cara kedua adalah membuat hash dari script di atas. Dalam modul ini saya menggunakan fitur script and style hasher pada website https://report-uri.com/. Salin script (tanpa menyertakan tag script) lalu paste pada form yang telah disediakan kemudian klik tombol hash.

Gambar 4 – Script and Style Hasher

Nilai hash akan muncul dan sertakan nilai hash tersebut pada rule CSP yang akan kita buat.

Untuk menjalankan script pada event hanlders seperti script pada atribut onclick, selain menambahkan nilai hash-nya, kita harus menambahkan ‘unsafe-hashes’ pada rule CSP. Contohnya sebagai berikut.

CSP rule-nya adalah sebagai berikut.

Yang perlu diperhatikan ketika kita memilih untuk menggunakan nonce, nonce yang diterapkan haruslah bersifat dinamis, bukan statis. Nonce harus berubah setiap halaman dimuat ulang karena, jika nonce tidak berubah-ubah, peretas dapat melakukan bypass terhadap rule CSP yang kita buat. Adapun syarat-syarat lainnya sebagai berikut:

1. Nonce harus unik untuk setiap HTTP Response
2. Nonce harus dibuat menggunakan generator acak yang aman secara kriptografis
3. Nonce harus memiliki panjang yang cukup, bertujuan untuk setidaknya 128 bit entropi (32 karakter hex, atau sekitar 24 karakter base64).
4. Tag skrip yang memiliki atribut nonce tidak boleh memiliki variabel tidak tepercaya/tidak lolos di dalamnya. Artinya harus terdaftar di CSP rule.

Untuk lebih lengkapnya tentang penerapan dynamic noce bisa dilihat pada link berikut.

1. Generate a nonce with Apache 2.4 (for a Content Security Policy header) - Stack Overflow
2. CSP Nonce support in Nginx

4. Penerapan Directive report-uri dan Konfigurasi URI Reporting pada Website report-uri.com

Pada CSP terdapat fitur reprot-uri dan report-to yang berfungsi untuk melaporkan pelanggaran terhadap CSP. Directive report-uri akan diikuti oleh URL di maka laporan akan dikirim oleh server jika terjadi pelanggaran. Sedangkan report-to diikuti nama grup URL pelaporan yang telah didefinisikan sebelumnya pada HTTP Header Report-To.

Penggunaan report-uri pada CSP.

Penggunaan report-to pada CSP.

Untuk mendapatkan URI Reporting, kita bisa mendaftar secara gratis pada website Report URI: Register (report-uri.com). Setelah itu, kita akan mendapatkan link verifikasi pada email kita. Klik link yang dikirimkan untuk menyelesaikan proses registrasi.

Gambar 6 – Halaman Registrasi Report URI

Setelah proses registrasi selesai, silakan login pada halaman berikut: Report URI: Login (report-uri.com).

Gambar 7 – Tampilan Halaman Login Report URI

Gambar 8 - Tampilan Dashboard Report URI

Klik icon CUSTOMISE pada Dashboard kemudian website akan mengarahkan kita pada halaman setup. Pada halaman ini kita bisa melakukan kustomisasi URI Reporting dan mendapatkan Reporting API.

Gambar 9 – Halaman Setup Report URI

5. Analisa Security Header dan CSP Scanner

Kita bisa menganalisa hasil dari konfigurasi HTTP Header dan CSP kita melalui website https://securityheaders.com atau dengan extension CSP Scanner pada browser Chrome dan Edge.

Gambar 10 – Hasil Analisa HTTP Header terhadap Website https://govcsirt.tangerangkota.go.id

Gambar 11 – Hasil Analisa CSP Header terhadap Website https://govcsirt.tangerangkota.go.id

Gambar 12 – Peringatan Kelemahan Konfigurasi yang Mungkin Bisa diperbaiki pada Website https://govcsirt.tangerangkota.go.id

Gambar 13 – Hasil Analisa CSP Header terhadap Website https://govcsirt.tangerangkota.go.id Menggunakan Extension CSPScanner pada Browser Ms. Edge.

Gambar 14 – Warning pada Konfigurasi CSP dari Website https://govcsirt.tangerangkota.go.id yang mungkin bisa diperbaiki.