Mencari Masalah Keselamatan
20 minitPertengahanHTML · CSS · JS
Dalam pelajaran ini
- ▸Terangkan bagaimana memasukkan input pengguna dengan
innerHTMLmembuka ruang cross-site scripting (XSS), dan paparkannya dengan selamat - ▸Tahu bahawa semua yang dihantar ke pelayar adalah awam, termasuk key yang "tersembunyi"
- ▸Buat validasi di server, kerana semakan di client boleh dipintas
Idea utama
Kod jana AI dioptimumkan untuk berfungsi bagi orang yang memintanya. Keselamatan ialah tentang apa yang berlaku bila orang lain sengaja menggunakannya dengan cara yang anda tidak jangka.
Buku tetamu dalam editor berfungsi dengan sempurna untuk pelawat yang jujur. Sekarang fikir seperti pelawat yang tidak jujur. Pelajaran ini merangkumi tiga masalah yang berulang kali muncul dalam kod web jana AI. Ia titik permulaan, bukan kursus keselamatan yang lengkap.
1. Input pengguna + innerHTML = XSS
innerHTML membaca string sebagai HTML. Jika string itu mengandungi apa yang ditaip pelawat, pelawat itulah yang menulis HTML halaman anda. Mesej seperti <img src=x onerror="…"> menjadi imej sebenar yang onerror-nya menjalankan JavaScript mereka dalam pelayar pelawat lain — itulah cross-site scripting (XSS). Ia boleh membaca apa yang dipaparkan halaman, bertindak sebagai pengguna yang log masuk, atau mengalihkan mereka.
Apa yang ditulis pembantu AI
list.innerHTML += `<li><strong>${name}</strong>: ${message}</li>`;Apa yang dihantar oleh penyemak
const li = document.createElement("li");
const strong = document.createElement("strong");
strong.textContent = name; // text, never parsed as HTML
li.append(strong, ": " + message); // strings become text nodes
list.appendChild(li);textContent, append("…") dan createTextNode melayan input sebagai teks. React juga escape teks dalam JSX dengan cara yang sama — tetapi dangerouslySetInnerHTML membawa masalah itu kembali.
2. Rahsia dalam kod frontend
Setiap fail yang dimuat turun pelayar boleh dibaca sesiapa: View Source, DevTools, atau sekadar memuat turun bundle JavaScript anda. Secret key dalam kod frontend ialah key yang diterbitkan. Ia mesti tinggal di server (dimuat daripada environment variable, dengan fail .env dikecualikan daripada git), dan pelayar hanya patut menerima hasil penggunaannya. Jika key sebenar pernah dihantar atau di-commit, tukar (rotate) key itu.
Sesetengah penyedia mengeluarkan key yang memang direka untuk awam (selalunya dipanggil publishable atau client key) dengan kebenaran terhad. Semak dokumentasi penyedia — dan jika key itu dipanggil "secret", ia tidak sekali-kali patut berada dalam pelayar.
3. Mempercayai validasi di client
maxlength="140" dan if dalam handler submit bagus untuk pengalaman pengguna. Tetapi ia bukan keselamatan: penyerang boleh menyunting halaman dalam DevTools, atau langsung tidak guna halaman anda dan memanggil API dengan tool seperti curl. Server mesti menyemak setiap input seolah-olah borang itu tidak wujud.
Meminta semakan keselamatan
Berbaloi untuk bertanya pembantu AI: "Semak kod ini untuk XSS, rahsia yang terdedah, validasi server yang tiada dan semakan kebenaran (authorisation). Tunjukkan baris yang tepat." Anggap jawapannya sebagai petunjuk untuk disahkan, bukan sijil bersih — dan jangan sekali-kali tampal rahsia sebenar semasa bertanya.
Hantar komen dengan mesej ini dan lihat apa yang muncul:
<img src=x onerror="document.body.style.background='red'">
Kemudian baiki handler submit dalam script.js supaya nama dan mesej sentiasa dipaparkan sebagai teks: bina <li> dengan createElement dan textContent (atau append) dan bukannya innerHTML.
Semakan
- HTML yang ditaip pelawat tidak menjadi elemen sebenar
- Komen biasa masih dipaparkan
Uji kefahaman
Apa yang anda pelajari
- ✓Paparkan input pengguna dengan
textContent/createElement, jangan sekali-kali dengan membina string HTML untukinnerHTML. - ✓Semua dalam kod frontend adalah awam. Rahsia tinggal di server; key yang bocor mesti ditukar.
- ✓Validasi di client ialah UX; validasi di server ialah keselamatan.
Output konsol daripada kod anda akan dipaparkan di sini.