CAPTCHA ir – bet neko neaizsargā

Daudzi vietņu īpašnieki pievieno savai saziņas formai CAPTCHA, redz, kā parādās mazā nozīmīte vai izvēles rūtiņa, un uzskata surogātpasta problēmu par atrisinātu. Pēc tam atkritumi turpina pienākt. Bieži vien pati CAPTCHA ir kārtībā – tā vienkārši nav savienota ne ar ko, kas varētu apturēt robotu. Šajā rakstā aplūkoti tipiskie veidi, kā reCAPTCHA, hCaptcha un Cloudflare Turnstile kļūst par dekorāciju, un tas, kā pārbaudīt savas formas.

Kur aizsardzība patiesībā notiek

Visi trīs pakalpojumi darbojas pēc viena principa. Skripts pārlūkprogrammā veic savas pārbaudes un nodod formai marķieri – īsu virkni, kas saka „šis apmeklētājs pārbaudi izturēja”. Marķieris kopā ar formas iesniegumu nonāk jūsu serverī. Tikai tur tiek pieņemts īstais lēmums: jūsu serveris nosūta marķieri kopā ar slepeno atslēgu pakalpojuma sniedzējam un saņem atbildi – veiksme vai neveiksme, bet reCAPTCHA v3 gadījumā arī punktu vērtējums. Ja kāds šīs ķēdes posms trūkst, logrīks joprojām izskatās pilnīgi normāli, bet robots, kas sūta datus tieši jūsu formas apstrādātājam, tiek taisni cauri.

Testa atslēga, kas palaiž cauri visu

Google, hCaptcha un Cloudflare publicē īpašas testa atslēgas, lai izstrādātāji varētu veikt automatizētus testus, nerisinot mīklas. Ar atbilstošo testa noslēpumu pārbaude vienmēr izdodas – tas ir viss to mērķis. Tās paredzētas lokālām un testa vidēm, bet tās regulāri pārdzīvo pāreju uz produkciju: izstrādātājs tās ielīmē izstrādes laikā, vietne tiek palaista, un neviens tās neaizstāj. reCAPTCHA vismaz rāda logrīkā paziņojumu, ka tā paredzēta tikai testēšanai, bet ar neredzamu konfigurāciju gandrīz neviens tajā neieskatās. Ja gan testa vietnes atslēga, gan testa noslēpums ir aktīvi, katrs iesniegums tiek cauri neatkarīgi no tā, vai tas nāk no cilvēka vai robota; ja testa atslēga ir tikai vietnes atslēga, pārbaude tā vietā neizdodas, un īsti ziņojumi var tikt noraidīti.

Marķieris, ko neviens nepārbauda

Otrs klasiskais gadījums ir serveris, kas nekad nevaicā pakalpojuma sniedzējam. Logrīks darbojas, marķieris tiek izveidots un iesniegts, un tad formas apstrādātājs to vienkārši ignorē. Tipiski avoti ir ar roku rakstītas formas, nokopēti fragmenti, kas aptver tikai pārlūkprogrammas pusi, un pusgatavi spraudņu iestatījumi. Tuvs radinieks: serveris gan izsauc pārbaudes pakalpojumu, bet pārbauda tikai to, vai pieprasījums izdevās, nevis to, ko saka atbilde. Vai arī reCAPTCHA v3 punktu sliekšņa vērtība ir 0, kas pieņem jebkuru vērtējumu, ko pakalpojums var atgriezt. Daži apstrādātāji arī „atveras kļūmes gadījumā”: ja marķiera nav vai pārbaude neizdodas, tie ziņojumu tik un tā pieņem – un robots marķieri vienkārši neiekļauj.

Kad logrīks nekad īsti neielādējas

Citas konfigurācijas kļūdas tā vietā salauž pārlūkprogrammas pusi. Ja vietnes atslēga nav reģistrēta domēnam – tipiski pēc pārejas no testa vides uz produkciju, domēna maiņas vai jauna apakšdomēna –, pakalpojuma sniedzējs atsakās izsniegt marķierus un rāda kļūdu logrīkā vai pārlūkprogrammas konsolē. Pēc motīva maiņas vai spraudņa atjauninājuma logrīka iezīmējums lapā var palikt, kamēr skripts, kas to iedzīvina, ir pazudis. Tādu pašu efektu var radīt sīkdatņu piekrišanas rīks, ja tas bloķē CAPTCHA skriptu, līdz apmeklētājs piekrīt. Tas, kas notiek tālāk, ir atkarīgs no servera: ja tas pieprasa derīgu marķieri, īsti apmeklētāji vairs nevar sūtīt ziņojumus, un neviens nepamana zaudētos pieprasījumus; ja nepieprasa, roboti tiek brīvi cauri.

Vēl divus gadījumus ir viegli palaist garām. reCAPTCHA v3 gadījumā nozīmīte stūrī parāda tikai to, ka skripts kaut kur lapā ir ielādēts – iespējams, to ielādējis motīvs vai cits spraudnis –, kamēr integrācija pašā formu spraudnī ir izslēgta. Un kešatmiņas spraudņi var saglabāt lapu kopā ar HTML iegultu marķieri. CAPTCHA marķieri ir derīgi tikai dažas minūtes, un tos var pārbaudīt tikai vienu reizi, tāpēc kešatmiņā saglabāts marķieris īstiem apmeklētājiem neizdodas; vilinošais „labojums” – pārbaudes izslēgšana – klusi noņem aizsardzību.

Īsa pašpārbaude

1. 1Atveriet formas lapu privātā logā, atveriet pārlūkprogrammas izstrādātāja rīkus un konsolē meklējiet CAPTCHA skripta kļūdas.
2. 2Pārbaudiet, vai logrīks patiešām parādās – vienreiz pirms un vienreiz pēc sīkdatņu paziņojuma pieņemšanas – un vai formu nevar nosūtīt, kamēr tā nav.
3. 3Pakalpojuma sniedzēja administrēšanas konsolē pārbaudiet, vai vietnes atslēgai ir norādīts jūsu aktīvais domēns (ieskaitot variantus, piemēram, www) un vai atslēgas jūsu formu spraudnī vai kodā tam atbilst – nevis ir atslēgas no dokumentācijas vai testa vides.
4. 4Formu spraudņa iestatījumos pārliecinieties, ka CAPTCHA integrācija ir ieslēgta tieši šai formai; reCAPTCHA v3 gadījumā pārbaudiet, vai punktu slieksnis ir lielāks par 0.
5. 5Ja jums ir piekļuve kodam, atrodiet servera puses pārbaudi un pārliecinieties, ka tā noraida iesniegumu, ja atbilde ir negatīva vai marķiera nav.
6. 6Izslēdziet formas lapu no pilnas lapas kešošanas vai nodrošiniet, ka marķieris katru reizi tiek izveidots no jauna pārlūkprogrammā.
7. 7Nosūtiet īstu testa ziņojumu un pārbaudiet, vai tas pienāk; atkārtojiet pārbaudi pēc motīva, spraudņu vai piekrišanas rīka izmaiņām.

CAPTCHA ir viens slānis, nevis visa aizsardzība. Kopā ar honeypot lauku, laika pārbaudi un servera puses filtrēšanu konfigurācijas kļūda vienā vietā neatstāj formu plaši atvērtu. Ja vēlaties ātri uzzināt, kādā stāvoklī ir jūsu formas, ievadiet savu domēnu vietnē formexposed.com – atskaite parāda, vai jūsu CAPTCHA konfigurācijas no ārpuses redzamās daļas ir kārtībā.