Melindungi Borang Log Masuk daripada Cubaan Berulang

Melindungi Borang Log Masuk daripada Cubaan Berulang

Serangan brute force berlaku apabila penyerang mencuba banyak gabungan nama pengguna dan kata laluan secara automatik sehingga satu daripadanya betul. Pertahanan yang berkesan bukan satu tembok besar, tetapi beberapa lapisan yang saling melengkapi: kunci berperingkat, had kadar per IP, kelewatan yang bertambah, dan pemantauan di pelayan hadapan. Artikel ini menerangkan setiap lapisan dan kelemahannya supaya anda boleh memilih gabungan yang sesuai untuk aplikasi CFML anda.

Kenapa Kunci Akaun Per Akaun Itu Merugikan

Idea menutup akaun selepas lima percubaan gagal kelihatan logik, tetapi ia membuka satu kelemahan besar: penyerang boleh mengunci akaun pemilik sebenar dengan sengaja menghantar kata laluan yang salah. Ini dipanggil penafian perkhidmatan, dan ia membolehkan sesiapa sahaja yang tahu alamat e-mel anda menutup akses anda tanpa mengetahui kata laluan anda. Cheat Sheet Pengesahan OWASP menegaskan bahawa dasar kunci akaun mesti mencari keseimbangan antara keselamatan dan kebolehgunaan. Penyelesaiannya ialah kunci berperingkat: tempoh kunci bermula sangat singkat, contohnya beberapa saat, dan bertambah perlahan dengan setiap percubaan gagal berturut-turut. Ini menggagalkan automasi tanpa mengunci pengguna sah secara kekal.

Had Per IP dan Kelemahannya

Had kadar per IP mengehadkan bilangan percubaan dari satu alamat dalam satu tempoh. Ia berkesan terhadap skrip mudah, tetapi ada dua kelemahan. Pertama, penyerang boleh bertukar IP melalui rangkaian bot atau proksi, jadi had per IP sahaja tidak menghentikan penyerang yang bermotivasi. Kedua, IP yang dikongsi, contohnya rangkaian pejabat atau NAT, boleh menyebabkan ramai pengguna sah turut disekat apabila salah seorang daripadanya tersalah taip kata laluan berkali-kali. Oleh sebab itu, had per IP ialah lapisan tambahan, bukan pertahanan tunggal, dan ia paling baik digabungkan dengan had per akaun.

Melambatkan Secara Berperingkat

Satu teknik yang mudah dan berkesan ialah membuat setiap percubaan gagal menjadi semakin lambat. Daripada memulangkan ralat serta-merta, aplikasi menunggu sedikit sebelum menjawab, dan tempoh menunggu itu bertambah dengan setiap kegagalan. Ini memaksa penyerang menghabiskan masa yang panjang untuk setiap tekaan, menjadikan serangan tidak berbaloi dari segi ekonomi, tanpa menyekat pengguna sah secara kekal. Lucee menyediakan fungsi Sleep() yang menerima tempoh dalam milisaat:

// Dalam Application.cfc, mulakan pembilang pada permulaan aplikasi
function onApplicationStart() {
    application.loginFailures = {}; // kunci = alamat IP atau nama pengguna
}

// Semasa memproses log masuk yang gagal
var attempt = structKeyExists(application.loginFailures, key)
    ? application.loginFailures[key] + 1 : 1;
application.loginFailures[key] = attempt;

// Kelewatan bertambah: 1 saat, 2 saat, 4 saat, dan seterusnya
sleep(min(1000 * (2 ^ (attempt - 1)), 16000));

// Reset pembilang selepas log masuk berjaya
structDelete(application.loginFailures, key);

Had atas seperti 16 saat dalam contoh menghalang kelewatan menjadi tidak munasabah untuk pengguna sah yang tersilap. Gunakan application untuk pembilang kerana ia dikongsi merentas permintaan dan tidak terikat kepada satu sesi, tetapi ingat ia hidup dalam memori dan hilang apabila pelayan dimulakan semula. Untuk jejak audit yang kekal, catatkan peristiwa ini ke fail log.

Had Kadar dengan Tetingkap Masa

Selain kelewatan, had kadar yang sebenar menetapkan bilangan percubaan maksimum dalam satu tetingkap masa. Contohnya, benarkan sepuluh percubaan bagi setiap IP dalam tempoh lima minit dan tolak selebihnya. Pembilang disimpan dalam skop application bersama cap masa tetingkap, dan ditetapkan semula apabila tetingkap tamat:

// Fungsi semakan had kadar untuk satu kunci (IP atau nama pengguna)
function terlaluKerap(required string key, numeric had = 10, numeric tetingkap = 300) {
    if (!structKeyExists(application.loginFailures, key)) {
        application.loginFailures[key] = { count = 0, start = now() };
    }
    var rec = application.loginFailures[key];
    // Tetapkan semula tetingkap jika sudah tamat
    if (dateDiff("s", rec.start, now()) > tetingkap) {
        rec.count = 0;
        rec.start = now();
    }
    rec.count += 1;
    return rec.count > had;
}

Dengan had kadar dan kelewatan berperingkat digabungkan, penyerang menghadapi dua kekangan sekaligus: jumlah percubaan terhad dalam satu tempoh, dan setiap percubaan tambahan menjadi semakin lambat. Ini menjadikan serangan automatik hampir mustahil tanpa menarik perhatian sistem pemantauan anda.

