CAPTCHA on olemassa – mutta ei suojaa mitään

Moni verkkosivuston omistaja lisää yhteydenottolomakkeeseensa CAPTCHAn, näkee pienen merkin tai valintaruudun ilmestyvän ja pitää roskapostiongelmaa ratkaistuna. Sitten roskaa tulee edelleen. Usein CAPTCHA itsessään on kunnossa – sitä ei vain ole kytketty mihinkään, mikä voisi pysäyttää botin. Tässä kirjoituksessa käydään läpi tyypilliset tavat, joilla reCAPTCHAsta, hCaptchasta ja Cloudflare Turnstilesta tulee pelkkää koristetta, ja miten voit tarkistaa omat lomakkeesi.

Missä suojaus todella tapahtuu

Kaikki kolme palvelua toimivat samalla periaatteella. Selaimessa toimiva skripti suorittaa tarkistuksensa ja antaa lomakkeelle tunnisteen – lyhyen merkkijonon, joka kertoo ”tämä kävijä läpäisi”. Tunniste kulkee lomakkeen lähetyksen mukana palvelimellesi. Vasta siellä tehdään varsinainen päätös: palvelimesi lähettää tunnisteen yhdessä salaisen avaimen kanssa palveluntarjoajalle ja saa vastauksen – onnistui tai epäonnistui, ja reCAPTCHA v3:ssa myös pistemäärän. Jos jokin ketjun lenkki puuttuu, widget näyttää edelleen täysin normaalilta, mutta botti, joka lähettää suoraan lomakkeesi käsittelijälle, pääsee suoraan läpi.

Testiavain, joka päästää kaiken läpi

Google, hCaptcha ja Cloudflare julkaisevat erityisiä testiavaimia, jotta kehittäjät voivat ajaa automaattisia testejä ratkaisematta tehtäviä. Vastaavalla testisalaisuudella tarkistus onnistuu aina – se on niiden koko tarkoitus. Ne on tarkoitettu paikallisiin ja testiympäristöihin, mutta ne säilyvät säännöllisesti siirryttäessä tuotantoon: kehittäjä liittää ne rakennusvaiheessa, sivusto julkaistaan, eikä kukaan vaihda niitä. reCAPTCHA sentään näyttää widgetissä ilmoituksen, että se on tarkoitettu vain testaukseen, mutta näkymättömässä toteutuksessa tuskin kukaan katsoo. Jos sekä testisivustoavain että testisalaisuus ovat käytössä, jokainen lähetys menee läpi, tuli se ihmiseltä tai botilta; jos vain sivustoavain on testiavain, tarkistus sen sijaan epäonnistuu ja oikeita viestejä voidaan hylätä.

Tunniste, jota kukaan ei tarkista

Toinen klassikko on palvelin, joka ei koskaan kysy palveluntarjoajalta. Widget toimii, tunniste luodaan ja lähetetään, ja sitten lomakkeen käsittelijä yksinkertaisesti jättää sen huomiotta. Tyypillisiä lähteitä ovat käsin kirjoitetut lomakkeet, kopioidut koodinpätkät, jotka kattavat vain selainpuolen, sekä puolivalmiit lisäosan asetukset. Läheinen sukulainen: palvelin kyllä kutsuu tarkistuspalvelua, mutta tarkistaa vain, että pyyntö meni läpi, ei sitä, mitä vastauksessa sanotaan. Tai reCAPTCHA v3:n pisteraja on asetettu arvoon 0, jolloin hyväksytään jokainen pistemäärä, jonka palvelu voi palauttaa. Jotkin käsittelijät myös ”epäonnistuvat avoimesti”: jos tunniste puuttuu tai tarkistus epäonnistuu, ne hyväksyvät viestin silti – ja botti vain jättää tunnisteen pois.

Kun widget ei koskaan oikeasti lataudu

