A CAPTCHA ott van – de semmit sem véd

Sok weboldaltulajdonos CAPTCHA-t tesz a kapcsolatfelvételi űrlapjára, látja megjelenni a kis jelvényt vagy jelölőnégyzetet, és megoldottnak tekinti a spamproblémát. Aztán a szemét tovább érkezik. Gyakran maga a CAPTCHA rendben van – csak nincs összekötve semmivel, ami megállíthatna egy botot. Ez a bejegyzés végigveszi, milyen tipikus módokon válik a reCAPTCHA, a hCaptcha és a Cloudflare Turnstile puszta dekorációvá, és hogyan ellenőrizheti saját űrlapjait.

Hol történik valójában a védelem

Mindhárom szolgáltatás ugyanazon az elven működik. Egy szkript a böngészőben lefuttatja az ellenőrzéseit, és egy tokent ad át az űrlapnak – egy rövid karakterláncot, amely azt mondja: „ez a látogató megfelelt”. A token az űrlapbeküldéssel együtt jut el a szerveréhez. Csak ott születik meg a valódi döntés: a szervere a tokent egy titkos kulccsal együtt elküldi a szolgáltatónak, és választ kap – sikeres vagy sikertelen, reCAPTCHA v3 esetén pontszámmal is. Ha ennek a láncnak bármelyik szeme hiányzik, a widget továbbra is teljesen normálisan néz ki, de egy bot, amely közvetlenül az űrlapkezelőnek küld, akadálytalanul átjut.

A tesztkulcs, amely mindent átenged

A Google, a hCaptcha és a Cloudflare különleges tesztkulcsokat tesz közzé, hogy a fejlesztők feladványok megoldása nélkül futtathassanak automatizált teszteket. A hozzájuk tartozó tesztkulccsal az ellenőrzés mindig sikeres – éppen ez a céljuk. Helyi és staging környezetekhez szánták őket, de rendszeresen túlélik az átköltözést az éles környezetbe: egy fejlesztő a fejlesztés során beilleszti őket, az oldal élesbe megy, és senki sem cseréli le őket. A reCAPTCHA legalább jelez a widgetben, hogy csak tesztelésre szolgál, de láthatatlan beállításnál alig néz oda valaki. Ha a teszt-webhelykulcs és a teszt titkos kulcs is élesben van, minden beküldés átmegy, akár embertől, akár bottól származik; ha csak a webhelykulcs tesztkulcs, az ellenőrzés épp ellenkezőleg meghiúsul, és a valódi üzeneteket is elutasíthatják.

Egy token, amelyet senki sem ellenőriz

A második klasszikus eset az a szerver, amely soha nem kérdezi meg a szolgáltatót. A widget fut, a token létrejön és beküldésre kerül, majd az űrlapkezelő egyszerűen figyelmen kívül hagyja. Tipikus forrásai a kézzel írt űrlapok, a csak a böngészőoldalt lefedő, másolt kódrészletek és a félkész bővítménybeállítások. Közeli rokona: a szerver ugyan meghívja az ellenőrző szolgáltatást, de csak azt nézi, hogy a kérés lefutott-e, azt nem, hogy mit mond a válasz. Vagy a reCAPTCHA v3 pontszámküszöbe 0-ra van állítva, ami minden pontszámot elfogad, amelyet a szolgáltatás visszaadhat. Egyes kezelők „nyitva hibáznak” is: ha a token hiányzik vagy az ellenőrzés meghiúsul, mégis elfogadják az üzenetet – egy bot pedig egyszerűen kihagyja a tokent.

Amikor a widget valójában soha nem töltődik be

Más hibás beállítások ehelyett a böngészőoldalt rontják el. Ha a webhelykulcs nincs regisztrálva a domainhez – ami tipikus a stagingről élesbe költözés, domainváltás vagy új aldomain után –, a szolgáltató megtagadja a tokenek kiadását, és hibát jelez a widgetben vagy a böngészőkonzolban. Témaváltás vagy bővítményfrissítés után a widgetjelölés még az oldalon lehet, miközben az életre keltő szkript eltűnt. Egy sütihozzájárulás-kezelő eszköz ugyanilyen hatással járhat, ha addig blokkolja a CAPTCHA-szkriptet, amíg a látogató bele nem egyezik. Hogy mi történik ezután, az a szervertől függ: ha ragaszkodik az érvényes tokenhez, a valódi látogatók már nem tudnak üzenetet küldeni, és senki sem veszi észre az elveszett megkereséseket; ha nem, a botok szabadon átjutnak.

Két további eset könnyen elkerüli a figyelmet. reCAPTCHA v3 esetén a sarokban lévő jelvény csak azt mutatja, hogy a szkript valahol az oldalon be van töltve – talán a téma vagy egy másik bővítmény által –, miközben magában az űrlapbővítményben ki van kapcsolva az integráció. A gyorsítótárazó bővítmények pedig egy oldalt a HTML-be ágyazott tokennel együtt tárolhatnak. A CAPTCHA-tokenek csak néhány percig érvényesek, és csak egyszer ellenőrizhetők, így egy gyorsítótárazott token a valódi látogatóknál hibát ad; az ellenőrzés kikapcsolásának csábító „javítása” pedig csendben megszünteti a védelmet.

Rövid önellenőrzés

1. 1Nyissa meg az űrlap oldalát privát ablakban, nyissa meg a böngésző fejlesztői eszközeit, és keressen a konzolban a CAPTCHA-szkripttől származó hibákat.
2. 2Ellenőrizze, hogy a widget valóban megjelenik-e – egyszer a sütibanner elfogadása előtt, egyszer utána –, és hogy az űrlap nem küldhető-e el, amíg hiányzik.
3. 3A szolgáltató adminisztrációs konzoljában ellenőrizze, hogy a webhelykulcsnál szerepel-e az éles domainje (a változatokkal együtt, például www), és hogy az űrlapbővítményben vagy a kódban lévő kulcsok ezzel egyeznek-e – nem a dokumentációból vagy egy staging környezetből származó kulcsok.
4. 4Az űrlapbővítmény beállításaiban győződjön meg arról, hogy a CAPTCHA-integráció engedélyezve van erre a konkrét űrlapra; reCAPTCHA v3 esetén ellenőrizze, hogy a pontszámküszöb 0 fölött van-e.
5. 5Ha hozzáfér a kódhoz, keresse meg a szerveroldali ellenőrzést, és győződjön meg arról, hogy elutasítja a beküldést, ha a válasz negatív vagy a token hiányzik.
6. 6Zárja ki az űrlap oldalát a teljes oldalas gyorsítótárazásból, vagy gondoskodjon arról, hogy a token mindig frissen jöjjön létre a böngészőben.
7. 7Küldjön egy valódi tesztüzenetet, és ellenőrizze, hogy megérkezik-e; ismételje meg az ellenőrzést a téma, a bővítmények vagy a hozzájáruláskezelő eszköz módosításai után.

A CAPTCHA egy réteg, nem a teljes védelem. Honeypot mezővel, időellenőrzéssel és szerveroldali szűréssel kombinálva egy helyen elkövetett beállítási hiba nem hagyja tárva-nyitva az űrlapot. Ha gyors képet szeretne kapni arról, hol tartanak az űrlapjai, adja meg a domainjét a formexposed.com oldalon – a jelentés megmutatja, hogy a CAPTCHA-beállítás kívülről látható részei rendben vannak-e.