Mencatat dan Memantau Percubaan Gagal

Tanpa log, anda tidak akan tahu serangan sedang berlaku sehingga terlalu lewat. Catat setiap percubaan gagal dengan maklumat minima yang mencukupi untuk siasatan: masa, nama pengguna, alamat IP dan sebab kegagalan. Jangan catat kata laluan, kerana log yang bocor akan memburukkan keadaan. Lucee menyediakan tag cflog untuk menulis ke fail log pelayan:

<cflog
    file="auth"
    type="warning"
    text="Percubaan log masuk gagal untuk pengguna #encodeForHTML(form.username)# dari #cgi.remote_addr#">

Seterusnya, pantau log ini secara aktif. Lonjakan percubaan gagal dari satu IP atau satu akaun ialah isyarat awal serangan, dan amaran automatik membolehkan anda bertindak sebelum penyerang menemui kejayaan. Maklumat lanjut tentang menyediakan log dan pemantauan ada dalam panduan log dan pemantauan CFML.

Memberi Amaran kepada Pemilik Akaun

Apabila anda mengesan corak percubaan gagal yang mencurigakan untuk satu akaun, beritahu pemiliknya. E-mel ringkas yang menyatakan terdapat percubaan log masuk yang tidak dikenali, tanpa mendedahkan butiran sensitif, memberi pengguna peluang menukar kata laluan atau mengaktifkan pengesahan dua faktor. Langkah ini menjadikan keselamatan sebagai tanggungjawab bersama dan membantu mengesan pancingan data lebih awal. Ia juga merupakan amalan yang disyorkan dalam pencegahan credential stuffing, di mana penyerang mencuba gabungan kata laluan yang bocor daripada perkhidmatan lain.

Perlindungan di Lapisan Pelayan Hadapan

Lapisan aplikasi bukan tempat terbaik untuk menyerap serangan berskala besar, kerana setiap permintaan sudah sampai ke enjin CFML sebelum ditolak. Lebih baik hentikan serangan di pelayan hadapan sebelum ia membebankan aplikasi. Dua alat yang lazim ialah fail2ban, yang membaca log dan menyekat IP yang berkelakuan buruk di peringkat tembok api, dan modul had kadar nginx seperti limit_req, yang mengehadkan bilangan permintaan sesaat dari satu IP. Kedua-duanya beroperasi sebelum permintaan sampai ke Lucee, jadi aplikasi anda tidak membazir sumber untuk permintaan yang akan ditolak. Butiran menyediakan nginx di hadapan Lucee ada dalam panduan nginx di hadapan Lucee.

Jadual Perbandingan Strategi

Jadual berikut merumuskan setiap strategi, kekuatannya dan kelemahannya:

Tiada satu baris pun cukup dengan sendirinya. Gabungan kunci berperingkat untuk akaun, kelewatan berperingkat untuk memperlahankan serangan, dan fail2ban atau had nginx untuk menapis di hadapan memberikan pertahanan berlapis yang jauh lebih sukar ditembusi.

Menyusun Lapisan Pertahanan

Urutan pelaksanaan yang praktikal ialah: mulakan dengan kunci berperingkat dan kelewatan berperingkat dalam kod CFML anda, tambah cflog untuk jejak audit, kemudian lengkapkan dengan fail2ban atau had nginx di pelayan hadapan. Setiap lapisan boleh diuji secara berasingan, dan anda boleh memantau kesannya melalui log. Lengkapkan semua ini dengan asas pengesahan yang kukuh seperti hash kata laluan dan 2FA yang diterangkan dalam panduan pengesahan pengguna CFML, dan pastikan borang anda tidak membuka laluan lain seperti suntikan skrip yang dibincangkan dalam panduan keselamatan aplikasi web CFML.

Soalan Lazim (FAQ)

Apakah kelemahan utama kunci akaun kekal?

Penyerang boleh mengunci akaun pemilik sebenar dengan sengaja menghantar kata laluan yang salah, iaitu satu bentuk penafian perkhidmatan. Kunci berperingkat dengan tempoh yang bertambah ialah alternatif yang lebih selamat.

Adakah had per IP mencukupi untuk menghentikan brute force?

Tidak. Penyerang boleh bertukar IP melalui bot atau proksi, dan IP kongsi seperti NAT boleh menyebabkan pengguna sah turut disekat. Ia perlu digabungkan dengan had per akaun.

Bagaimana kelewatan berperingkat membantu?

Ia menjadikan setiap percubaan gagal semakin lambat, contohnya menggandakan tempoh menunggu setiap kali. Penyerang perlu menghabiskan masa yang sangat lama untuk setiap tekaan, menjadikan serangan tidak berbaloi.

Apakah yang perlu saya catat dalam log percubaan gagal?

Catat masa, nama pengguna, alamat IP dan sebab kegagalan. Jangan catat kata laluan, kerana log yang bocor akan memburukkan lagi keadaan.

Di mana tempat terbaik untuk menyekat serangan berskala besar?

Di pelayan hadapan, menggunakan fail2ban atau modul had kadar nginx seperti limit_req, supaya permintaan berbahaya ditolak sebelum sampai ke enjin CFML.

Sumber

• Authentication Cheat Sheet - OWASP
• Credential Stuffing Prevention Cheat Sheet - OWASP
• Blocking Brute Force Attacks - OWASP
• Sleep() - Lucee Documentation
• cflog - Lucee Documentation
• Module ngx_http_limit_req_module - nginx