Defaults.Exposed › Pembaikan › Content-Security-Policy (CSP)

Cara memperbaiki Content-Security-Policy (CSP)

Content Security Policy ialah peraturan keselamatan yang laman web anda berikan kepada pelayar setiap pengunjung, memberitahunya dengan tepat kod mana yang dibenarkan untuk dijalankan. Tanpanya, jika sesuatu yang berniat jahat pernah mendarat pada halaman — melalui kotak komen, plugin yang digodam, atau skrip pihak ketiga — pelayar akan menjalankannya dengan bebas, termasuk kod yang secara senyap mengikis nombor kad dan kata laluan pelanggan anda semasa mereka menaip, dengan kunci masih muncul.

Kesimpulan untuk perniagaan anda: Jika laman anda pernah diubah, kod berniat jahat boleh membaca butiran kad pembayaran dan log masuk pelanggan anda terus dari checkout anda sendiri semasa segalanya kelihatan normal sepenuhnya — meninggalkan anda dengan caj balik, tuntutan penipuan, pelanggaran data yang boleh dilaporkan, dan kegagalan semakan yang pasukan keselamatan klien yang lebih besar gunakan untuk menangguhkan atau membunuh sesuatu urusan perniagaan.

Apakah kos yang boleh timbul

Kod tersembunyi tergelincir masuk ke salah satu halaman anda dan secara senyap menyalin setiap nombor kad dan kata laluan yang pelanggan anda masukkan di checkout, menghantar kepada penyerang sementara laman anda kelihatan normal sepenuhnya — anda hanya tahu apabila aduan penipuan tiba.
Penipu menanam borang 'bayar di sini' palsu pada laman web sebenar anda yang menangkap pembayaran ke dalam akaun mereka sendiri; pelanggan fikir mereka membayar anda, menyalahkan anda apabila barangan tidak datang, dan menuntut wang mereka kembali.
Pasukan keselamatan klien yang lebih besar mengimbas laman anda, melihat perlindungan asas ini dimatikan, dan menandanya — menangguhkan atau mengakibatkan kehilangan kontrak sehingga anda dapat membuktikan ia diperbetulkan.
Pelanggaran yang dikesan kepada perlindungan standard yang hilang menjadi insiden yang boleh dilaporkan: soalan pengawal selia, pemberitahuan pelanggan, dan kejatuhan reputasi yang merugikan jauh lebih banyak daripada pembetulan percuma.

Mengapa ia penting. Kunci membuktikan sambungan ke laman anda adalah peribadi, tetapi ia tidak membuat apa-apa untuk mengawal kod yang dijalankan setelah pengunjung berada pada halaman. Content Security Policy adalah perlindungan yang melakukan itu — ia memberitahu pelayar untuk mengabaikan sebarang skrip yang tidak datang dari sumber yang anda percayai, supaya satu medan yang diubah, iklan, atau plugin tidak boleh bertukar menjadi alat untuk mencuri wang dan data pelanggan anda. Ia adalah semakan yang dinilai pada kad skor anda, bernilai mata sebenar, dan salah satu perkara pertama yang semakan keselamatan profesional cari.

Apa ini, dalam bahasa mudah

Apabila seseorang melawati laman web anda, pelayar mereka memuat turun halaman anda dan menjalankan apa sahaja kod yang ada padanya — skrip yang membuat menu jatuh, butang berfungsi, borang pembayaran dihantar, dan sebagainya. Secara lalai, pelayar mempercayai semuanya. Ia tidak mempunyai cara untuk mengetahui kod mana yang benar-benar milik anda dan yang diselundupkan oleh seseorang yang lain.

Content Security Policy (sering disingkat CSP) adalah senarai peraturan pendek yang laman web anda melampirkan kepada setiap halaman, memberitahu pelayar: “hanya jalankan kod dari sumber ini yang saya luluskan, dan tolak segalanya yang lain.” Ia adalah perbezaan antara kelab malam yang membenarkan sesiapa masuk dan satu dengan senarai tetamu di pintu.

Sebab ini sangat penting adalah kerana laman web terus diubah — tidak selalu dengan menggodam pelayan anda, tetapi melalui pintu belakang yang kebanyakan laman biarkan terbuka: medan komen, kotak carian, plugin yang lapuk, skrip pihak ketiga untuk iklan atau analitik, atau widget chat. Jika penyerang mendapatkan walaupun satu baris kod mereka sendiri pada salah satu halaman anda, pelayar menjalankannya seolah-olah ia adalah milik anda. Dari sana ia boleh membaca semua yang pelanggan anda taip — nombor kad, kata laluan, alamat — dan menghantar secara senyap ke tempat lain. Content Security Policy menutup pintu itu dengan menolak untuk menjalankan apa-apa dari sumber yang anda tidak luluskan.

