Pengenalan kepada keselamatan HTML5: Pengenalan kepada Dasar Keselamatan Kandungan (CSP)_html5 kemahiran tutorial

Dasar keselamatan World Wide Web berakar pada dasar asal yang sama. Sebagai contoh, kod www.jb51.net hanya boleh mengakses data www.jb51.net, tetapi tidak mempunyai kebenaran untuk mengakses http://www.baidu.com. Setiap asal diasingkan daripada seluruh rangkaian, mewujudkan kotak pasir yang selamat untuk pembangun. Ini sempurna dalam teori, tetapi kini penyerang telah menemui cara bijak untuk menjejaskan sistem ini.
Ini ialah serangan skrip merentas tapak XSS, yang memintas dasar asal yang sama melalui kandungan palsu dan klik tipu. Ini adalah masalah besar, dan jika penyerang berjaya menyuntik kod, sejumlah besar data pengguna boleh dibocorkan.
Kini kami memperkenalkan strategi pertahanan keselamatan yang baharu dan berkesan untuk mengurangkan risiko ini, iaitu Polisi Keselamatan Kandungan (CSP).
Senarai Putih Sumber
Teras serangan XSS ialah penyemak imbas tidak dapat membezakan sama ada skrip disuntik oleh pihak ketiga atau benar-benar sebahagian daripada aplikasi anda. Sebagai contoh, butang Google 1 akan memuatkan dan melaksanakan kod daripada https://apis.google.com/js/plusone.js, tetapi kami tidak boleh mengharapkan untuk menentukan daripada gambar pada penyemak imbas bahawa kod itu benar-benar datang daripada apis.google .com , sekali lagi daripada apis.evil.example.com. Penyemak imbas memuat turun dan melaksanakan kod sewenang-wenangnya pada permintaan halaman, tanpa mengira asalnya.
CSP mentakrifkan pengepala HTTP Content-Security-Policy untuk membolehkan anda membuat senarai putih sumber yang dipercayai supaya penyemak imbas hanya melaksanakan dan memaparkan sumber daripada sumber ini, dan bukannya mempercayai secara membuta tuli semua kandungan yang disediakan oleh pelayan. Walaupun penyerang boleh mencari kelemahan untuk menyuntik skrip, ia tidak akan dilaksanakan kerana sumber tidak termasuk dalam senarai putih.
Mengambil butang Google 1 di atas sebagai contoh, kerana kami percaya bahawa apis.google.com menyediakan kod yang sah, serta kami sendiri, kami boleh menentukan dasar yang membenarkan penyemak imbas hanya melaksanakan skrip daripada salah satu daripada dua berikut sumber.
Content-Security-Policy:script-src 'self' https://apis.google.com
Bukankah ia sangat mudah? script-src boleh mengawal kebenaran berkaitan skrip untuk halaman yang ditentukan. Dengan cara ini penyemak imbas hanya akan memuat turun dan melaksanakan skrip daripada http://apis.google.com dan halaman ini sendiri.
Sebaik sahaja kami mentakrifkan strategi ini, penyemak imbas akan membuat ralat apabila ia mengesan kod yang disuntik (perhatikan apakah pelayar itu).
Dasar keselamatan kandungan terpakai pada semua sumber yang biasa digunakan
Walaupun sumber skrip adalah risiko keselamatan yang paling jelas, CSP juga menyediakan set arahan yang kaya yang membolehkan halaman mengawal pemuatan pelbagai jenis sumber, seperti jenis berikut :
content-src: Hadkan jenis sambungan (seperti XHR, WebSockets dan EventSource)
font-src: Kawal sumber fon web. Contohnya, fon web Google boleh digunakan melalui font-src https://themes.googleusercontent.com.
frame-src: Menyenaraikan sumber bingkai yang boleh dibenamkan. Contohnya, frame-src https://youtube.com hanya membenarkan pembenaman video YouTube. .
img-src: Mentakrifkan sumber imej yang boleh dimuatkan.
media-src: Hadkan sumber video dan audio.
object-src: Hadkan sumber Flash dan pemalam lain.
style-src: serupa dengan Script-src, tetapi hanya digunakan pada fail css.
Secara lalai, semua tetapan dihidupkan tanpa sebarang sekatan. Anda boleh memisahkan berbilang arahan dengan koma bertitik, tetapi dalam bentuk skrip-src https://host1.com;script-src https://host2.com, arahan kedua akan diabaikan. Cara yang betul untuk menulisnya ialah skrip-src https://host1.com https://host2.com.
Contohnya, jika anda mempunyai aplikasi yang perlu memuatkan semua sumber daripada rangkaian penghantaran kandungan (CDN, seperti https://cdn.example.net), dan anda tahu bahawa tiada kandungan yang tidak memerlukan sebarang bingkai atau pemalam, strategi anda mungkin seperti berikut:
Content-Security-Policy:default-src https://cdn.example.net frame-src 'none';
Butiran
Saya gunakan dalam contoh Pengepala HTTP ialah Content-Security-Policy, tetapi penyemak imbas moden sudah menyediakan sokongan melalui awalan: Firefox menggunakan x-Content-Security-Policy, WebKit menggunakan X-WebKit-CSP. Akan ada peralihan beransur-ansur kepada piawaian bersatu pada masa hadapan.
Strategi boleh ditetapkan mengikut setiap halaman yang berbeza, yang memberikan fleksibiliti yang hebat. Kerana sesetengah halaman tapak anda mungkin mempunyai butang Google 1, manakala yang lain mungkin tidak.
Senarai sumber untuk setiap arahan boleh agak fleksibel, anda boleh menentukan corak (data:, https:), atau menentukan nama hos dalam julat (example.com, yang sepadan dengan mana-mana asal, sebarang corak dan mana-mana port pada hos ), atau tentukan URI yang lengkap (https://example.com:443, khususnya protokol https, nama domain example.com, port 443).
Terdapat empat lagi kata kunci yang boleh anda gunakan dalam senarai sumber anda:
"tiada": anda mungkin menjangkakan tidak sepadan dengan apa-apa
"diri": sama seperti sumber semasa, tetapi tanpa subdomain
"tidak selamat- dalam talian ": membenarkan Javascript sebaris dan CSS
"unsafe-eval": membenarkan mekanisme text-to-JS seperti eval
Sila ambil perhatian bahawa kata kunci ini perlu dipetik.
Kotak pasir
Terdapat satu lagi arahan yang patut dibincangkan di sini: kotak pasir. Ia agak tidak konsisten dengan arahan lain Ia terutamanya mengawal tindakan yang diambil pada halaman, dan bukannya sumber yang boleh dimuatkan oleh halaman tersebut. Jika atribut ini ditetapkan, halaman akan berkelakuan seperti bingkai dengan set atribut kotak pasir. Ini mempunyai pelbagai kesan pada halaman, seperti menghalang penyerahan borang, dsb. Ini sedikit di luar skop artikel ini, tetapi anda boleh mendapatkan maklumat lanjut dalam bab "Tetapan Bendera Kotak Pasir" pada spesifikasi HTML5.
Kod Sebaris Berbahaya
CSP adalah berdasarkan penyenaraian putih sumber, tetapi ia tidak dapat menyelesaikan sumber terbesar serangan XSS: suntikan skrip sebaris. Jika penyerang boleh menyuntik teg skrip (
) yang mengandungi kod berbahaya, penyemak imbas tidak mempunyai mekanisme yang baik untuk membezakan teg ini. CSP hanya boleh menyelesaikan masalah ini dengan melumpuhkan skrip sebaris sepenuhnya. Larangan ini termasuk bukan sahaja teg skrip yang dibenamkan dalam skrip, tetapi juga pengendali acara sebaris dan javascrpt: URL. Anda perlu meletakkan kandungan teg skrip ke dalam fail luaran dan menggantikan javascript: dan
dengan kaedah addEventListener yang sesuai. Sebagai contoh, anda mungkin menulis semula borang berikut:

Adakah saya hebat?
ke borang berikut:



Adakah saya hebat?

// amazing.js
fungsi doAmazingThings() {
alert('ANDA LUAR BIASA!');
}
dokumen. addEventListener('DOMContentReady', function () {
document.getElementById('amazing')
.addEventListener('click', doAmazingThings);
});
Sama ada menggunakan CSP atau tidak, The kod di atas sebenarnya mempunyai kelebihan yang lebih besar. JavaScript sebaris mencampurkan struktur dan tingkah laku sepenuhnya, dan anda tidak sepatutnya melakukannya. Selain itu, sumber luaran lebih mudah dicache oleh penyemak imbas, lebih mudah difahami oleh pembangun dan lebih mudah untuk disusun dan dimampatkan. Jika anda menggunakan kod luaran, anda akan menulis kod yang lebih baik.
Gaya sebaris perlu dikendalikan dengan cara yang sama, kedua-dua atribut gaya dan teg gaya perlu diekstrak ke dalam helaian gaya luaran. Ini menghalang semua jenis cara ajaib kebocoran data.
Jika anda mesti mempunyai skrip dan gaya sebaris, anda boleh menetapkan 'nilai sebaris tidak selamat untuk atribut skrip-src atau gaya-src. Tetapi jangan lakukan ini. Melumpuhkan skrip sebaris ialah jaminan keselamatan terbaik yang disediakan oleh CSP. Melumpuhkan gaya sebaris boleh menjadikan aplikasi anda lebih selamat dan mantap. Ia satu pertukaran, tetapi sangat berbaloi.
Eval
Walaupun penyerang tidak boleh menyuntik skrip secara langsung, dia boleh menipu aplikasi anda untuk menukar teks yang dimasukkan ke dalam skrip boleh laku dan melaksanakan sendiri. eval() , newFunction() , setTimeout([string], ...) dan setInterval([string], ...) semuanya boleh menjadi vektor bahaya ini. Strategi CSP untuk risiko ini adalah untuk menyekat vektor ini sepenuhnya.
Ini mempunyai beberapa implikasi untuk cara anda membina aplikasi anda:
Parse JSON melalui JSON.parse terbina dalam dan bukannya bergantung pada eval. Pelayar selepas IE8 menyokong operasi JSON tempatan, yang benar-benar selamat.
Tulis semula cara anda memanggil setTimeout dan setInterval dengan menggunakan fungsi sebaris dan bukannya rentetan. Contohnya:
setTimeout("document.querySelector('a').style.display = 'none';", 10);
Boleh ditulis semula sebagai:
setTimeout(function () { document. querySelector ('a').style.display = 'none'; }, 10;
Elakkan templat sebaris pada masa jalan: Banyak perpustakaan templat menggunakan Function() baharu untuk mempercepatkan penjanaan templat. Ini bagus untuk program dinamik, tetapi berisiko untuk teks berniat jahat.
Laporan<script>sendMyDataToEvilDotCom();</script> Keupayaan CSP untuk menyekat sumber yang tidak dipercayai pada bahagian pelayan adalah bagus untuk pengguna, tetapi sangat bagus untuk kami menerima pelbagai pemberitahuan yang dihantar ke pelayan supaya kami boleh mengenal pasti dan membetulkan sebarang suntikan skrip Hasad. Untuk melakukan ini, anda boleh mengarahkan penyemak imbas untuk menghantar laporan pemintasan dalam format JSON ke alamat tertentu melalui arahan report-uri. <script><br /> function doAmazingThings() {<br /> alert('YOU AM AMAZING!');<br /> }<br /></script>Polisi-Keselamatan-Kandungan: default-src 'self' ...;Laporan akan kelihatan seperti ini:
{
"csp-report": {
"document-uri": "http://example.org/page.html",
"referrer " : "http://evil.example.com/",
"blocked-uri": "http://evil.example.com/evil.js",
"violated-directive": " skrip -src 'self' https://apis.google.com",
"original-policy": "script-src 'self' https://apis.google.com report-uri http:// contoh .org/my_amazing_csp_report_parser"
}
}
Maklumat yang terkandung di dalamnya akan membantu anda mengenal pasti situasi pemintasan, termasuk halaman di mana pemintasan berlaku (document-uri), perujuk halaman dan sumber yang melanggar dasar halaman (uri disekat), arahan yang dilanggar dan semua dasar keselamatan kandungan halaman (dasar-asal).
Penggunaan Dunia Sebenar
CSP kini tersedia dalam Chrome 16 dan Firefox 4, dan ia dijangka mempunyai sokongan terhad dalam IE10. Safari belum menyokongnya lagi, tetapi binaan WebKit setiap malam tersedia, jadi harap Safari menyokongnya dalam lelaran seterusnya.
Mari lihat beberapa kes penggunaan biasa:
Kes praktikal 1: Widget media sosial
Butang Google 1 termasuk skrip daripada https://apis.google.com dan dibenamkan daripada https:// iframe for plusone .google.com. Strategi anda perlu memasukkan sumber ini untuk menggunakan butang Google 1. Strategi paling mudah ialah script-src https://apis.google.com; frame-src https://plusone.google.com. Anda juga perlu memastikan bahawa coretan JS yang disediakan oleh Google disimpan dalam fail JS luaran.
Terdapat banyak penyelesaian pelaksanaan untuk butang Suka Facebook. Saya syorkan anda kekal dengan versi iframe kerana ia kekal terpencil dari seluruh tapak anda. Ini memerlukan penggunaan arahan frame-src https://facebook.com. Sila ambil perhatian bahawa secara lalai, kod iframe yang disediakan oleh Facebook menggunakan laluan relatif //facebook.com Sila tukar kod ini kepada https://facebook.com Anda tidak boleh menggunakan HTTP jika perlu.
Butang Tweet Twitter bergantung pada skrip dan bingkai, kedua-duanya datang daripada https://platform.twitter.com (Twitter menyediakan URL relatif secara lalai, sila edit kod untuk menentukan HTTPS semasa menyalin).
Platform lain mempunyai situasi yang sama dan boleh diselesaikan dengan cara yang sama. Saya mengesyorkan menetapkan default-src kepada tiada, dan kemudian menyemak konsol untuk menyemak sumber yang anda perlukan untuk memastikan widget berfungsi dengan betul.
Menggunakan berbilang widget adalah sangat mudah: hanya gabungkan semua arahan strategi dan ingat untuk mengekalkan tetapan untuk arahan yang sama bersama-sama. Jika anda ingin menggunakan tiga widget di atas, strateginya akan kelihatan seperti ini:
script-src https://apis.google.com https://platform.twitter.com frame-src https:// plusone .google.com https://facebook.com https://platform.twitter.com
Kes Praktikal 2: Pertahanan
Katakan anda melawati tapak web bank dan ingin memastikan bahawa hanya sumber yang anda perlukan dimuatkan. Dalam kes ini, mulakan dengan menetapkan kebenaran lalai untuk menyekat semua kandungan (default-src 'tiada') dan membina dasar dari awal.
Sebagai contoh, tapak web bank perlu memuatkan imej, gaya dan skrip daripada CDN daripada https://cdn.mybank.net, dan menyambung ke https://api.mybank.com/ melalui XHR untuk menarik pelbagai data . Anda juga perlu menggunakan bingkai, tetapi bingkai datang daripada halaman tempatan bukan pihak ketiga. Tiada Flash, fon dan kandungan lain di tapak web. Dalam kes ini, pengepala CSP paling ketat yang boleh kami hantar ialah:
Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net style-src https:// cdn; .mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; Pentadbir forum cincin perkahwinan mahu semua sumber dimuatkan dengan cara yang selamat, tetapi tidak mahu menulis terlalu banyak kod menulis semula sejumlah besar skrip dan gaya sebaris forum pihak ketiga adalah di luar kemampuannya. Jadi dasar berikut akan sangat berguna:
Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; -src menentukan https, skrip dan gaya tidak diwarisi secara automatik. Setiap arahan akan menggantikan sepenuhnya jenis sumber lalai.
Masa Depan
Kumpulan Kerja Keselamatan Aplikasi Web W3C sedang merumuskan butiran spesifikasi dasar keselamatan kandungan Versi 1.0 akan memasuki peringkat semakan akhir, dan ia sangat hampir dengan perkara yang diterangkan dalam artikel ini. Kumpulan mel public-webappsec@ sedang membincangkan versi 1.1, dan pengeluar penyemak imbas juga sedang berusaha keras untuk menyatukan dan menambah baik pelaksanaan CSP.
CSP 1.1 mempunyai beberapa ciri menarik pada artboard yang bernilai disenaraikan secara berasingan:
Menambah dasar melalui teg meta: Cara pilihan untuk menetapkan CSP adalah melalui pengepala HTTP, yang sangat berguna, tetapi menetapkannya melalui teg atau skrip adalah lebih mudah , tetapi buat masa ini Belum dimuktamadkan lagi. WebKit telah melaksanakan ciri menetapkan kebenaran melalui elemen meta, jadi anda kini boleh mencuba tetapan berikut dalam Chrome: tambah pada pengepala dokumen.
Anda juga boleh menambah strategi melalui skrip semasa masa jalan.
API DOM: Jika lelaran CSP seterusnya menambahkan ciri ini, anda boleh menanyakan dasar keselamatan semasa halaman melalui Javascript dan melaraskannya mengikut situasi yang berbeza. Sebagai contoh, pelaksanaan kod anda mungkin sedikit berbeza jika eval() tersedia. Ini sangat berguna untuk pengarang rangka kerja JS dan memandangkan spesifikasi API pada masa ini sangat tidak pasti, anda boleh menemui lelaran terkini dalam bab Antara Muka Skrip bagi spesifikasi draf.
Arahan baharu: Banyak arahan baharu sedang dibincangkan, termasuk skrip-nonce: hanya elemen skrip yang dinyatakan secara eksplisit boleh menggunakan skrip sebaris: ini akan mengehadkan jenis pemalam-tindakan: membenarkan borang untuk hanya Serah kepada; sumber tertentu.
Jika anda berminat dalam perbincangan tentang ciri masa hadapan ini, anda boleh membaca arkib senarai mel atau menyertai senarai mel.
Artikel ini diterjemahkan daripada: http://www.html5rocks.com/en/tutorials/security/content-security-policy/
Dipetik daripada: blog Jiang Yujie