Praktik terbaik untuk menggunakan CAPTCHA dan Challenge tindakan

Ikuti panduan di bagian ini untuk merencanakan dan mengimplementasikan AWS WAF CAPTCHA atau tantangan.

Rencanakan CAPTCHA Anda dan tantang implementasi

Tentukan di mana menempatkan teka-teki CAPTCHA atau tantangan diam berdasarkan penggunaan situs web Anda, sensitivitas data yang ingin Anda lindungi, dan jenis permintaan. Pilih permintaan di mana Anda akan menerapkan CAPTCHA sehingga Anda menyajikan teka-teki sesuai kebutuhan, tetapi hindari menyajikannya di tempat yang tidak berguna dan dapat menurunkan pengalaman pengguna. Gunakan Challenge tindakan untuk menjalankan tantangan diam yang berdampak lebih kecil pada pengguna akhir, tetapi tetap membantu memverifikasi bahwa permintaan tersebut berasal dari browser yang JavaScript diaktifkan.

Putuskan di mana menjalankan teka-teki CAPTCHA dan tantangan diam pada klien Anda

Identifikasi permintaan yang Anda tidak ingin terpengaruh oleh CAPTCHA, misalnya, permintaan untuk CSS atau gambar. Gunakan CAPTCHA hanya jika diperlukan. Misalnya, jika Anda berencana untuk memeriksa CAPTCHA saat login, dan pengguna selalu dibawa langsung dari login ke layar lain, memerlukan pemeriksaan CAPTCHA di layar kedua mungkin tidak diperlukan dan mungkin menurunkan pengalaman pengguna akhir Anda.

Konfigurasikan Challenge dan CAPTCHA gunakan sehingga AWS WAF hanya mengirimkan teka-teki CAPTCHA dan tantangan diam sebagai tanggapan atas permintaan. GET text/html Anda tidak dapat menjalankan teka-teki atau tantangan dalam menanggapi POST permintaan, permintaan preflight Cross-Origin Resource Sharing (CORS), atau jenis OPTIONS GET non-permintaan lainnya. Perilaku browser untuk jenis permintaan lain dapat bervariasi dan mungkin tidak dapat menangani pengantara dengan benar.

Ada kemungkinan bagi klien untuk menerima HTML tetapi masih tidak dapat menangani CAPTCHA atau menantang pengantara. Misalnya, widget pada halaman web dengan iFrame kecil mungkin menerima HTML tetapi tidak dapat menampilkan CAPTCHA atau memprosesnya. Hindari menempatkan tindakan aturan untuk jenis permintaan ini, sama seperti untuk permintaan yang tidak menerima HTML.

Gunakan CAPTCHA atau Challenge untuk memverifikasi akuisisi token sebelumnya

Anda dapat menggunakan tindakan aturan semata-mata untuk memverifikasi keberadaan token yang valid, di lokasi di mana pengguna yang sah harus selalu memilikinya. Dalam situasi ini, tidak masalah apakah permintaan dapat menangani pengantara.

Misalnya, jika Anda menerapkan aplikasi JavaScript klien CAPTCHA API, dan menjalankan teka-teki CAPTCHA pada klien segera sebelum Anda mengirim permintaan pertama ke titik akhir yang dilindungi, permintaan pertama Anda harus selalu menyertakan token yang valid untuk tantangan dan CAPTCHA. Untuk informasi tentang integrasi aplikasi JavaScript klien, lihatAWS WAF JavaScript integrasi.

Untuk situasi ini, di ACL web Anda, Anda dapat menambahkan aturan yang cocok dengan panggilan pertama ini dan mengonfigurasinya dengan tindakan CAPTCHA aturan Challenge atau. Ketika aturan cocok untuk pengguna akhir dan browser yang sah, tindakan akan menemukan token yang valid, dan karena itu tidak akan memblokir permintaan atau mengirim tantangan atau teka-teki CAPTCHA sebagai tanggapan. Untuk informasi selengkapnya tentang cara kerja tindakan aturan, lihatCAPTCHAdan perilaku Challenge tindakan.

Lindungi data non-HTML sensitif Anda dengan CAPTCHA dan Challenge

Anda dapat menggunakan CAPTCHA dan Challenge proteksi untuk data non-HTML yang sensitif, seperti API, dengan pendekatan berikut.

1. Identifikasi permintaan yang mengambil respons HTML dan yang dijalankan di dekat permintaan untuk data sensitif dan non-HTML Anda.

2. Tulis CAPTCHA atau Challenge aturan yang cocok dengan permintaan HTML dan yang cocok dengan permintaan untuk data sensitif Anda.

3. Sesuaikan pengaturan waktu Anda CAPTCHA dan Challenge kekebalan sehingga, untuk interaksi pengguna normal, token yang diperoleh klien dari permintaan HTML tersedia dan belum kedaluwarsa dalam permintaan mereka untuk data sensitif Anda. Untuk informasi penyetelan, lihatKedaluwarsa stempel waktu: waktu kekebalan token.

Ketika permintaan untuk data sensitif Anda cocok dengan Challenge aturan CAPTCHA atau, itu tidak akan diblokir jika klien masih memiliki token yang valid dari teka-teki atau tantangan sebelumnya. Jika token tidak tersedia atau stempel waktu kedaluwarsa, permintaan untuk mengakses data sensitif Anda akan gagal. Untuk informasi selengkapnya tentang cara kerja tindakan aturan, lihatCAPTCHAdan perilaku Challenge tindakan.

Gunakan CAPTCHA dan Challenge untuk menyesuaikan aturan yang ada

Tinjau aturan yang ada, untuk melihat apakah Anda ingin mengubah atau menambahkannya. Berikut ini adalah beberapa skenario umum yang perlu dipertimbangkan.

• Jika Anda memiliki aturan berbasis tarif yang memblokir lalu lintas, tetapi Anda menjaga batas tarif relatif tinggi untuk menghindari pemblokiran pengguna yang sah, pertimbangkan untuk menambahkan aturan berbasis tarif kedua setelah aturan pemblokiran. Berikan aturan kedua batas yang lebih rendah dari aturan pemblokiran dan tetapkan tindakan aturan ke CAPTCHA atauChallenge. Aturan pemblokiran masih akan memblokir permintaan yang datang pada tingkat yang terlalu tinggi, dan aturan baru akan memblokir sebagian besar lalu lintas otomatis pada tingkat yang lebih rendah. Untuk informasi tentang aturan berbasis tarif, lihat. Pernyataan aturan berbasis tarif

• Jika Anda memiliki grup aturan terkelola yang memblokir permintaan, Anda dapat mengalihkan perilaku untuk beberapa atau semua aturan dari Block ke CAPTCHA atauChallenge. Untuk melakukannya, dalam konfigurasi grup aturan terkelola, ganti setelan tindakan aturan. Untuk informasi tentang tindakan aturan utama, lihatTindakan aturan mengesampingkan.

Uji CAPTCHA Anda dan tantang implementasi sebelum Anda menerapkannya

Adapun semua fungsionalitas baru, ikuti panduan diMenguji dan menyetel perlindungan Anda AWS WAF.

Selama pengujian, tinjau persyaratan kedaluwarsa stempel waktu token Anda dan atur ACL web Anda dan konfigurasi waktu kekebalan tingkat aturan sehingga Anda mencapai keseimbangan yang baik antara mengontrol akses ke situs web Anda dan memberikan pengalaman yang baik bagi pelanggan Anda. Untuk informasi, lihat Kedaluwarsa stempel waktu: waktu kekebalan token.