Apa yang ini boleh koskan anda

Serangan yang Content Security Policy mencegah — kod yang disuntik ke halaman yang mencuri data dari pelanggan anda sendiri — adalah di sebalik beberapa pelanggaran pengikisan kad terbesar yang direkodkan. Begini ia cenderung berlaku untuk perniagaan biasa:

Pengimbas checkout yang tidak kelihatan. Penyerang menyelipkan beberapa baris kod ke halaman checkout anda melalui plugin yang terdedah atau skrip pihak ketiga yang terjejas. Setiap nombor kad, nama, dan CVV yang pelanggan anda taip disalin dan dihantar kepada penyerang dalam masa nyata. Laman anda kelihatan dan berfungsi dengan sempurna; kunci ada di sana. Anda mendapatinya berminggu-minggu kemudian apabila pembekal pembayaran anda menghubungi tentang kelompok laporan penipuan yang semuanya mengesan kembali ke kedai anda. Kini anda menghadapi caj balik, audit keselamatan paksa, kemungkinan kehilangan hak pemprosesan kad, dan pelanggaran yang mungkin diwajibkan anda laporkan.
Borang pembayaran palsu. Penipu menyuntik kotak “bayar di sini” yang meyakinkan ke laman web sebenar anda. Pelanggan memasukkan butiran mereka mempercayai jenama anda; wang dan data pergi kepada penyerang. Pelanggan menyalahkan anda — dan mereka tidak salah, kerana ia berlaku di laman anda.
Kontrak yang hilang. Pasukan keselamatan prospek yang lebih besar menjalankan imbasan automatik laman anda sebagai sebahagian daripada due diligence vendor. Content Security Policy yang hilang muncul serta-merta sebagai jurang keparahan tinggi. Bagi penyemak perolehan atau keselamatan, perlindungan standard tunggal yang hilang itu dibaca sebagai “pembekal ini tidak melakukan asas” — dan urusan perniagaan tertangguh sementara mereka meminta pemulihan, atau secara senyap pergi kepada pesaing yang lulus.
Pelanggaran yang boleh dilaporkan. Apabila pelanggaran data dikesan kembali kepada perlindungan standard percuma yang hilang, ia berhenti menjadi nasib malang dan mula kelihatan seperti kecuaian. Itu mengubah soalan pengawal selia, kewajipan pemberitahuan pelanggan, dan kos — kedua-dua denda dan kerosakan reputasi, yang bertahan lama selepas insiden ditutup.
Iklan atau widget yang terjejas. Banyak laman memuatkan kod dari pihak luar — rangkaian iklan, fon, chat sokongan, analitik. Jika mana-mana satu itu terjejas, kod berniat jahat naik terus ke halaman anda. Content Security Policy mengehadkan radius letupan dengan hanya membenarkan sumber luar tertentu yang anda percayai, jadi satu pelanggaran pembekal tidak secara automatik menjadi milik anda.

Apa yang ia sebenarnya (butiran)

Content Security Policy dihantar sebagai satu pengepala respons HTTP tunggal — satu baris yang pelayan web anda hantar dengan setiap halaman. Nilainya adalah set arahan, setiap satu menamakan jenis kandungan dan sumber yang dibenarkan untuknya. Contohnya:

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

Dalam istilah mudah, itu berkata: secara lalai hanya muatkan perkara dari laman saya sendiri; hanya jalankan skrip dari laman saya sendiri; benarkan tiada plugin gaya lama; dan jangan biarkan laman lain menanam laman saya dalam bingkai.

Apa yang “baik” kelihatan. Semakan kami tidak hanya mencari kehadiran pengepala — ia membaca arahan dasar satu demi satu dan menilai betapa kuatnya sebenarnya, cara penyemak keselamatan akan. Dasar yang kukuh:

Menetapkan garis dasar yang ketat (default-src 'self') dan hanya meluaskannya untuk pihak ketiga yang dipercayai tertentu yang anda gunakan.
Mengelak penyelewengan. Ia tidak menggunakan 'unsafe-inline' atau 'unsafe-eval' untuk skrip, dan tidak menggunakan sumber wildcard (*) atau skim bare (seperti https:) untuk skrip — ini secara berkesan membuka semula pintu yang dasar sepatutnya tutup. Di mana skrip sebaris benar-benar diperlukan, ia menggunakan nonce atau hash supaya hanya kod yang anda luluskan secara khusus dijalankan.
Mengunci bingkai dengan frame-ancestors 'self' (ini juga menghalang serangan “tanam laman anda untuk menipu pelanggan anda”) dan melumpuhkan plugin warisan dengan object-src 'none'.
Menguatkuasakan, bukan hanya-laporan. Pengepala Content-Security-Policy-Report-Only hanya memantau; ia memberikan sifar perlindungan masa jalan. Semakan kami memberikannya sebahagian kecil kredit dan tidak pernah merekodkannya sebagai lulus. Anda hanya dilindungi setelah dasar menguatkuasakan.

