Kata pengantar
Dalam model pengembangan pemisahan front-end dan back-end, perubahan paling jelas dalam hal peran dan fungsi pengembangan adalah: Di masa lalu, siswa front-end yang hanya bertanggung jawab untuk pengembangan di lingkungan browser yang diperlukan untuk mengeksplorasi tingkat server-end dan menulis kode server-end. Dan pertanyaan dasar di hadapan kami adalah bagaimana memastikan keamanan web?
Artikel ini mengusulkan solusi untuk masalah keamanan yang dihadapi oleh mode pemisahan front-end dan back-end dalam pengembangan web front-end, serta penanggulangan dan tindakan pencegahan.
Defense of Cross-Site Scripting Attack (XSS)
Masalah dan solusi
Scripting lintas situs (XSS, scripting lintas situs) adalah metode yang paling umum dan dasar untuk menyerang situs web. Penyerang dapat mempublikasikan data yang berisi kode ofensif di halaman web. Ketika browser melihat halaman web ini, skrip tertentu akan dieksekusi sebagai identitas dan izin pengguna browser. XSS dapat lebih mudah dimodifikasi, mencuri data pengguna, informasi pengguna dan menyebabkan jenis serangan lainnya, seperti serangan CSRF.
Cara dasar untuk mencegah serangan XSS adalah dengan memastikan bahwa output data apa pun ke halaman HTML lolos di HTML (HTML Escape). Misalnya, kode template berikut:
Salinan kode adalah sebagai berikut:
<TextAreA Name = "Deskripsi"> $ Deskripsi </TextAreA>
Deskripsi $ dalam kode ini adalah variabel dari templat (sintaks variabel yang ditentukan dalam templat yang berbeda berbeda, berikut adalah diagram). Data yang dikirimkan oleh pengguna dapat memasukkan sepotong kode yang berisi "JavaScript" untuk membuat hasil dari pernyataan templat di atas menjadi hasil berikut:
Salinan kode adalah sebagai berikut:
<name TextArea = "Deskripsi">
</textarea> <script> alert ('hello') '</cript>
</textarea>
Kode di atas, diterjemahkan di browser, akan menjalankan kode JavaScript dan mengingatkan halo di layar. Tentu saja, kode ini tidak berbahaya, tetapi penyerang dapat membuat javascript untuk memodifikasi informasi pengguna atau mencuri data cookie.
Solusinya sangat sederhana, yaitu untuk menghindari nilai $ deskripsi. Kode output setelah melarikan diri adalah sebagai berikut
Salinan kode adalah sebagai berikut:
<name TextArea = "Deskripsi">
</pextarea> <script> waspada (halo!) </script>
</textarea>
Kode HTML yang lolos di atas tidak berbahaya.
Solusi Midway
Lepaskan semua data output pengguna di halaman
Ada beberapa situasi dan metode untuk melarikan diri dari data:
1. Melarikan diri menggunakan mekanisme yang disediakan di dalam template
Midway menggunakan Kissy Xtemplate sebagai bahasa template.
Dalam implementasi Xtemplate, data templat adalah sintaks yang diuraikan menggunakan dua braket ({{val}}). Secara default, data adalah HTML yang diloloskan, sehingga pengembang dapat menulis templat seperti ini:
Salinan kode adalah sebagai berikut:
<textarea name = "description"> {{description}} </textarea>
Di Xtemplate, jika Anda tidak ingin data output diloloskan, Anda perlu menggunakan tiga tanda kurung ({{{val}}}).
2. Sebutkan fungsi pelarian yang jelas di tengah jalan
Pengembang dapat secara langsung memanggil metode HTML Escape yang disediakan oleh Midway dalam program atau templat Node.js untuk melarikan diri dari data yang ditampilkan, sebagai berikut:
Metode 1: HTML Escape Data di Program Node.js
Salinan kode adalah sebagai berikut:
var security = membutuhkan ('midway-keamanan');
// Data dari server, misalnya {html: '</pextarea>', lainnya: ""}
data.html = Security.escapeHtml (data.html);
xtpl = xtpl.render (data);
Metode 2: HTML Escape HTML Data dalam Template
Salinan kode adalah sebagai berikut:
<TextAreA name = "description"> Security.escapeHtml ({{{{deskripsi}}}) </textarea>
Catatan: Security.escapeHTML digunakan untuk melarikan diri hanya ketika data tidak lolos di dalam templat. Kalau tidak, template internal dan program akan luput dari overlay dua kali, menghasilkan output yang tidak memenuhi harapan.
Direkomendasikan: Jika Anda menggunakan Xtemplate, disarankan untuk menggunakan {{}}} dari templat bawaan untuk melarikan diri secara langsung; Jika Anda menggunakan templat lain, disarankan untuk menggunakan Security.escapeHtml untuk melarikan diri.
Memfilter output teks kaya dari pengguna di halaman
Anda mungkin berpikir: "Sebenarnya, saya hanya ingin mengeluarkan teks yang kaya, seperti beberapa papan pesan dan forum untuk memberi pengguna ukuran font sederhana, warna, latar belakang, dan fungsi lainnya. Jadi bagaimana saya harus menangani teks yang kaya untuk mencegah XSS?"
1. Gunakan fungsi RichText yang disediakan oleh Security di Midway
Midway menyediakan metode RichText, yang secara khusus digunakan untuk memfilter teks yang kaya dan mencegah kerentanan seperti XSS, phishing, dan pencurian kue.
Ada papan pesan, dan kode template mungkin sebagai berikut:
Salinan kode adalah sebagai berikut:
<div>
{{{pesan}}}
</div>
Karena pesan adalah data input pengguna, konten papan pesannya berisi informasi teks yang kaya, di sini tiga kawat gigi digunakan dalam xtemplate, dan pelarian HTML tidak dilakukan secara default; Kemudian data yang dimasukkan oleh pengguna adalah sebagai berikut:
Salinan kode adalah sebagai berikut:
<skrip src = "http://eval.com/eval.js"> </script> <span style = "color: red; font-size: 20px; Posisi: fixed;"> Saya meninggalkan pesan </span>
Jika data teks yang kaya di atas secara langsung output ke halaman, itu pasti akan mengarah pada injeksi JS dari situs eval.com ke halaman saat ini, menyebabkan serangan XSS. Untuk mencegah kerentanan ini, kami hanya memanggil metode Security.RichText dalam templat atau program untuk memproses input teks yang kaya oleh pengguna.
Metode panggilan mirip dengan EscapeHtML, dan ada dua cara untuk
Metode 1: Hubungi langsung di program Node.js
Salinan kode adalah sebagai berikut:
pesan = Security.RichText (pesan);
var html = xtpl.render (pesan)
Metode 2: Panggil dalam templat
Salinan kode adalah sebagai berikut:
<div>
Security.richText ({{{pesan}}})
</div>
Setelah memanggil metode keamanan RichText, output akhir adalah sebagai berikut:
Salinan kode adalah sebagai berikut:
<div>
<span style = "color: red; font-size: 20px;"> Saya meninggalkan pesan </span>
</div>
Dapat dilihat bahwa terlebih dahulu: Tag skrip yang akan menyebabkan serangan XSS akan disaring secara langsung; Pada saat yang sama, posisi atribut CSS: diperbaiki; Gaya dalam tag gaya juga difilter. Akhirnya, teks kaya HTML yang tidak berbahaya adalah output
Pelajari tentang cara lain untuk berpotensi menyebabkan serangan XSS
Selain kemungkinan serangan XSS di templat halaman, ada beberapa cara lain dalam aplikasi web yang mungkin juga berisiko.
1. Kerentanan di halaman kesalahan
Jika halaman tidak dapat ditemukan, sistem dapat melaporkan kesalahan 404 yang tidak ditemukan, misalnya: http: // localhost/page/tidak/ditemukan
404 NOTFOUND
Halaman/halaman/tidak/ditemukan tidak exsit
Jelas: penyerang dapat menggunakan halaman ini untuk membangun koneksi seperti ini, http: // localhost/%3cscript%3alert%28%27hello%27%29%3c%2fscript%3e, dan memikat korban untuk mengklik; Jika halaman kesalahan tidak luput dari variabel output, maka <script> alert ('hello') </script> tersembunyi di koneksi akan dieksekusi.
Di Express, metode pengiriman halaman 404 adalah sebagai berikut
res.send (404, 'Maaf, kami tidak menemukan itu!')
Di sini, pengembang perlu memperhatikan penanganan halaman kesalahan (404 atau status kesalahan lainnya). Jika konten pengembalian pesan kesalahan berisi informasi jalur (pada kenyataannya, lebih akurat, informasi input pengguna), Anda harus melakukan pelarian.
Selanjutnya, mekanisme keamanan penanganan kesalahan akan diselesaikan di tingkat kerangka kerja tengah.
Catatan Tambahan untuk Solusi Midway
Mesin template lainnya
Midway mendukung templat xtemplate secara default, tetapi juga dapat mendukung templat lain di masa depan: seperti batu giok, kumis, EJS, dll. Saat ini, dalam templat arus utama, default yang melarikan diri dan metode penulisan variabel output yang tidak dibatasi disediakan, dan pengembang perlu memberikan perhatian khusus pada keamanan mereka.
Dukungan lain untuk melarikan diri
Selain output data teks normal dan kaya pada halaman, beberapa skenario juga mencakup situasi lain yang mungkin memerlukan pelarian. Midway memberikan metode pelarian yang umum digunakan berikut untuk digunakan pengembang:
EscapeHTML menyaring karakter dalam html tertentu untuk mencegah kerentanan XSS
Jsencode JavaScript Escape dari string input. Unicode Escape of Chinese, Single Quotes, dan Double Quotes Escape
EscapeJson tidak menghancurkan fungsi melarikan diri dari struktur JSON, dan hanya melakukan pelarian dari pemrosesan pada nama dan vaule dalam struktur JSON
EscapeJsonforjsvar dimengerti jsencode+EscapeJson
Contohnya adalah sebagai berikut
Salinan kode adalah sebagai berikut:
var jsontext = "{/" <script>/":/" <script>/"}";
console.log (Securityutil.escapeJson (jsontext)); // {"<script>": "<script>"}
var jsontext = "{/" hello/":/" <script>/"}";
console.log (Securityutil.escapeJsonforjsvar (jsontext)); // {/"/u4f60/u597d/":/"<script>/"}
var str = "alert (/" hello/")";
Console.log (Securityutil.jsencode (str)); // waspada (/"/u4f60/u597d/")
Pencegahan Serangan Pemalsuan Permintaan Lintas Situs (CSRF)
Masalah dan solusi
Definisi istilah: Formulir: mengacu pada formulir yang digunakan oleh browser untuk mengirimkan data pada klien; Termasuk tag, data pengiriman AJAX, data pengiriman formulir, dll., Daripada tag formulir yang sama dengan HTML.
Pemalsuan Permintaan Lintas Situs (CSRF, Pemalsuan Permintaan Lintas Situs) adalah serangan umum lainnya. Penyerang memalsukan permintaan melalui berbagai metode dan meniru perilaku pengguna untuk mengirimkan formulir, sehingga mencapai tujuan memodifikasi data pengguna atau melakukan tugas -tugas tertentu.
Untuk berpura -pura menjadi pengguna, serangan CSRF sering dikombinasikan dengan serangan XSS, tetapi cara lain dapat digunakan: misalnya, untuk menginduksi pengguna untuk mengklik tautan yang berisi serangan.
Gagasan menyelesaikan serangan CSRF dibagi menjadi dua langkah.
1. Tingkatkan kesulitan serangan. Dapatkan permintaan mudah dibuat. Pengguna dapat memulai permintaan tipe GET dengan mengklik tautan. Permintaan pasca relatif sulit. Penyerang sering perlu menggunakan JavaScript untuk mengimplementasikannya. Oleh karena itu, memastikan formulir formulir atau antarmuka server hanya menerima permintaan pengiriman pasca-tipe dapat meningkatkan keamanan sistem.
2. Otentikasi permintaan untuk memastikan bahwa permintaan memang mengisi formulir atau memulai permintaan dan diserahkan oleh pengguna, daripada dipalsukan oleh pihak ketiga.
Proses informasi situs web yang memodifikasi pengguna normal adalah sebagai berikut
Permintaan Pengguna Untuk Memodifikasi Informasi (1) -> Situs Web Menampilkan Formulir Informasi Modifikasi Pengguna (2) -> Pengguna Mengubah Informasi dan Kirim (3) -> Situs Web Menerima data yang dimodifikasi pengguna dan menyimpan (4)
Serangan CSRF tidak akan mengambil rute ini, tetapi akan secara langsung memalsukan informasi pengiriman pengguna pada langkah 2.
Lewati langsung ke langkah 2 (1) -> tempa informasi yang akan dimodifikasi dan kirim (2) -> Situs web menerima penyerang untuk memodifikasi data parameter dan menyimpan (3)
Selama kedua situasi ini dapat dibedakan, serangan CSRF dapat dicegah. Jadi bagaimana cara membedakannya? Ini untuk memverifikasi informasi yang dikirimkan pada Langkah 2 untuk memastikan bahwa data berasal dari formulir pada langkah 1. Proses verifikasi spesifik adalah sebagai berikut:
Permintaan pengguna untuk memodifikasi informasi (1) -> Situs web menampilkan formulir kosong yang digunakan untuk memodifikasi informasi. Formulir ini berisi token khusus dan menyimpan token di sesi (2) -> pengguna memodifikasi informasi dan mengirimkannya, dan mengirimkan kembali informasi token ke server (3) -> Situs web membandingkan token yang dikirim kembali oleh pengguna dan token di sesi. Itu harus konsisten. Kemudian data yang dimodifikasi oleh pengguna diterima dan disimpan.
Dengan cara ini, jika penyerang memalsukan informasi yang akan dimodifikasi dan diserahkan, ia tidak akan dapat secara langsung mengakses sesi tersebut, sehingga ia tidak akan bisa mendapatkan nilai token yang sebenarnya; Jika permintaan dikirim ke server, ketika server melakukan verifikasi token, akan ditemukan bahwa itu tidak konsisten, dan permintaan ditolak secara langsung.
Solusi Midway
Nonaktifkan Formulir Pengiriman Dapatkan
Jika server tidak menerima data formulir yang dikirimkan oleh GET, itu akan menyebabkan kesulitan besar bagi penyerang; Karena sangat mudah untuk membangun atribut A-Label HREF atau atribut IMG-Label SRC pada halaman untuk membuat permintaan, tetapi jika Anda ingin mengirimkannya, Anda harus menggunakan skrip untuk mengimplementasikannya.
Verifikasi permintaan dengan token CSRF
Karena Midway tidak melibatkan logika sesi terdistribusi Taobao dan verifikasi token, dalam kerangka kerja tengah, hanya token yang diteruskan antara server dan klien, dan tidak melakukan pekerjaan verifikasi yang sebenarnya. Prosesnya adalah sebagai berikut:
Selanjutnya: Di tengah jalan, setelah sesi yang didistribusikan dari Node.js dan Taobao terhubung, Anda dapat mempertimbangkan secara otomatis melakukan verifikasi token di lapisan tengah; Lagi pula, semakin awal verifikasi keamanan dilakukan, semakin rendah biaya.
Saran: Di tengah jalan, Anda dapat menentukan apakah ada nilai token dalam permintaan. Jika operasi modifikasi tidak memiliki token, Anda dapat secara langsung mempertimbangkannya di lapisan tengah untuk tidak aman dan membuang permintaan tersebut.
Masalah keamanan lainnya
Ada beberapa masalah keamanan web yang umum. Berikut adalah beberapa perkenalan dan akan terus diwarisi ke dalam kerangka kerja tengah di masa depan.
Keamanan header http
Penyerang injeksi CRLF menemukan cara untuk menyuntikkan dua karakter khusus CRLF ke header respons, menghasilkan format data respons yang luar biasa, dengan demikian menyuntikkan skrip, dll.
Menolak serangan akses setiap permintaan karena cookie dibawa secara default, dan server umumnya membatasi ukuran cookie, yang mengarah pada itu jika cookie klien pengguna diatur untuk melebihi ambang batas tertentu, pengguna tidak akan lagi dapat mengakses situs web.
Pencegahan dan Kontrol Cookie, Pencurian Cookie Umum diperoleh melalui JavaScript (kerentanan XSS), jadi cobalah untuk mengatur cookie hanya ke HTTP dan tambahkan waktu kedaluwarsa cookie
Mengenai masalah keamanan cookie, WebX telah memiliki solusi yang baik sebelumnya; Kali ini Midway tidak bertanggung jawab atas pengaturan dan verifikasi cookie, dan hanya bertanggung jawab untuk meneruskan ke tingkat webx untuk memeriksa.
Tentang node.js
Kerentanan injeksi seperti XSS adalah yang paling mudah diabaikan di antara semua kerentanan, menyumbang lebih dari 70% dari total serangan Internet; Saat menulis kode Node.js, pengembang harus selalu mengingatkan diri mereka sendiri dan tidak pernah mempercayai masukan pengguna.
Misalnya, contoh -contoh berikut.
var mod = fs.readfileSync ('path'); Jika jalur berasal dari input pengguna, maka dengan asumsi bahwa pengguna masuk /etc /password, konten yang tidak boleh dibaca akan dibaca, menyebabkan risiko kebocoran kata sandi
var result = eval (jsonval); Pastikan untuk memastikan jsonval adalah json, bukan input pengguna
... Di tempat lain yang mungkin berisi input pengguna, pastikan untuk mengonfirmasi bahwa input pengguna adalah nilai yang kami harapkan.
Meringkaskan
Dalam mode pemisahan front-end dan back-end, pengembang front-end tradisional dapat mulai menulis kode back-end. Meskipun arsitektur hanya bertanggung jawab untuk lapisan templat, mereka juga akan terpapar dengan sejumlah besar kode back-end; Oleh karena itu, keamanan adalah tantangan besar bagi front-end.