CAPTCHA-en er der – men beskytter ingenting

Mange nettstedseiere legger en CAPTCHA til kontaktskjemaet sitt, ser det lille merket eller avkrysningsboksen og anser søppelpostproblemet som løst. Så fortsetter søppelet å komme. Ofte er selve CAPTCHA-en i orden – den er bare ikke koblet til noe som kan stoppe en bot. Dette innlegget går gjennom de typiske måtene reCAPTCHA, hCaptcha og Cloudflare Turnstile blir til pynt på, og hvordan du kontrollerer dine egne skjemaer.

Hvor beskyttelsen faktisk skjer

Alle tre tjenestene virker etter samme prinsipp. Et skript i nettleseren utfører kontrollene og gir skjemaet et token – en kort streng som sier «denne besøkende bestod». Tokenet følger skjemainnsendingen til serveren din. Først der tas den virkelige avgjørelsen: serveren sender tokenet sammen med en hemmelig nøkkel til leverandøren og får et svar – vellykket eller mislykket, og for reCAPTCHA v3 også en poengsum. Hvis et ledd i kjeden mangler, ser widgeten fortsatt helt normal ut, men en bot som sender direkte til skjemabehandleren din, går rett gjennom.

Testnøkkelen som vinker alt gjennom

Google, hCaptcha og Cloudflare publiserer egne testnøkler slik at utviklere kan kjøre automatiserte tester uten å løse gåter. Med den tilhørende testhemmeligheten lykkes verifiseringen alltid – det er hele formålet. De er ment for lokale miljøer og testmiljøer, men overlever jevnlig overgangen til produksjon: en utvikler limer dem inn under byggingen, nettstedet lanseres og ingen bytter dem ut. reCAPTCHA viser i det minste en merknad i widgeten om at den bare er til testing, men med et usynlig oppsett er det knapt noen som ser etter. Hvis både testnøkkelen og testhemmeligheten er i produksjon, slipper hver innsending gjennom, enten den kommer fra et menneske eller en bot; hvis bare nettstedsnøkkelen er en testnøkkel, mislykkes verifiseringen i stedet, og ekte meldinger kan avvises.

Et token ingen kontrollerer

Den andre klassikeren er en server som aldri spør leverandøren. Widgeten kjører, et token opprettes og sendes inn, og så ignorerer skjemabehandleren det ganske enkelt. Typiske årsaker er håndskrevne skjemaer, kopierte kodebiter som bare dekker nettlesersiden og halvferdige programtilleggsinnstillinger. En nær slektning: serveren anroper verifiseringstjenesten, men kontrollerer bare at forespørselen gikk gjennom, ikke hva svaret sier. Eller poengterskelen for reCAPTCHA v3 settes til 0, som godtar enhver poengsum tjenesten kan returnere. Noen behandlere «feiler åpent»: hvis tokenet mangler eller verifiseringen mislykkes, godtar de meldingen likevel – og en bot utelater bare tokenet.

Når widgeten aldri egentlig lastes

Andre feilkonfigurasjoner ødelegger nettlesersiden i stedet. Hvis nettstedsnøkkelen ikke er registrert for domenet – typisk etter flytting fra testmiljø til produksjon, domenebytte eller et nytt underdomene – nekter leverandøren å utstede tokener og viser en feil i widgeten eller nettleserkonsollen. Etter temabytte eller oppdatering av programtillegg kan widget-koden fortsatt stå på siden mens skriptet som gir den liv, er borte. Et samtykkeverktøy for informasjonskapsler kan ha samme virkning hvis det blokkerer CAPTCHA-skriptet til den besøkende samtykker. Hva som skjer videre, avhenger av serveren: hvis den krever et gyldig token, kan ekte besøkende ikke lenger sende meldinger, og ingen merker de tapte henvendelsene; hvis den ikke gjør det, slipper boter fritt gjennom.

To andre tilfeller er lette å overse. Med reCAPTCHA v3 viser merket i hjørnet bare at skriptet er lastet et sted på siden – kanskje av temaet eller et annet programtillegg – mens integrasjonen i selve skjemaprogramtillegget er slått av. Og mellomlagringsprogramtillegg kan lagre en side sammen med et token innebygd i HTML-en. CAPTCHA-tokener er bare gyldige i noen minutter og kan bare verifiseres én gang, så et mellomlagret token feiler for ekte besøkende; den fristende «rettingen» å slå av kontrollen fjerner stille beskyttelsen.

En kort egenkontroll

1. 1Åpne skjemasiden i et privat vindu, åpne nettleserens utviklerverktøy og se etter feil fra CAPTCHA-skriptet i konsollen.
2. 2Kontroller at widgeten faktisk vises – én gang før og én gang etter at informasjonskapselbanneret er godtatt – og at skjemaet ikke kan sendes mens den mangler.
3. 3Kontroller i leverandørens administrasjonskonsoll at nettstedsnøkkelen oppgir produksjonsdomenet ditt (inkludert varianter som www), og at nøklene i skjemaprogramtillegget eller koden samsvarer – ikke nøkler fra dokumentasjon eller et testoppsett.
4. 4Kontroller i skjemaprogramtilleggets innstillinger at CAPTCHA-integrasjonen er aktivert for akkurat dette skjemaet; for reCAPTCHA v3, kontroller at poengterskelen er over 0.
5. 5Hvis du har tilgang til koden, finn verifiseringen på serveren og kontroller at den avviser innsendingen når svaret er negativt eller tokenet mangler.
6. 6Unnta skjemasiden fra fullsidemellomlagring, eller sørg for at tokenet opprettes på nytt i nettleseren.
7. 7Send en ekte testmelding og kontroller at den kommer frem; gjenta kontrollen etter endringer i tema, programtillegg eller samtykkeverktøy.

En CAPTCHA er ett lag, ikke hele beskyttelsen. Kombinert med et fellefelt, en tidskontroll og filtrering på serveren gjør ikke en feilkonfigurasjon ett sted skjemaet helt åpent. Hvis du vil ha et raskt bilde av hvordan skjemaene dine ligger an, skriv inn domenet ditt på formexposed.com – rapporten viser om delene av CAPTCHA-oppsettet som er synlige utenfra, er i orden.