Dasar yang wujud tetapi bergantung pada 'unsafe-inline', 'unsafe-eval', atau wildcard masih akan mendapat markah rendah — kerana dalam amalan ia memberikan perlindungan sebenar yang sedikit. Matlamatnya adalah dasar yang ketat, bukan sebarang dasar sahaja.

Cara membetulkannya (percuma, ~1–2 jam)

Berikan ini kepada orang IT atau sesiapa yang menjalankan laman web anda — pembetulan itu sendiri adalah sepenuhnya percuma. Kami hanya pernah mengenakan bayaran untuk memantau bahawa ia kekal wujud dan kekal betul dari masa ke masa; menghidupkannya tidak memerlukan kos apa-apa. Sebab ini mengambil masa sejam atau dua dan bukannya beberapa minit adalah langkah percubaan yang berhati-hati yang menghentikannya daripada secara tidak sengaja menyekat bahagian laman anda sendiri.

Mulakan dalam mod hanya-laporan — jangan kuatkuasa dahulu. Tambah pengepala respons Content-Security-Policy-Report-Only. Ini memantau dan mencatat apa yang akan disekat tanpa benar-benar menyekat apa-apa, supaya laman langsung terus berfungsi semasa anda belajar apa yang setiap halaman benar-benar bergantung padanya. (Penting: hanya-laporan sahaja tidak memberikan perlindungan kepada pengunjung — ia hanya langkah pertama yang selamat.)
Bina dasar dari apa yang laman anda sebenarnya gunakan. Semak laporan untuk mencari setiap sumber sah skrip, gaya, fon, dan imej — domain anda sendiri, analitik anda, pembekal pembayaran anda, hos fon anda, widget chat anda — dan senaraikan mereka sebagai sumber yang dibenarkan. Titik permulaan yang kukuh ialah default-src 'self' ditambah entri eksplisit untuk pihak ketiga yang dipercayai yang anda benar-benar gunakan.
Elak penyelewengan yang mengalahkan keseluruhan tujuan. Elakkan 'unsafe-inline' dan 'unsafe-eval' untuk skrip, dan elakkan sumber wildcard seperti * dan skim bare seperti https: untuk skrip — ini membuka semula tepat jurang yang dasar sepatutnya tutup. Di mana skrip sebaris tidak dapat dielak, gunakan nonce atau hash supaya hanya kod yang anda luluskan secara khusus dijalankan.
Kunci bingkai dan plugin. Tambah frame-ancestors 'self' (ini juga menghentikan laman lain menanam laman anda untuk menipu pelanggan anda, dan ia memenuhi semakan clickjacking yang berkaitan) dan object-src 'none' untuk menyekat serangan berasaskan plugin warisan.
Beralih dari hanya-laporan kepada menguatkuasakan. Setelah laporan bersih dan laman berfungsi, tukar nama pengepala dari Content-Security-Policy-Report-Only kepada Content-Security-Policy. Ini adalah langkah yang sebenarnya memberikan perlindungan — dasar hanya-laporan sahaja tidak, dan tidak akan lulus semakan.

Di mana anda menetapkan pengepala bergantung pada platform anda:
- Cloudflare: Rules → Transform Rules → Modify Response Header → tetapkan Content-Security-Policy.
- Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';" always;
- Apache: Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';"
- IIS (web.config): tambah pengepala respons HTTP tersuai bernama Content-Security-Policy dengan dasar sebagai nilainya.
- Google Workspace / Microsoft 365: ini menjalankan e-mel anda, bukan laman web awam anda, jadi dasar ditetapkan di mana sahaja laman web anda sebenarnya dihoskan (Cloudflare atau hos web anda di atas), bukan dalam konsol admin e-mel anda.
Semak semula domain anda untuk mengesahkan dasar kini ditunjukkan sebagai dihidupkan dan menguatkuasakan, tanpa penyelewengan yang melemahkan.

Kesilapan biasa

