Senarai semak keselamatan CFML sebelum produksi

Senarai semak keselamatan CFML sebelum produksi

Senarai semak keselamatan bukan koleksi teknik untuk dihafal. Ia satu urutan semakan yang setiap satunya menghasilkan bukti, iaitu nilai yang anda lihat dengan mata sendiri, arahan yang memulangkan jawapan jelas, atau baris log yang mengesahkan sesuatu lapisan benar-benar aktif. Tujuannya supaya aplikasi CFML diterbitkan dengan bukti, bukan dengan perasaan sudah selamat.

Kenapa urutan penting

Urutan semakan menentukan sama ada bukti yang anda kumpul boleh dipercayai. Rahsia mesti dikunci dahulu sebelum anda menyemak header dan TLS, kerana header yang betul di atas kod yang membocorkan kunci pangkalan data tidak membawa makna. Semakan input mesti datang sebelum semakan sesi, kerana input yang tidak disahkan boleh memintas pengesahan. Susun semakan mengikut lapisan, dari yang paling dalam keluar, supaya setiap langkah membina di atas langkah sebelumnya.

Urutan yang praktikal untuk aplikasi Lucee ialah enam langkah: rahsia dan konfigurasi, input dan SQL, sesi dan pengesahan, muat naik fail, header dan TLS, kemudian log dan pemantauan. Setiap langkah di bawah menyatakan apa yang perlu disemak dan bukti yang perlu dikumpul.

Semakan 1: Rahsia keluar dari kod

Langkah pertama ialah memastikan tiada kata laluan, kunci API atau rentetan sambungan pangkalan data tertulis terus dalam fail kod. Buktinya mudah: cari rentetan sambungan dan kunci dalam kod sumber, dan pastikan ia dibaca dari pemboleh ubah persekitaran atau fail konfigurasi di luar webroot.

# Bukti: tiada kata laluan atau kunci API dalam fail kod
grep -rniE 'password|apikey|secret|connectionString' /var/www --include='*.cfm' --include='*.cfc' | grep -viE 'env|getenv|systemsetting|expandPath'

Arahan di atas, tidak diuji pada pelayan ini, memaparkan baris yang mengandungi kata kunci rahsia dan menapis baris yang membaca dari pemboleh ubah persekitaran. Output kosong ialah bukti yang anda mahukan. Cara menyimpan dan membaca rahsia dengan betul dibincangkan dalam rahsia env dalam CFML.

Semakan 2: Input disahkan, SQL diparameter

Input ialah pintu masuk utama. Setiap nilai yang tiba dari skop form, url atau cookie mesti disahkan sebelum diproses dan dienkod sebelum dipaparkan. Untuk pangkalan data, setiap nilai mesti masuk melalui cfqueryparam, bukan cantuman rentetan.

<cfscript>
    // Sahkan dan enkod input sebelum ia diproses atau dipaparkan.
    emel = "ali@contoh.my";
    nama = "<script>alert(1)</script>";
    if (!isValid("email", emel)) {
        writeOutput("emel ditolak");
    } else {
        writeOutput("emel lulus<br>");
        writeOutput("nama selamat: " & encodeForHTML(nama));
    }
</cfscript>

Blok di atas menunjukkan corak dan diuji pada Lucee 7.1: nilai emel lulus pengesahan dan nilai nama yang mengandungi skrip dienkod menjadi <script> supaya ia dipaparkan sebagai teks, bukan dilaksanakan. Butiran penuh pengesahan input dan enkod output ada dalam panduan keselamatan XSS dan CSRF, manakala parameterisasi pertanyaan ada dalam cfquery dan cfqueryparam.

Bukti yang perlu dikumpul: senarai setiap medan form dan url yang dibaca dalam aplikasi, dan pengesahan bahawa tiada satu pun nilai itu sampai ke pertanyaan SQL tanpa parameter.

Semakan 3: Sesi dan pengesahan

Semak tiga perkara pada sesi: kuki dilindungi, tamat tempoh yang munasabah, dan pengesahan yang tidak boleh dipaksa dengan meneka. Kuki sesi mesti membawa atribut HttpOnly dan Secure, dan halaman log masuk mesti menghadkan percubaan.

<cfscript>
    // Baca tetapan keselamatan sebenar daripada enjin, bukan dari ingatan.
    meta = getApplicationMetadata();
    writeOutput("sesi aktif: " & meta.sessionmanagement & "<br>");
    writeOutput("kuki klien: " & meta.setClientCookies & "<br>");
    writeOutput("scriptProtect: " & meta.scriptProtect & "<br>");
    writeOutput("XML secure: " & meta.xmlFeatures.secure & "<br>");
    writeOutput("debug ditunjukkan: " & meta.monitoring.showDebug);
</cfscript>

Blok ini diuji dan memulangkan nilai sebenar daripada tetapan aplikasi, bukti yang boleh anda bandingkan dengan tetapan yang anda mahukan. Perhatikan bahawa debug ditunjukkan mesti bernilai false dalam produksi. Asas pengurusan sesi ada dalam pengurusan sesi session, dan menghadkan percubaan log masuk dibincangkan dalam had kadar brute force.