Muut määritysvirheet rikkovat sen sijaan selainpuolen. Jos sivustoavainta ei ole rekisteröity verkkotunnukselle – tyypillistä siirryttäessä testiympäristöstä tuotantoon, verkkotunnuksen vaihtuessa tai uuden aliverkkotunnuksen myötä – palveluntarjoaja kieltäytyy myöntämästä tunnisteita ja näyttää virheen widgetissä tai selaimen konsolissa. Teeman vaihdon tai lisäosan päivityksen jälkeen widgetin merkintäkoodi voi yhä olla sivulla, vaikka sen henkiin herättävä skripti on poissa. Evästesuostumustyökalulla voi olla sama vaikutus, jos se estää CAPTCHA-skriptin, kunnes kävijä antaa suostumuksensa. Mitä seuraavaksi tapahtuu, riippuu palvelimesta: jos se vaatii kelvollisen tunnisteen, oikeat kävijät eivät voi enää lähettää viestejä eikä kukaan huomaa menetettyjä yhteydenottoja; jos ei vaadi, botit pääsevät vapaasti läpi.

Kaksi muuta tapausta jää helposti huomaamatta. reCAPTCHA v3:ssa kulmassa näkyvä merkki osoittaa vain, että skripti on ladattu jossakin sivulla – ehkä teeman tai jonkin muun lisäosan toimesta – vaikka itse lomakelisäosan integraatio on kytketty pois päältä. Lisäksi välimuistilisäosat voivat tallentaa sivun yhdessä HTML:ään upotetun tunnisteen kanssa. CAPTCHA-tunnisteet ovat voimassa vain muutaman minuutin ja ne voidaan tarkistaa vain kerran, joten välimuistiin tallennettu tunniste epäonnistuu oikeilla kävijöillä; houkutteleva ”korjaus” eli tarkistuksen kytkeminen pois päältä poistaa suojauksen huomaamatta.

Lyhyt itsetarkistus

1. 1Avaa lomakesivu yksityisessä ikkunassa, avaa selaimen kehittäjätyökalut ja etsi konsolista CAPTCHA-skriptin virheitä.
2. 2Tarkista, että widget todella näkyy – kerran ennen evästebannerin hyväksymistä ja kerran sen jälkeen – ja ettei lomaketta voi lähettää, kun widget puuttuu.
3. 3Tarkista palveluntarjoajan hallintakonsolista, että sivustoavaimessa on lueteltu julkaistu verkkotunnuksesi (myös muunnelmat kuten www) ja että lomakelisäosasi tai koodisi avaimet vastaavat sitä – eivätkä ole dokumentaatiosta tai testiympäristöstä peräisin olevia avaimia.
4. 4Varmista lomakelisäosan asetuksista, että CAPTCHA-integraatio on käytössä juuri tässä lomakkeessa; reCAPTCHA v3:ssa tarkista, että pisteraja on yli 0.
5. 5Jos sinulla on pääsy koodiin, etsi palvelinpuolen tarkistus ja varmista, että se hylkää lähetyksen, kun vastaus on kielteinen tai tunniste puuttuu.
6. 6Sulje lomakesivu pois koko sivun välimuistista tai varmista, että tunniste luodaan selaimessa aina uutena.
7. 7Lähetä oikea testiviesti ja tarkista, että se saapuu; toista tarkistus teemaan, lisäosiin tai suostumustyökaluun tehtyjen muutosten jälkeen.

CAPTCHA on yksi kerros, ei koko suojaus. Kun se yhdistetään honeypot-kenttään, aikatarkistukseen ja palvelinpuolen suodatukseen, yhden kohdan määritysvirhe ei jätä lomaketta täysin auki. Jos haluat nopean kuvan lomakkeidesi tilanteesta, syötä verkkotunnuksesi osoitteessa formexposed.com – raportti näyttää, ovatko CAPTCHA-toteutuksesi ulospäin näkyvät osat kunnossa.