CAPTCHA е налице – но не защитава нищо

Много собственици на уебсайтове добавят CAPTCHA към формуляра си за контакт, виждат появата на малката значка или квадратче за отметка и смятат проблема със спама за решен. След това боклуците продължават да пристигат. Често самата CAPTCHA е наред – тя просто не е свързана с нищо, което би могло да спре бот. Тази статия разглежда типичните начини, по които reCAPTCHA, hCaptcha и Cloudflare Turnstile се превръщат в украса, и как да проверите собствените си формуляри.

Къде всъщност се осъществява защитата

И трите услуги работят на един и същ принцип. Скрипт в браузъра извършва проверките си и предава на формуляра токен – кратък низ, който казва „този посетител премина“. Токенът пътува заедно с изпращането на формуляра до вашия сървър. Едва там се взема истинското решение: сървърът ви изпраща токена заедно с таен ключ до доставчика и получава отговор – успех или неуспех, а при reCAPTCHA v3 и оценка. Ако липсва някое звено от тази верига, уиджетът все още изглежда напълно нормално, но бот, който изпраща директно към обработчика на формуляра ви, преминава безпрепятствено.

Тестовият ключ, който пропуска всичко

Google, hCaptcha и Cloudflare публикуват специални тестови ключове, за да могат разработчиците да изпълняват автоматизирани тестове, без да решават пъзели. Със съответния тестов таен ключ проверката винаги е успешна – в това е целият им смисъл. Те са предназначени за локални и тестови среди, но редовно оцеляват при преминаването към продукционна среда: разработчикът ги поставя по време на изграждането, сайтът стартира и никой не ги сменя. reCAPTCHA поне показва в уиджета съобщение, че е само за тестване, но при невидима настройка почти никой не поглежда. Ако и тестовият ключ на сайта, и тестовият таен ключ са активни, всяко изпращане преминава, независимо дали идва от човек или от бот; ако само ключът на сайта е тестов, проверката вместо това е неуспешна и истинските съобщения може да бъдат отхвърлени.

Токен, който никой не проверява

Втората класика е сървър, който никога не пита доставчика. Уиджетът работи, токенът се създава и изпраща, а след това обработчикът на формуляра просто го игнорира. Типични източници са ръчно написани формуляри, копирани фрагменти, които покриват само страната на браузъра, и недовършени настройки на плъгини. Близък роднина: сървърът извиква услугата за проверка, но проверява само дали заявката е преминала, а не какво казва отговорът. Или прагът на оценката за reCAPTCHA v3 е зададен на 0, което приема всяка оценка, която услугата може да върне. Някои обработчици също „отказват отворено“: ако токенът липсва или проверката е неуспешна, те все пак приемат съобщението – а ботът просто пропуска токена.

Когато уиджетът никога не се зарежда истински

Други грешни настройки вместо това развалят страната на браузъра. Ако ключът на сайта не е регистриран за домейна – типично след преместване от тестова в продукционна среда, смяна на домейна или нов поддомейн – доставчикът отказва да издава токени и показва грешка в уиджета или в конзолата на браузъра. След смяна на темата или актуализация на плъгин маркирането на уиджета може все още да е в страницата, докато скриптът, който го задейства, вече липсва. Инструмент за съгласие за бисквитки може да има същия ефект, ако блокира скрипта на CAPTCHA, докато посетителят не даде съгласие. Какво се случва след това, зависи от сървъра: ако той настоява за валиден токен, истинските посетители вече не могат да изпращат съобщения и никой не забелязва изгубените запитвания; ако не настоява, ботовете преминават свободно.

Още два случая лесно се пропускат. При reCAPTCHA v3 значката в ъгъла показва само, че скриптът е зареден някъде на страницата – може би от темата или от друг плъгин – докато интеграцията в самия плъгин за формуляри е изключена. А плъгините за кеширане могат да съхранят страница заедно с вграден в HTML токен. CAPTCHA токените са валидни само няколко минути и могат да бъдат проверени само веднъж, така че кешираният токен е невалиден за истинските посетители; изкушаващата „поправка“ да се изключи проверката тихомълком премахва защитата.

Кратка самопроверка

1. 1Отворете страницата с формуляра в частен прозорец, отворете инструментите за разработчици на браузъра и потърсете в конзолата грешки от скрипта на CAPTCHA.
2. 2Проверете дали уиджетът действително се появява – веднъж преди и веднъж след приемане на банера за бисквитки – и дали формулярът не може да бъде изпратен, докато уиджетът липсва.
3. 3В административната конзола на доставчика проверете дали ключът на сайта включва вашия активен домейн (включително варианти като www) и дали ключовете във вашия плъгин за формуляри или код съответстват на него – а не ключове от документацията или от тестова среда.
4. 4В настройките на плъгина за формуляри се уверете, че интеграцията на CAPTCHA е включена за този конкретен формуляр; при reCAPTCHA v3 проверете дали прагът на оценката е над 0.
5. 5Ако имате достъп до кода, намерете проверката на сървъра и се уверете, че тя отхвърля изпращането, когато отговорът е отрицателен или токенът липсва.
6. 6Изключете страницата с формуляра от кеширането на цели страници или се уверете, че токенът се създава наново в браузъра.
7. 7Изпратете истинско тестово съобщение и проверете дали пристига; повтаряйте проверката след промени в темата, плъгините или инструмента за съгласие.

CAPTCHA е един слой, а не цялата защита. В комбинация с поле honeypot, проверка на времето и филтриране на сървъра грешна настройка на едно място не оставя формуляра широко отворен. Ако искате бърза представа за състоянието на формулярите си, въведете домейна си на formexposed.com – докладът показва дали видимите отвън части от настройката на вашата CAPTCHA са наред.