Berhenti pada hanya-laporan. Kesilapan tunggal yang paling biasa: dasar ditambah dalam mod hanya-laporan, semua orang bergerak, dan laman tidak pernah benar-benar dilindungi. Hanya-laporan tidak menyekat apa-apa. Anda mesti beralih kepada penguatkuasaan.
Mencapai 'unsafe-inline' untuk menjadikannya “hanya berfungsi.” Apabila dasar menyekat skrip sebaris yang sah, pembetulan pantas adalah untuk membenarkan semua skrip sebaris — tetapi itu membuka semula lubang tepat yang dasar sepatutnya tutup. Gunakan nonce atau hash.
Menggunakan wildcard. * bare (atau https:) dalam script-src membenarkan skrip dari mana-mana sahaja, bermakna dasar memberikan hampir tiada perlindungan sebenar dan masih akan mendapat markah rendah.
Terlupa sumber pihak ketiga. Menguatkuasakan dasar yang ketat tanpa menyenaraikan terlebih dahulu perkhidmatan luar yang sah yang anda gunakan (analitik, fon, widget pembayaran) boleh memutuskan bahagian laman anda sendiri — itulah sebabnya langkah percubaan hanya-laporan wujud.
Menetapkannya hanya pada halaman utama. Dasar perlu merangkumi setiap halaman, terutama checkout, log masuk, dan halaman akaun — itulah yang berbaloi untuk diserang.
Menganggapnya sebagai pengganti kunci. Content Security Policy dan HTTPS/HSTS melindungi perkara yang berbeza. Anda mahu semuanya; satu tidak menutup untuk yang lain.

Soalan Lazim

Saya bukan orang teknikal — bolehkah saya menangani perkara ini sendiri?

Anda tidak perlu memahami butirannya. Ini adalah tetapan yang ditambah oleh sesiapa yang menjalankan laman web atau pengehosan anda, dan pada perkhidmatan seperti Cloudflare ia sebahagian besarnya dipandu. Berikan bahagian 'Cara membetulkannya' di bawah kepada mereka. Ia percuma; satu berhati-hati ialah ia harus digulung dengan berhati-hati dalam mod percubaan hanya-pantau dahulu supaya ia tidak menyekat bahagian laman anda sendiri secara tidak sengaja — yang adalah tepat apa yang langkah merangkumi.

Saya sudah mempunyai kunci dan sijil SSL — bukankah laman saya selamat?

Kunci melindungi penghantaran halaman anda; ia tidak mengawasi apa yang dijalankan di dalamnya. Jika kod berniat jahat pernah berakhir pada halaman — melalui plugin yang digodam, iklan yang terjejas, atau medan yang disuntik — kunci tidak akan menghentikannya daripada mencuri data. Content Security Policy adalah lapisan yang mengehadkan apa yang dibenarkan untuk dijalankan. Mereka melindungi perkara yang berbeza, dan anda mahu kedua-duanya.

Bolehkah menghidupkan ini memutuskan laman saya?

Ia boleh jika dihidupkan secara agresif sekaligus, kerana ia mungkin menyekat skrip yang sah yang sebenarnya anda gunakan. Itulah sebabnya pendekatan standard adalah untuk bermula dalam mod percubaan 'hanya-laporan' yang memantau tanpa menyekat, membetulkan apa-apa yang ditandakannya, dan hanya kemudian menguatkuasakannya. Dilakukan dengan cara ini ia selamat — dan langkah percubaan dibina dalam pembetulan di bawah.

Kami sudah meletakkannya dalam mod 'hanya-laporan' — adakah kami dilindungi?

Tidak, dan ini adalah rasa selamat yang palsu yang paling biasa. Mod hanya-laporan memantau dan mencatat apa yang akan disekat, tetapi ia tidak menyekat apa-apa — pengunjung mendapat sifar perlindungan sebenar. Ia hanya langkah pertama yang selamat. Semakan kami memberikan hanya-laporan sebahagian kecil kredit daripada dasar sebenar dan tidak akan merekodkannya sebagai lulus. Anda hanya dilindungi setelah anda beralih ke mod penguatkuasaan.

Adakah ini mempengaruhi skor kami, atau adakah ia hanya nasihat?

Ia mempengaruhi skor anda. Semakan Content Security Policy dinilai dan bernilai sehingga 25 mata dalam kategori Keselamatan Web. Dasar yang hilang atau lemah ditanda keparahan tinggi dan menjatuhkan gred anda — dan ia adalah tepat jenis jurang yang soal selidik keselamatan klien bertanya.

Pembangun kami menambah dasar tetapi skor masih rendah — mengapa?

Dasar boleh wujud dan masih lemah. Punca paling biasa ialah penyelewengan seperti 'unsafe-inline' dan 'unsafe-eval' untuk skrip, atau sumber wildcard (tanda * sahaja), yang membuka semula jurang tepat yang dasar sepatutnya tutup. Semakan kami membaca arahan dasar satu demi satu dan menilai ke bawah kelemahan itu — dasar yang membenarkan apa-apa sahaja mendapat markah sedikit lebih baik daripada tidak ada langsung. Pembetulan adalah untuk mengetatkan peraturan skrip menggunakan nonce atau hash dan bukannya penyelewengan itu.