Dua Lapisan Keselamatan yang Mesti Sepakat

Content Security Policy (CSP) memberitahu pelayar dari sumber mana sesebuah halaman boleh memuatkan skrip, gaya, imej, bingkai dan permintaan rangkaian. Platform pengurusan persetujuan melakukan kerja sebaliknya: ia menentukan skrip mana yang dibenarkan berjalan berdasarkan pilihan pengguna. Apabila keduanya dikonfigurasi secara berasingan, keduanya berlanggar. CMP gagal dimuatkan kerana disekat CSP, atau CSP dilonggarkan begitu banyak demi CMP dan tag iklan sehingga ia tidak melindungi apa-apa lagi.

Panduan ini menerangkan direktif CSP yang lazimnya diperlukan CMP, cara nonce berinteraksi dengan suntikan skrip, dan cara melancarkan perubahan tanpa merosakkan sepanduk anda.

Apa yang Biasanya CMP Perlukan daripada CSP

Keperluan tepat bergantung pada vendor, jadi sentiasa mulakan dengan dokumentasi CMP anda sendiri. Secara umum, semak direktif ini:

• script-src — domain tempat skrip CMP dimuatkan, ditambah sebarang fail skrip tambahan yang dimuatkannya.
• connect-src — titik akhir yang dipanggil CMP dengan fetch atau XHR, seperti konfigurasi, senarai vendor, geolokasi dan pelogan persetujuan.
• style-src — domain helaian gaya, dan mungkin gaya sebaris jika CMP menyuntik elemen <style> atau menetapkan atribut gaya.
• img-src — logo, ikon dan sebarang piksel tanpa penjejakan yang digunakan CMP.
• font-src — jika sepanduk memuatkan fonnya sendiri.
• frame-src — jika CMP menggunakan iframe, contohnya untuk perkongsian persetujuan merentas domain.

Pada tapak TCF, ingat bahawa CMP turut mencipta bingkai pencari bernama __tcfapiLocator pada halaman. Bingkai itu dicipta tanpa sumber jauh, jadi lazimnya ia tidak memerlukan entri frame-src, tetapi wajar disahkan semasa pengujian.

Masalah Stub Sebaris

Kebanyakan CMP meminta anda meletakkan skrip sebaris kecil — stub — dalam head halaman, supaya skrip lain boleh menggilirkan panggilan sebelum CMP utama dimuatkan. CSP yang ketat menyekat skrip sebaris kecuali anda membenarkannya secara eksplisit. Anda ada tiga pilihan:

1. Nonce. Hasilkan nilai rawak bagi setiap respons, tambahkan pada pengepala CSP sebagai 'nonce-...' dan pada tag <script> stub. Ini pilihan paling fleksibel untuk halaman dinamik.
2. Cincangan (hash). Tambahkan cincangan SHA-256 bagi kandungan tepat stub pada script-src. Ini berfungsi baik untuk tapak statik, tetapi sebarang perubahan pada stub, walaupun ruang kosong, akan merosakkannya.
3. Hos sendiri stub sebagai fail luaran pada domain anda, dilindungi oleh 'self'. Ini memerlukan penjagaan supaya ia dimuatkan cukup awal.

Elakkan 'unsafe-inline' sebagai jalan pintas. Ia membenarkan setiap skrip sebaris, yang menghapuskan banyak perlindungan yang diberikan CSP.

Nonce dan Skrip yang Disuntik CMP

CMP yang menyekat skrip sehingga ada persetujuan sering berfungsi dengan menahannya dan menyuntiknya kemudian. Di bawah CSP berasaskan nonce, skrip yang disuntik itu juga perlu dibenarkan. Ada dua pendekatan lazim:

• Perambatan nonce. CMP membaca nonce daripada tag skripnya sendiri dan menambahkannya pada setiap skrip yang disuntiknya. Semak sama ada CMP anda menyokong ini.
• 'strict-dynamic'. Kata kunci ini memberitahu pelayar yang menyokongnya supaya mempercayai skrip yang dimuatkan oleh skrip yang sudah dipercayai. Ia memudahkan urusan dengan pengurus tag dan CMP yang menyuntik skrip, tetapi ia juga bermakna mana-mana skrip yang anda percayai boleh memuatkan skrip lain, jadi percayalah dengan berhati-hati.

Pengurus tag menimbulkan soalan yang sama. Jika anda memuatkan tag iklan dan analitik melalui pengurus tag, ikut dokumentasinya tentang nonce dan pastikan CMP serta pengurus tag menggunakan pendekatan yang konsisten.

Tag Iklan Menyukarkan CSP

Pengiklanan programatik memuatkan skrip dan bingkai daripada banyak domain, dan senarainya berubah apabila rakan permintaan berubah. Penerbit biasanya membuat salah satu daripada dua pilihan:

• CSP yang ketat pada halaman tanpa iklan programatik, dan dasar yang lebih luas di tempat iklan berjalan.
• Dasar yang menumpukan pada direktif yang kekal boleh diurus, seperti frame-ancestors, object-src 'none' dan base-uri, manakala sumber skrip kekal lebih luas.

Apa pun pilihannya, CMP harus berada dalam senarai benar yang eksplisit, bukan hanya dilindungi oleh kad bebas, supaya perubahan CSP tidak sekali-kali melumpuhkan sepanduk secara senyap.

Lancarkan dengan Mod Report-Only

Gunakan pengepala Content-Security-Policy-Report-Only dahulu. Pelayar melaporkan pelanggaran tanpa menyekat apa-apa, jadi anda dapat melihat apa yang akan dirosakkan oleh dasar baharu.

1. Terapkan dasar dalam mod report-only dengan titik akhir pelaporan.
2. Muatkan halaman dalam profil pelayar yang bersih dan jalani seluruh aliran persetujuan: lawatan pertama, terima semua, tolak semua, pilihan tersuai, penarikan balik.
3. Semak laporan pelanggaran dan konsol pelayar untuk sumber CMP yang disekat.
4. Laraskan dasar, kemudian beralih kepada penguatkuasaan.
5. Biarkan pelaporan aktif selepas penguatkuasaan untuk mengesan regresi.

Gejala Konflik CSP

• Sepanduk tidak pernah muncul, dan konsol menunjukkan pelanggaran CSP bagi skrip CMP.
• Sepanduk muncul tetapi tanpa gaya, kerana style-src menyekat CSS-nya.
• Pilihan tidak disimpan, kerana connect-src menyekat panggilan pelogan persetujuan.
• Iklan atau analitik tidak pernah dimuatkan selepas persetujuan, kerana skrip yang disuntik tiada nonce.
• __tcfapi tidak ditakrifkan, kerana stub sebaris disekat.

Perkara Utama

• Semak script-src, connect-src, style-src, img-src dan frame-src untuk CMP anda.
• Benarkan stub sebaris dengan nonce atau cincangan, bukan 'unsafe-inline'.
• Pastikan skrip yang disuntik selepas persetujuan menerima nonce atau dilindungi oleh 'strict-dynamic'.
• Uji setiap laluan persetujuan dalam mod report-only sebelum menguatkuasakan.
• Kekalkan CMP dalam senarai benar yang eksplisit supaya perubahan CSP tidak dapat melumpuhkannya.