Scarnox · Blog

Cara kerja reCAPTCHA v2 dan cara memecahkannya (segera hadir)

reCAPTCHA v2 adalah captcha klasik Google. Ia menampilkan kotak centang berlabel "I'm not a robot" dan, ketika ia tidak yakin tentang pengunjung, menambahkan tantangan gambar. Solver untuknya harus menghasilkan token respons yang valid, yang bisa diverifikasi situs bersama Google. Dukungan Scarnox untuk reCAPTCHA v2 segera hadir. Panduan ini menjelaskan cara kerja widget, pendekatan umum yang digunakan orang saat ini, dan apa yang bisa diharapkan dari solver berbasis token.

Scarnox belum memecahkan reCAPTCHA v2 secara langsung. Satu-satunya jenis tugas yang aktif saat ini adalah PopularCaptcha, proxyless. Jika proyek Anda membutuhkan reCAPTCHA v2 sekarang, pendekatan di bawah ini adalah opsi yang realistis.

Cara kerja widget

Halaman menyematkan elemen kontainer dengan atribut data-sitekey. Sitekey itu mengidentifikasi situs bagi Google. Ketika widget dimuat, ia menjalankan pemeriksaan di browser, dengan melihat perilaku pengunjung, cookie, dan riwayat, lalu mengirimkan penilaian risiko ke Google.

Jika penilaiannya berisiko rendah, kotak centang akan tercentang sendiri dan widget menuliskan token ke field tersembunyi bernama g-recaptcha-response. Jika penilaiannya berisiko lebih tinggi, pengunjung melihat tantangan gambar, misalnya memilih ubin yang berisi objek tertentu. Lulus dari tantangan juga menuliskan token.

Backend situs kemudian mengirimkan token itu ke endpoint verifikasi Google, bersama secret key situs. Google merespons dengan sukses atau gagal. Karena verifikasi dilakukan di server, form yang menerima token tanpa memeriksanya ke Google sebenarnya tidak dilindungi oleh reCAPTCHA sama sekali.

Mengapa ia ditandai

Kotak centang adalah keputusan risiko, bukan teka-teki. Pemicu yang umum adalah:

Memahami pemicu ini lebih penting daripada widget itu sendiri. Jika lalu lintas Anda tidak memicu kotak centang, Anda tidak akan pernah melihat tantangan gambar.

Pendekatan umum yang berfungsi saat ini

Pendekatan ini banyak digunakan, dan ini adalah pendekatan yang jujur. Pendekatan ini mengurangi seberapa sering tantangan muncul pada pekerjaan yang sah.

  1. Pertahankan sesi nyata. Gunakan kembali cookie dan profil browser yang konsisten selama satu sesi, daripada memulai dari awal di setiap halaman.
  2. Atur laju request. Laju yang stabil dan lambat jauh lebih mirip manusia daripada lonjakan.
  3. Gunakan browser sungguhan untuk widget. Browser lengkap dengan pengaturan normal lebih jarang ditandai daripada setup headless yang disederhanakan. Panduan deteksi browser headless mencantumkan sinyal yang umum.
  4. Minta pengecualian atau kunci uji. Jika Anda memiliki situsnya, gunakan kunci uji yang dipublikasikan Google di staging. Jika tidak, mintalah allowlist kepada pemilik situs.
  5. Libatkan manusia. Untuk tugas bervolume rendah, seseorang bisa menyelesaikan kotak centang dan meneruskan token. Ini lambat tetapi andal.

Pendekatan ini tidak menjamin tantangan tidak akan pernah muncul. Pendekatan ini hanya mengurangi frekuensinya, dan itulah yang membuat pekerjaan yang sah tetap stabil.

Apa yang akan dilakukan solver berbasis token

Solver berbasis token untuk reCAPTCHA v2 melakukan hal yang sama dengan yang dilakukan PopularCaptcha saat ini. Ia menerima sitekey dan URL halaman, menghasilkan token g-recaptcha-response yang valid, dan mengembalikannya ke kode Anda. Kode Anda kemudian menuliskan token ke dalam form dan mengirimkannya sebelum token kedaluwarsa.

Scarnox akan mendokumentasikan jenis tugas dan field tambahan apa pun di referensi API ketika dukungan reCAPTCHA v2 dirilis. Sampai saat itu, jangan membangun di atas antarmuka yang hanya diasumsikan. Bentuk request-nya akan mirip dengan contoh PopularCaptcha, tetapi periksa dokumentasi untuk nilai yang tepat.

Daftar periksa untuk pekerjaan reCAPTCHA v2

Ketika Anda merencanakan pekerjaan yang menyentuh form reCAPTCHA v2, periksa poin-poin ini:

Kesalahan umum

Masalah paling sering dalam integrasi reCAPTCHA v2 adalah token yang ditolak situs padahal tampak benar. Tiga penyebab menyumbang sebagian besar kasus ini. Pertama, ketidakcocokan antara sitekey dan URL halaman: token terikat pada halaman tempat widget ditampilkan, jadi sitekey yang diambil dari satu halaman lalu dikirim ke halaman lain akan gagal. Kedua, token yang sudah usang. Token berumur pendek, jadi skrip yang memecahkan lebih dulu lalu menjalankan urutan langkah lain yang lambat akan mengirim nilai yang sudah kedaluwarsa. Ketiga, tidak ada pemeriksaan sisi server di pihak Anda. Jika pengujian Anda hanya memastikan token ada, Anda tidak akan menyadari bahwa langkah verifikasi gagal.

Kelompok kesalahan kedua berasal dari alur kerja di sekitar widget. Login pada satu sesi lalu mengirim form dari sesi lain adalah salah satu yang umum, karena verifikasi mungkin bergantung pada sesi yang memuat widget. Mencoba ulang form yang ditolak berkali-kali secara beruntun juga membuat sesi terlihat mencurigakan, yang bisa mengubah satu tantangan menjadi serangkaian tantangan. Ketika ada yang gagal, berhenti sejenak, periksa kondisi halaman, lalu coba sekali lagi dengan nilai yang baru.

Scraping secara bertanggung jawab

Jika form adalah bagian dari pekerjaan scraping, periksa robots.txt dan ketentuan situs sebelum Anda mulai. Jaga laju tetap rendah, dan jangan mengumpulkan data pribadi yang tidak Anda butuhkan. Panduan apakah web scraping legal membahas pertimbangan utamanya.

Langkah selanjutnya