Komentar: Kata Pengantar: Setelah HTML5 muncul, keamanan jaringan telah menarik lebih banyak perhatian luas. Perbaikan apa yang dilakukan web untuk keamanan jaringan? Bagaimana kita menghadapi penipuan dan serangan cyber yang semakin berbahaya? Artikel berikut berbicara tentang solusi terbaru W3C untuk masalah ini. Jika saya memiliki kesempatan di masa depan, saya akan melakukan konten HTML5 di XSS, P3P, kebijakan homolog, CORS (berbagi sumber daya domain lintas) dan CSP.
Kebijakan keamanan World Wide Web berakar pada kebijakan homolog. Misalnya, kode hanya dapat mengakses data, tetapi tidak memiliki izin akses. Setiap sumber dipisahkan dari sisa jaringan, membuat kotak pasir yang aman untuk pengembang. Ini sempurna dalam teori, tetapi sekarang para penyerang telah menemukan cara yang cerdas untuk menghancurkan sistem.Ini adalah serangan scripting lintas-situs XSS, melewati kebijakan homolog melalui konten palsu dan trik klik. Ini adalah masalah besar, jika penyerang berhasil menyuntikkan kode, sejumlah besar data pengguna akan bocor.
Sekarang kami memperkenalkan strategi pertahanan keamanan yang baru dan efektif untuk mengurangi risiko ini, yaitu kebijakan Contentsecurity (CSP).
Sumber WhiteList
Inti dari serangan XSS adalah bahwa browser tidak dapat mengetahui apakah skrip disuntikkan oleh pihak ketiga atau benar -benar bagian dari aplikasi Anda. Misalnya, tombol Google +1 akan memuat dan menjalankan kode dari https://apis.google.com/js/plusone.js, tetapi kami tidak dapat berharap untuk mengetahui dari gambar di browser apakah kode tersebut benar -benar dari apis.google.com atau dari apis.evil.example.com. Browser mengunduh dan menjalankan permintaan halaman untuk kode apa pun, terlepas dari sumbernya.
CSP mendefinisikan header keamanan-keamanan-policyhttp untuk memungkinkan Anda membuat daftar putih sumber tepercaya, sehingga browser hanya mengeksekusi dan membuat sumber daya dari sumber-sumber tersebut, daripada secara membabi buta mempercayai segala sesuatu yang disediakan oleh server. Bahkan jika penyerang dapat menemukan kerentanan untuk menyuntikkan skrip, itu tidak akan dieksekusi karena sumbernya tidak termasuk dalam daftar putih.
Tombol Google +1 di atas adalah contoh, karena kami percaya bahwa apis.google.com menyediakan kode yang valid, serta diri kami sendiri, kami dapat mendefinisikan kebijakan yang memungkinkan browser untuk menjalankan skrip dari salah satu dari dua sumber di bawah ini.
Konten-Security-Policy: Script-Src 'Self' https://apis.google.com
Bukankah itu sangat sederhana? Script-SRC dapat mengontrol izin terkait skrip untuk halaman tertentu. Dengan cara ini browser hanya akan mengunduh dan menjalankan skrip dari dan dari halaman ini sendiri.
Setelah kami mendefinisikan kebijakan ini, browser akan melakukan kesalahan ketika mendeteksi kode yang disuntikkan (perhatikan apa browser itu).
Kebijakan keamanan konten berlaku untuk semua sumber daya umum
Meskipun sumber daya skrip adalah risiko keamanan yang paling jelas, CSP juga memberikan serangkaian instruksi yang kaya yang memungkinkan halaman untuk mengontrol pemuatan berbagai jenis sumber daya, seperti jenis berikut:
Konten-SRC: Batasi jenis koneksi (mis. XHR, WebSockets, dan EventSource)
Font-SRC: Mengontrol sumber font jaringan. Misalnya, Anda dapat menggunakan font web Google melalui font-src https://themes.googleusercontent.com.
Frame-SRC: Daftar sumber bingkai yang dapat disematkan. Misalnya, frame-src https://youtube.com hanya memungkinkan video yang tertanam di YouTube. .
IMG-SRC: Menentukan sumber gambar yang dapat dimuat.
Media-SRC: Batasi sumber video dan audio.
Object-SRC: Batasi sumber flash dan plugin lainnya.
Style-SRC: Mirip dengan skrip-src, itu hanya berfungsi pada file CSS.
Secara default, semua pengaturan aktif tanpa batasan apa pun. Anda dapat memisahkan beberapa instruksi dengan titik koma, tetapi mirip dengan skrip-src https: //host1.com; Script-src https://host2.com, instruksi kedua akan diabaikan. Cara yang benar untuk menulisnya adalah skrip-src https://host1.com https://host2.com.
Misalnya, Anda memiliki aplikasi yang perlu memuat semua sumber daya dari jaringan distribusi konten (CDN, misalnya https://cdn.example.net) dan ketahuilah bahwa konten tidak ada frame dan plugin diperlukan, strategi Anda mungkin terlihat seperti ini:
Konten-keamanan-polis: default-src https://cdn.example.net; bingkai-src 'tidak ada'; objek-src 'tidak ada'
Detail
Header HTTP yang saya gunakan dalam contoh saya adalah kebijakan-keamanan konten, tetapi browser modern telah memberikan dukungan melalui awalan: Firefox menggunakan kebijakan X-Content-Security, WebKit menggunakan X-Webkit-CSP. Di masa depan, secara bertahap akan beralih ke standar terpadu.
Strategi dapat diatur untuk setiap halaman yang berbeda, yang memberikan banyak fleksibilitas. Karena beberapa halaman di situs Anda mungkin memiliki tombol Google +1, sementara yang lain tidak.
Daftar sumber dari setiap instruksi bisa sangat fleksibel. Anda dapat menentukan pola (data:, https :), atau tentukan nama host dalam rentang (example.com, yang cocok dengan sumber apa pun, mode apa pun dan port apa pun pada host), atau tentukan URI lengkap (https://example.com:443, khususnya protokol https, nama domain example.com, port 443).
Anda juga dapat menggunakan empat kata kunci dalam daftar sumber:
Tidak ada: Anda mungkin berharap untuk tidak cocok dengan apa pun
Diri: Sama seperti sumber saat ini, tetapi tidak mengandung subdomain
Tidak aman-inline: Memungkinkan inline JavaScript dan CSS
UNCEMAL-EVAL: Mekanisme yang memungkinkan teks ke JS, seperti eval
Harap dicatat bahwa kata kunci ini perlu dikutip.
Bak pasir
Ada instruksi lain yang layak dibahas di sini: Sandbox. Ini agak tidak konsisten dengan instruksi lain. Ini terutama mengontrol perilaku yang diambil pada halaman, daripada sumber daya yang dapat dimuat halaman. Jika properti ini diatur, halaman akan berperilaku seperti bingkai dengan set properti Sandbox. Ini memiliki berbagai dampak pada halaman, seperti mencegah pengiriman formulir, dll. Ini sedikit di luar ruang lingkup artikel ini, tetapi Anda dapat menemukan lebih banyak informasi di bagian Pengaturan Logo Sandbox Spesifikasi HTML5.
Kode inline berbahaya
CSP didasarkan pada daftar putih sumber, tetapi tidak menyelesaikan sumber terbesar serangan XSS: inline Script Injection. Jika penyerang dapat menyuntikkan tag skrip yang berisi kode berbahaya (<script> sendmydatoevildotcom (); </script>), browser tidak memiliki mekanisme yang baik untuk membedakan tag ini. CSP hanya dapat menyelesaikan masalah ini dengan melarang skrip inline sepenuhnya.
Larangan ini tidak hanya mencakup tag skrip yang tertanam dalam skrip, tetapi juga inline event handlers dan javascrpt: URL. Anda perlu memasukkan konten tag skrip ke dalam file eksternal dan mengganti JavaScript: dan <a… onclick = [javaScript]> dengan addeventListener yang sesuai. Misalnya, Anda dapat meletakkan formulir berikut:
<script>
fungsi doamazingthings () {
waspada ('Anda luar biasa!');
}
</script>
<button> Apakah saya luar biasa? </button>
Tulis ulang ke bentuk berikut:
<!-Amazing.html->
<Script src = 'Amazing.js'> </script>
<button> Apakah saya luar biasa? </button>
// Amazing.js
fungsi doamazingthings () {
waspada ('Anda luar biasa!');
}
Document.addeventListener ('DomContentReady', function () {
document.geteLementById ('luar biasa')
.addeventListener ('klik', doamazingthings);
});
Terlepas dari apakah Anda menggunakan CSP atau tidak, kode di atas sebenarnya memiliki keunggulan yang lebih besar. JavaScript inline benar -benar memadukan struktur dan perilaku, Anda seharusnya tidak melakukannya. Selain itu, sumber daya penjangkauan lebih mudah disimpan di browser, lebih mudah dipahami pengembang, dan mudah dikompilasi dan dikompres. Jika Anda menggunakan kode penjangkauan, Anda akan menulis kode yang lebih baik.
Gaya inline perlu diproses dengan cara yang sama, baik atribut gaya dan tag gaya perlu diekstraksi ke dalam stylesheet eksternal. Ini dapat mencegah semua jenis kebocoran data magis.
Jika Anda harus memiliki skrip dan gaya inline, Anda dapat mengatur nilai 'tidak aman untuk skrip-SRC atau atribut gaya-SRC. Tapi jangan lakukan ini. Forbidding Inline Script adalah jaminan keamanan maksimum yang disediakan oleh CSP. Pada saat yang sama, melarang gaya inline dapat membuat aplikasi Anda lebih aman dan lebih kuat. Ini trade-off, tapi itu sangat berharga.
Evaluasi
Bahkan jika penyerang tidak dapat menyuntikkan skrip secara langsung, ia dapat menginduksi aplikasi Anda untuk mengubah teks yang dimasukkan menjadi skrip yang dapat dieksekusi dan menjalankannya sendiri. eval (), newFunction (), setTimeout ([string], ...) dan setInterval ([string], ...) semuanya bisa menjadi pembawa berbahaya. Strategi untuk CSP untuk menargetkan risiko ini adalah memblokir vektor -vektor ini sama sekali.
Ini memiliki beberapa implikasi tentang cara Anda membangun aplikasi Anda:
Parse Json melalui json.parse bawaan tanpa mengandalkan eval. Browser setelah IE8 mendukung operasi JSON lokal, yang benar -benar aman.
Tulis ulang metode panggilan setTimeout dan setInterval dengan fungsi inline alih -alih string. Misalnya:
setTimeout (document.queryselector ('a'). style.display = 'none';, 10);
Dapat ditulis ulang sebagai:
setTimeout (function () {document.queryselector ('a'). style.display = 'none';}, 10);
Hindari templat inline saat runtime: Banyak perpustakaan template menggunakan fungsi baru () untuk mempercepat pembuatan templat. Ini bagus untuk program dinamis, tetapi berisiko untuk teks jahat.
Laporan
CSP dapat memblokir sumber daya yang tidak dipercaya di sisi server, yang sangat berguna bagi pengguna, tetapi sangat berguna bagi kami untuk mendapatkan berbagai pemberitahuan yang dikirim ke server, sehingga kami dapat mengidentifikasi dan memperbaiki suntikan skrip berbahaya. Untuk tujuan ini, Anda dapat menginstruksikan browser untuk mengirim laporan intersep dalam format JSON ke alamat melalui Petunjuk Laporan-URI.
Konten-keamanan-kebijakan: default-src 'self'; ...; Report-URI /my_amazing_csp_report_parser;
Laporan akan terlihat seperti ini:
{
CSP-Report: {
Dokumen-Uuri :,
Penanggulangan :,
Blocked-Uuri :,
Violent-Directive: Script-Src 'Self' https://apis.google.com,
original-policy: script-src 'self' https://apis.google.com; Laporan-Uuri
}
}
Informasi yang terkandung di dalamnya akan membantu Anda mengidentifikasi situasi pemblokiran, termasuk dokumen-URI yang terjadi, pengirim halaman, sumber daya yang melanggar kebijakan halaman, arahan yang dilanggar, dan kebijakan asli dari semua konten halaman.
Penggunaan realistis
CSP sekarang tersedia di browser Chrome 16+ dan Firefox 4+, dan diharapkan menerima dukungan terbatas pada IE10. Safari belum didukung, tetapi Webkit Nightly Build tersedia, jadi diharapkan bahwa Safari akan didukung dalam iterasi di bawah ini.
Mari kita lihat beberapa kasus penggunaan yang umum digunakan di bawah ini:
Kasus Aktual 1: Widget Media Sosial
Tombol Google +1 termasuk skrip dari https://apis.google.com, serta iframes yang tertanam dari https://plusone.google.com. Kebijakan Anda perlu memasukkan sumber -sumber ini untuk menggunakan tombol Google+1. Strategi termudah adalah skrip-src https://apis.google.com; frame-src https://plusone.google.com. Anda juga perlu memastikan bahwa fragmen JS yang disediakan oleh Google disimpan dalam file JS eksternal.
Ada banyak solusi implementasi untuk tombol suka Facebook. Saya sarankan Anda tetap berpegang pada versi iframe karena tetap terisolasi dengan baik dari seluruh situs Anda. Ini membutuhkan penggunaan arahan bingkai-src https://facebook.com. Harap dicatat bahwa secara default, kode iframe yang disediakan oleh Facebook menggunakan jalur relatif //facebook.com. Harap ubah kode ini ke https://facebook.com. Tidak perlu http tidak digunakan.
Tombol tweet Twitter tergantung pada skrip dan bingkai, keduanya dari https://platform.twitter.com (Twitter menyediakan URL relatif secara default, silakan edit kode saat menyalin untuk menentukannya sebagai https).
Platform lain memiliki situasi yang sama dan dapat diselesaikan dengan cara yang sama. Saya merekomendasikan pengaturan default-src ke tidak ada dan kemudian melihat konsol untuk memeriksa sumber daya mana yang perlu Anda gunakan untuk memastikan widget berfungsi dengan baik.
Menggunakan beberapa widget sangat sederhana: gabungkan semua arahan kebijakan dan ingatlah untuk meletakkan pengaturan dari arahan yang sama bersama -sama. Jika Anda ingin menggunakan tiga widget di atas, strateginya akan terlihat 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
Kasus aktual 2: Pertahanan
Misalkan Anda mengunjungi situs web perbankan dan ingin memastikan bahwa hanya sumber daya yang Anda butuhkan. Dalam hal ini, mulailah mengatur izin default untuk memblokir semuanya (default-src 'none') dan membangun kebijakan dari awal.
Misalnya, situs web bank perlu memuat gambar, gaya, dan skrip dari CDN dari https://cdn.mybank.net, dan terhubung ke https://api.mybank.com/ melalui XHR untuk menarik berbagai data. Ini juga perlu menggunakan bingkai, tetapi frame semuanya dari halaman lokal non-ketiga. Tidak ada flash, font, dan konten lain di situs web. Dalam hal ini kita dapat mengirimkan header CSP yang paling ketat adalah:
Konten-keamanan-kebijakan: 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; bingkai-src 'diri'
Kasus aktual 3: Gunakan hanya SSL
Administrator forum cincin kawin ingin semua sumber daya dimuat dengan cara yang aman, tetapi tidak ingin benar -benar menulis terlalu banyak kode; Menulis ulang sejumlah besar skrip inline forum pihak ketiga dan gaya berada di luar kemampuannya. Jadi strategi berikut akan sangat berguna:
Konten-keamanan-kebijakan: default-src https:; Script-Src https: 'tidak aman-inline'; Style-Src https: 'tidak aman'
Meskipun default-SRC menentukan HTTPS, skrip dan gaya tidak diwariskan secara otomatis. Setiap arahan akan sepenuhnya mengganti jenis sumber daya default.
masa depan
Kelompok Kerja Keamanan Aplikasi Web W3C sedang mengembangkan rincian spesifikasi kebijakan keamanan konten. Versi 1.0 akan memasuki tahap revisi akhir, yang sangat dekat dengan apa yang dijelaskan dalam artikel ini. Grup Public-Webappsec@ Email sedang membahas versi 1.1, dan produsen browser juga bekerja keras untuk mengkonsolidasikan dan meningkatkan implementasi CSP.
CSP 1.1 memiliki beberapa hal menarik di artboard yang layak dicantumkan secara terpisah:
Menambahkan kebijakan melalui tag meta: Cara yang disukai untuk mengatur CSP adalah header HTTP, yang sangat berguna, tetapi akan lebih langsung melalui tag atau skrip, tetapi belum diselesaikan. WebKit telah mengimplementasikan fitur pengaturan izin melalui elemen meta, sehingga Anda sekarang dapat mencoba pengaturan berikut di Chrome: Tambahkan <metahttp-equiv = x-webkit-csp konten = [Kebijakan pergi ke sini]> ke header dokumen.
Anda bahkan dapat menambahkan kebijakan melalui skrip saat runtime.
DOM API: Jika fitur ini ditambahkan ke iterasi CSP berikutnya, Anda dapat menanyakan kebijakan keamanan halaman saat ini melalui JavaScript dan menyesuaikannya sesuai dengan situasi yang berbeda. Misalnya, jika eval () tersedia, implementasi kode Anda mungkin sedikit berbeda. Ini sangat berguna bagi penulis JS Framework; Dan spesifikasi API masih sangat tidak pasti, Anda dapat menemukan iterasi terbaru di bagian antarmuka skrip dari spesifikasi draft.
Arahan baru: Banyak arahan baru sedang dibahas, termasuk non-nonce: inline skrip hanya dapat digunakan jika elemen skrip yang ditentukan secara eksplisit digunakan; Jenis Plugin: Ini akan membatasi jenis plugin; Bentuk-aksi: Izinkan formulir untuk diserahkan ke sumber tertentu saja.
Jika Anda tertarik dengan diskusi tentang fitur -fitur masa depan ini, Anda dapat membaca arsip milis atau menambahkannya ke milis.
Artikel ini diterjemahkan dari:
Dikutip dari: Blog Jiang Yujie