Semakan 4: Muat naik fail

Muat naik fail ialah laluan yang paling kerap dilupakan dalam semakan. Semak tiga perkara: jenis fail disahkan daripada kandungan dan bukan hanya sambungan nama; fail disimpan di luar webroot atau dalam direktori dengan sekatan pelaksanaan; dan tiada fail yang boleh dilaksanakan melalui pelayan. Buktinya ialah ujian muat naik fail dengan sambungan yang menyamar, contohnya fail skrip yang dinamakan sebagai imej, dan pengesahan bahawa ia ditolak. Prosedur lengkap ada dalam muat naik fail selamat.

Semakan 5: Header dan TLS

Header keselamatan mengawal kelakuan pelayar, dan TLS memastikan trafik disulitkan. Semak kedua-duanya dari luar aplikasi, bukan dari dalam, kerana itulah yang dilihat oleh pelawat.

# Bukti: header keselamatan dihidangkan pada halaman sebenar
curl -sI https://contoh.lucee.my/ | grep -iE 'x-frame-options|x-content-type-options|strict-transport-security|content-security-policy'

# Bukti: sijil TLS masih sah dan tarikh tamatnya
echo | openssl s_client -connect contoh.lucee.my:443 -servername contoh.lucee.my 2>/dev/null | openssl x509 -noout -dates

Kedua-dua arahan di atas tidak diuji pada pelayan ini kerana ia menunjuk kepada domain contoh. Apabila dijalankan pada domain sebenar, arahan pertama memulangkan header yang sepatutnya ada dan arahan kedua memulangkan tarikh sah sijil. Header yang tiada dalam output ialah bukti bahawa ia belum ditetapkan.

Semakan 6: Log dan pemantauan

Semakan terakhir ialah memastikan kegagalan boleh dikesan selepas terbit. Log aplikasi mesti dihidupkan dan ditulis ke lokasi yang tidak dihidangkan secara awam, dan mesej ralat kepada pengguna tidak boleh membocorkan laluan fail atau nama pangkalan data. Buktinya ialah satu ralat yang anda cetuskan dengan sengaja, kemudian sahkan ia muncul dalam log manakala halaman yang dipaparkan kepada pengguna tidak membawa butiran dalaman seperti laluan templat atau susunan panggilan. Log yang lengkap ialah perkara pertama yang anda perlukan apabila insiden berlaku, jadi jangan tangguhkan semakan ini sehingga selepas terbit.

Bukti yang perlu dikumpul

Ringkaskan bukti setiap langkah dalam satu dokumen supaya semakan boleh diulang oleh sesiapa sahaja, bukan hanya penulis asal. Setiap baris mesti mengandungi arahan atau nilai, bukan ayat pendapat.

Jadual senarai semak

Gunakan jadual ini sebagai senarai muktamad sebelum terbit. Tandakan setiap baris dengan bukti yang dikumpul, bukan dengan anggapan.

Kategori risiko

Tidak semua semakan sama berat. Jadual berikut mengelaskan risiko supaya anda tahu yang mana perlu dibaiki dahulu apabila sesuatu gagal.

Kategori kritikal mesti selesai sebelum terbit, kategori tinggi mesti selesai sejurus selepas itu, dan kategori sederhana serta rendah boleh dijadualkan tetapi dicatat supaya tidak dilupakan.

Soalan Lazim

Berapa kerap senarai semak ini perlu dijalankan?

Jalankan penuh sebelum setiap terbitan ke produksi, dan jalankan semakan rahsia serta header setiap kali konfigurasi berubah. Senarai semak ialah dokumen hidup yang dikemas kini apabila aplikasi bertambah.

Apakah bukti yang paling penting untuk disimpan?

Bukti yang paling penting ialah bukti yang boleh diulang, iaitu output arahan sebenar dan bukan ayat penerangan. Simpan output grep, curl dan nilai tetapan enjin supaya semakan seterusnya boleh membandingkan perubahan.

Adakah header keselamatan menggantikan pengesahan input?

Tidak. Header seperti Content-Security-Policy ialah lapisan tambahan. Pengesahan input, enkod output dan parameterisasi SQL ialah pertahanan utama yang tidak boleh digantikan.

Bagaimana saya tahu kuki sesi sudah dilindungi?

Semak header Set-Cookie pada respons log masuk. Ia mesti membawa atribut HttpOnly dan Secure. Jika atribut itu tiada, kuki boleh dibaca oleh skrip dan dihantar tanpa penyulitan.

Apa yang perlu dibuat dahulu apabila semakan gagal?

Baiki mengikut kategori risiko, bukan mengikut urutan senarai. Kegagalan kritikal seperti rahsia dalam kod atau SQL tanpa parameter mesti dibaiki serta-merta, walaupun ia muncul lewat dalam senarai semakan.