Atak bota na formularz newslettera. Jak się zabezpieczyć

Jeśli masz na stronie formularz zapisu do newslettera i polegasz na wbudowanej captchy swojego dostawcy, to prawdopodobnie masz otwarte drzwi dla hakerów. Przez trzy miesiące mój formularz w MailerLite był atakowany i zbudowane przeze mnie zabezpieczenia działały. W tym tygodniu hakerzy znaleźli jednak nowy sposób i formularz posłużył do wysyłania niechcianych maili do obcych ludzi, z mojej domeny, z poprawnym SPF i DKIM. W tym tekście opisuję, po czym to poznałem (po niemieckich autoresponderach), co to jest subscription bombing i jaka architektura zamyka ten wektor ataku.

Nie jest to tekst z teorii, tylko opis incydentu z 2 września 2026 i tego, co po nim zmieniłem.

Jak to się zaczęło: autorespondery od ludzi, których nie znam

Pierwszy sygnał nie przyszedł z analityki, tylko na moją skrzynkę kontaktową. Zacząłem dostawać autorespondery. „Sehr geehrte Damen und Herren, ich befinde mich derzeit nicht im Büro”. „Thank you for sending your email. I am currently out of office”. Od ludzi z niemieckich i amerykańskich firm przemysłowych, których nigdy w życiu nie widziałem na oczy.

Skąd to? Nie prowadziłem żadnej kampanii na rynek niemiecki ani amerykański i nie znałem ani jednej z tych firm (odlewnie, spedycje, producenci elementów złącznych). A autorespondery były odpowiedziami na mój mail, czyli coś z mojej domeny wysłało do tych ludzi wiadomość.

Pierwsza myśl: ktoś mi się włamał na konto mailowe. Sprawdzam serwer. Czysto. Sprawdzam logi, też czysto, i… nie ma śladu po teoretycznie wysłanych mailach, na które mam autorespondery. Sprawdzam nagłówki maili, podejrzewając jakiś phishing. Są poprawne. Sprawdzam DNS-y, a potem konfigurację domeny super narzędziem, jakie polecam: MXToolbox. Wszystko jest idealnie. Czyli coś w jakiś sposób wysyła maile jako ja, ale to nie jestem ja ani mój serwer pocztowy.

Co pozostało więc? Newsletter. Zajrzałem do panelu MailerLite i tam było widać wszystko.

Diagnoza: 17 zapisów w cztery godziny

Wyeksportowałem listę aktywnych subskrybentów i pierwsze, co rzuciło mi się w oczy, to układ adresów:

juan.salazar+km1387388b00853@vectorcag.com
msherman+km54e12ca400827@specialtyring.com
jonathan.jankowski+km161d04ab00660@vectorcag.com
jstevens+km1051609400836@mastertag.com

W każdym to samo: imię, znak plus, km, osiem znaków szesnastkowych i pięć cyfr. Czy siedemnastu ludzi wpisujących się w formularz wygeneruje taki układ? Nie. Jeden skrypt owszem.

Sygnałów było więcej, bo 17 potwierdzonych zapisów między 16:27 a 20:47 jednego dnia to nie jest mój normalny ruch (u mnie to jeden zapis na kilka tygodni), a do tego adresy IP zapisu szły z sieci domowych z całego świata, potwierdzenia zaś z centrów danych AWS i Microsoftu. Niemieckie i amerykańskie firmy przemysłowe zapisujące się na polskojęzyczny newsletter o LinkedInie, czyli zero sensu biznesowego. Do tego domeny nie były zmyślone. Za każdym adresem stał prawdziwy człowiek w istniejącej firmie.

Ostatnia rejestracja miała znacznik czasu późniejszy niż mój eksport. Bot pracował w momencie, gdy go diagnozowałem.

Prawdziwa skala: 213 zapisów, 189 niepotwierdzonych

Wszedłem w ustawienia formularza i okazało się, że to nie był incydent jednego dnia. Formularz utworzyłem 9 czerwca. Od tego czasu:

Metryka	Wartość
Zapisów łącznie	213
Potwierdzonych (aktywnych)	24
Niepotwierdzonych	189
Odsetek niepotwierdzonych	~89%

Zdrowy formularz z double opt-in ma 20–40% niepotwierdzonych. Przy 89% nie ma co mówić o słabej konwersji, to jest bot.

Gorsza była druga liczba. Przejrzałem te 24 „aktywne” adresy jeden po drugim. Ilu prawdziwych ludzi? Siedmiu: dwa moje adresy testowe i pięć osób, które zapisały się same między lutym a sierpniem. Pozostałych 17 to boty z jednego dnia, które ktoś, a właściwie coś, potwierdziło za nie.

Co to właściwie jest: subscription bombing

Czy to jakiś egzotyczny przypadek? Nie, to skatalogowana technika ataku. MITRE ATT&CK opisuje ją jako T1667 „Email Bombing” w taktyce Impact, a definicja mówi o zautomatyzowanych botach, które zapisują adres ofiary na listy mailingowe niesprawdzające nowych zapisów.

Jak to działa?

1. Atakujący ma listę prawdziwych adresów firmowych: z wycieku, ze scrapingu albo od brokera danych. U mnie chyba chodziło o szpiegostwo przemysłowe.
2. Bot znajduje formularze zapisu, ustala, jaki endpoint je obsługuje, i wysyła na nie zapytania z tymi adresami.
3. Każdy formularz odpala mail potwierdzający z domeny właściciela strony, z poprawnym SPF i DKIM.
4. Ofiara dostaje setki lub tysiące maili w krótkim czasie.
5. Celem ataku nie jest sam formularz ani moja strona, ale endpoint u dostawcy, który ten formularz obsługuje.

Dlaczego prawdziwe adresy? Bo tylko one działają. Fałszywy adres się odbije, a prawdziwa skrzynka przyjmie mail, uruchomi potwierdzenie i da przewidywalny efekt. Proofpoint podkreśla jedną rzecz: maile potwierdzające idą z legalnych domen i mają poprawną autentykację, więc przechodzą przez filtry antyspamowe oparte na reputacji. Klasyczne zastosowanie to zasypanie skrzynki ofiary, żeby ukryć w niej alert o oszustwie albo o zmianie hasła.

A ten +km z hashem? Najprawdopodobniej tag śledzący: atakujący chce wiedzieć, przez który formularz dany adres przeszedł. Nie znalazłem publicznego źródła, które przypisywałoby tę sygnaturę do nazwanej grupy, więc traktuję ją jako odcisk palca do filtrowania, a nie jako pewną identyfikację.

Ofiary są dwie naraz. Ludzie, których adresy podstawiono, dostają mail, o który nie prosili. Jak się potwierdzi, a u mnie w 17 przypadkach się potwierdził, to przestępcy mają już dane do dalszego kroku. A ja? Moja domena nadawcza wysłała ponad 200 niechcianych wiadomości. Każde kliknięcie „to jest spam” po drugiej stronie obciąża moją reputację, a pułapki spamowe w takich listach potrafią wpisać domenę na blacklistę. Na szczęście na tyle szybko wykryłem i zablokowałem atak, że tak się nie stało.

Dlaczego moje zabezpieczenia nie zadziałały

Miałem włączone rzeczy, które w teorii powinny wystarczyć. Zawiodły wszystkie, po kolei.

1. Captcha i honeypot działają tylko w przeglądarce

W formularzu był napisany przez mnie honeypot, czyli ukryte pole, którego człowiek nie widzi, a bot wypełnia, i był też mechanizm mierzący czas wypełnienia. Czyli jak formularz był wypełniony w czasie poniżej 3 sekund, to znaczy, że robił to bot, a nie człowiek. Uważałem, że sprytnie to wymyśliłem, i przez kilka miesięcy spełniało swoją rolę. Dołożyłem do tego logowanie IP i sprawdzanie, czy nie ma więcej zapisów z pojedynczego IP, i spałem spokojnie. Gdzie był problem i dlaczego finalnie to nie zadziałało? Wszystkie te zabezpieczenia dzieją się w przeglądarce. Bot, który wysyła surowy POST na endpoint formularza, nigdy nie ładuje strony, nie renderuje widgetu i nie widzi honeypota. Przez kilka miesięcy działały blokady po IP i rate limit, ale hakerzy chyba to wykryli i zmienili taktykę, bo w logach widać, że zaczęli korzystać z botnetu i każda próba szła z innego IP.

Cloudflare pisze o tym w dokumentacji Turnstile: sam widget po stronie klienta nie chroni formularza, bo token można sfałszować, a atakujący może wysłać dowolny ciąg znaków na endpoint bez przechodzenia challenge’u. Stąd weryfikacja serwerowa jest obowiązkowa, nie opcjonalna.

Pytanie do własnego dostawcy newslettera brzmi więc: czy captcha jest sprawdzana po stronie serwera, czy tylko renderowana? Możesz to sprawdzić sam. Wyślij curlem POST na endpoint swojego formularza z pominięciem widgetu. Jeśli adres pojawi się na liście, captcha jest ozdobą.

2. Double opt-in obchodzą korporacyjne skanery

To mnie zaskoczyło najbardziej. Część botowych adresów miała status aktywny, mimo włączonego double opt-in. Ktoś kliknął link potwierdzający. Kto? Żaden człowiek.

Korporacyjne bramki bezpieczeństwa (Proofpoint URL Defense, Mimecast URL Protect, Barracuda) pobierają każdy link w przychodzącej poczcie, żeby przeskanować go przed dostarczeniem, więc klikają też link potwierdzający double opt-in. Adres przechodzi w stan aktywny bez udziału i bez zgody człowieka.

To znany od lat problem w społeczności marketing automation, gdzie konsensus jest taki, że kliknięcia linku nie można traktować jako dowodu zgody. U mnie widać to w danych: adresy IP, z których przyszły potwierdzenia, należą do AWS i do infrastruktury pocztowej Microsoftu. Firmy z mojej listy to dokładnie ten profil, czyli korporacje z bramkami bezpieczeństwa. Stąd mieszanka: część adresów potwierdzona automatycznie, większość nie.

3. Flaga „nieaktywny” w panelu nic nie blokuje

Kiedy już wiedziałem, co się dzieje, najpierw wyłączyłem formularz ze strony i wyłączyłem go w MailerLite, a potem zacząłem sprawdzać logi. Jakież było moje zdziwienie, kiedy okazało się, że formularz w API miał wartość false, czyli był oznaczony jako nieaktywny, a nic to nie zmieniło. Ostatnia rejestracja? Zapis sprzed godziny, kiedy formularz był już wyłączony.

Jak to możliwe? Status formularza w panelu mówi tylko o tym, czy jest gdzieś osadzony i aktywny, a nie o tym, czy jego endpoint przyjmuje dane. Endpoint żyje własnym życiem, dopóki formularz istnieje.

Sprawdziłem też, czy da się go po prostu wyłączyć przez API. Nie da się, bo MailerLite wystawia dla formularzy tylko GET, PUT (który zmienia wyłącznie nazwę) i DELETE, a operacji „wyłącz” nie ma w ogóle. Jedyne, co zamyka endpoint, to skasowanie formularza, więc to zrobiłem. Po usunięciu ten sam POST, który wcześniej dodawał subskrybentów, zwraca 404.

Ceną jest nieodwracalny przepadek treści formularza, statystyk i konfiguracji strony potwierdzenia (adresy w grupie zostają), a powrót oznacza nowy formularz z nowym identyfikatorem.

4. Formularz hostowany przez dostawcę to osobna furtka ataku

Ostatnia rzecz, jaką wykryłem: mój formularz miał własną, publiczną stronę hostowaną przez MailerLite, z krótkim slugiem, niezależną od mojej domeny. Co by mi dało przepisanie całej mojej strony na nowo? Nic, bo bot nie uderzał w moją stronę. Hostowane formularze są w tych narzędziach funkcją, nie dodatkiem.

Jak to naprawiłem: własny endpoint zamiast formularza dostawcy

Co zamyka ten wektor? Tylko jedno: przeniesienie weryfikacji na serwer, którym sam zarządzam.

Podejście	Gdzie jest sprawdzenie bota	Bezpieczne?
Wbudowany snippet dostawcy	Przeglądarka	❌
Formularz hostowany / popup	Przeglądarka + publiczny URL	❌
Własny HTML → endpoint dostawcy	Przeglądarka	❌
Własny HTML → własny endpoint → API dostawcy	Serwer	✅

Dlaczego tylko czwarty wariant? Bo bot nie ma jak pominąć kroku, który wykonuje się po mojej stronie. Do tego klucz API zostaje tajny, a to właśnie jego brak wymuszał wcześniej publiczny, a więc podatny endpoint. Domyślnie, jak instalujesz formularz zapisu na swoim WordPressie czy innej stronie, to właśnie wykorzystujesz gotowca od dostawcy. To naprawdę zły pomysł.

Gdzie postawić ten endpoint

Moja strona to framework Astro na Vercelu, generowane statycznie. Sprawdziłem, czy istnieje oficjalna integracja. Istnieje, a instrukcja mówi: zainstaluj oficjalny adapter i zrób z tego route serwerowy. Sprawdziłem i odpuściłem ten sposób. Dlaczego? Bo dokumentacja Vercela o Astro mówi, żeby w projektach Astro nie używać vercel.json do przepisywania ścieżek: daje to niespójne zachowanie i nie ma oficjalnego wsparcia. Musiałbym przenieść stronę z Vercela na przykład na Cloudflare, a nie widzę takiej potrzeby.

Mój vercel.json niesie produkcyjny Content-Security-Policy, komplet nagłówków bezpieczeństwa, 17 przekierowań SEO i trailingSlash. Adapter przejmuje wypisywanie konfiguracji wyjściowej. Stawiać to wszystko na niepotwierdzonym założeniu, i to w ramach naprawy bezpieczeństwa? Zły pomysł i trochę zamiana siekierki na kijek.

Wybrałem wariant, który rozwiązuje problem, zamiast go omijać: zbudować od zera natywną funkcję Vercela w katalogu api/ w głównym repo. Buduje się niezależnie od wykrytego frameworka i bez żadnej konfiguracji. Strona zostaje w stu procentach statyczna, vercel.json pozostaje jedynym źródłem prawdy, a build Astro nie zmienia się ani o linijkę.

Przepływ zabezpieczeń w docelowym rozwiązaniu

Kolejność zabezpieczeń ma znaczenie: najtańsze sprawdzenia idą pierwsze, żeby bot zużywał jak najmniej mojego budżetu obliczeniowego. Nie chcę po miesiącu dostać ekstra faktury od Vercela za czas serwera zużyty na obsługę botów i Ty też tego nie chcesz.

1. Stop przy błędach konfiguracji: jeśli brakuje którejkolwiek zmiennej środowiskowej, endpoint zwraca 503, kończy działanie i zgłasza IP do fail2ban. Otwarty endpoint z wyłączonymi kontrolami to stan, z którego właśnie się wygrzebywałem. Brutalnie proste i skuteczne zabezpieczenie.
2. Sprawdzenie Origin, czyli odrzucenie POST-ów z obcych domen.
3. Honeypot: jeśli ukryte pole jest wypełnione, zwracam fałszywe 200 i nie informuję bota, że wpadł. Uważa, że mu się udało, więc nie ponawia próby.
4. Kontrola czasu: odrzucenie zgłoszeń szybszych niż 3 sekundy i starszych niż 6 godzin. Wartość przychodzi z przeglądarki, więc bot może ją sfałszować; to filtr za darmo, nie zabezpieczenie. Generalnie u mnie przez długi czas działało i u Ciebie też będzie, bo obejście wymaga już większej pracy od hakera.
5. Walidacja adresu: podstawa, ale musi być.
6. Weryfikacja tokenu Turnstile po stronie serwera, czyli jedyny krok, którego bezpośredni POST nie pominie. Ostatnia linia obrony i najskuteczniejsza.
7. Dopiero teraz następuje wywołanie API dostawcy newslettera z tajnym kluczem i statusem „niepotwierdzony”.
8. Zwrócenie generycznej odpowiedzi, identycznej dla każdego odrzucenia. Bot nie dowie się, czy zatrzymał go honeypot, czas czy captcha, więc nie ma czego iterować.

Dwóch rzeczy z klasycznych poradników tu nie ma, i to celowo.

Rate limitingu po IP nie ma w kodzie. Jego miejsce jest w infrastrukturze (u mnie reguła zapory na ścieżce endpointu, 10 żądań na minutę na adres IP), a nie w funkcji, która przy każdym wywołaniu startuje od zera i nie ma gdzie trzymać licznika. Zastrzeżenie i tak zostaje: mój bot szedł z rozproszonych adresów domowych, więc limit na IP sam z siebie by go nie zatrzymał.

Filtra wzorca +km też nie ma. Kusiło, ale to zabezpieczenie przed poprzednim atakiem. Napastnik zmienia tag w minutę, a ja zostaję z regułą, która pewnego dnia odrzuci prawdziwego człowieka używającego plus-adresowania. Sygnatura nadaje się do sprzątania listy i do alertów, nie do bramki wejściowej.

Weryfikacja captchy

Wybrałem w końcu Cloudflare Turnstile. Dlaczego? Jest to darmowe rozwiązanie, bez limitu i bez wymogu hostowania strony w Cloudflare, a do tego nie ustawia trwałych identyfikatorów, więc nie śledzi między stronami. No i najmniej boli pod RODO: francuski CNIL i niemiecki organ ochrony danych podejmowały działania przeciwko stronom używającym reCAPTCHA bez wyraźnej zgody, bo reCAPTCHA ustawia trwałe ciasteczko i dzieli sygnały w ekosystemie Google. A reCAPTCHA to właśnie to, co oferuje wbudowany formularz MailerLite. Używając go, miałbym nie tylko dziurę w bezpieczeństwie, ale i zobowiązanie po stronie zgód RODO.

Weryfikacja serwerowa to jeden POST na endpoint siteverify Cloudflare z parametrami secret, response (token z ukrytego pola formularza) i opcjonalnie adresem IP użytkownika. W odpowiedzi sprawdzam nie tylko success, ale też hostname i action, żeby token wygenerowany na innej stronie albo dla innego formularza nie przeszedł.

Dwa ograniczenia: token jest ważny 300 sekund i jest jednorazowy. Po stronie przeglądarki łatwo się o to potknąć. Jeśli zapis się nie powiedzie i użytkownik zostaje na stronie, jego token jest już zużyty, więc druga próba poleci ze spalonym tokenem i serwer ją odrzuci, choć po stronie człowieka wszystko jest w porządku. Widget trzeba zresetować po każdej nieudanej próbie.

Utwardzenie strony potwierdzenia: czego nie dało się zrobić

Zalecenie z każdego poradnika brzmi: nie potwierdzaj zapisu na samym wejściu na link, tylko prowadź nim na stronę, która jeszcze nic nie potwierdza, z przyciskiem „Tak, potwierdzam zapis” wysyłającym POST. Skaner zrobi GET i pobierze stronę, ale przycisku nie kliknie. Człowiek kliknie.

Logika bez zarzutu, ale przy double opt-in po stronie dostawcy niewykonalna. Dlaczego? Link potwierdzający generuje i obsługuje dostawca. Prowadzi na jego endpoint, ten endpoint aktywuje subskrypcję, a dopiero potem przekierowuje na moją stronę podziękowania. Auto-klik skanera trafia więc w cel, zanim cokolwiek dotrze do mojego serwera.

Żeby zrobić to naprawdę, trzeba by przejąć całe double opt-in: zapisywać ludzi ze statusem „niepotwierdzony”, wysyłać własny mail potwierdzający z własnym linkiem i samemu przełączać status po kliknięciu przycisku. To oznacza własną wysyłkę transakcyjną i przeniesienie odpowiedzialności za dostarczalność na siebie.

Nie zrobiłem tego i nie uważam, żeby to było pójście na skróty. Auto-klik szkodził tylko dlatego, że boty w ogóle wchodziły na listę. Kiedy captcha odsiewa je, zanim dostawca się o nich dowie, nie ma już kogo fałszywie potwierdzać.

Checklista wdrożeniowa prawidłowego formularza zapisu na newsletter

Jeśli chcesz przenieść do siebie to, co ja sprawdziłem u siebie, oto minimalna lista rzeczy do zrobienia. U mnie wystarczył pierwszy punkt, żeby wiedzieć, że coś jest nie tak.

Natychmiast, w godzinę:

• Sprawdź stosunek potwierdzonych do niepotwierdzonych zapisów u swojego dostawcy. To Twój test diagnostyczny.
• Przetestuj curlem, czy captcha Twojego formularza jest sprawdzana serwerowo.
• Wstrzymaj wysyłki do zanieczyszczonej grupy.

Sprzątanie listy:

• Wysegmentuj podejrzane adresy: po wzorcu, po dacie, po domenie.
• Usuń je opcją Forget, nie Delete. Forget kasuje dane całkowicie w ciągu 30 dni, czyli realizuje prawo do usunięcia danych z RODO, a to są dane osobowe prawdziwych ludzi, których nikt nie pytał o zgodę.
• Nigdy nie aktywuj ręcznie niepotwierdzonych rekordów.

Docelowa architektura:

• Własny endpoint serwerowy zamiast snippetu dostawcy.
• Klucz API w zmiennych środowiskowych, nigdy w kodzie klienckim.
• Captcha z obowiązkową weryfikacją serwerową, sprawdzająca też hostname i action.
• Honeypot i kontrola czasu wypełnienia jako darmowe filtry, nie jako zabezpieczenie.
• Sprawdzenie nagłówka Origin, jeśli endpoint stoi poza frameworkiem.
• Usunięcie publicznego formularza hostowanego przez dostawcę. Sprawdź, czy „dezaktywacja” zamyka endpoint, bo zwykle nie zamyka. Szczerze pisząc, uważam, że to poważna wpadka MailerLite, a pisanie w ich helpie, że wiedzą o tym i nie ma jak się zabezpieczyć, mało mnie interesuje. To w mojej opinii błąd na poziomie architektury.
• Rate limiting po IP na poziomie infrastruktury Twojego serwera plus zgłoszenie do fail2ban.
• Alert przy nagłym skoku liczby zapisów: proste do zrobienia, a pozwoliłoby wykryć taki atak szybciej niż w godzinę.

Czego nie robić

• Nie blokuj wszystkich adresów z plusem. Plus-addressing (czyli zapisywanie maila w formie ada.kowalska+newsletterRafala@gmail.com) to legalna, przydatna funkcja i specjaliści od e-mail marketingu, jak Paweł Sala, odradzają blokowanie go hurtem. Filtruj zaobserwowaną sygnaturę, nie całą klasę adresów.
• Nie licz na blokadę domen jednorazowych. W tym ataku wszystkie domeny były prawdziwe i korporacyjne, więc ten filtr by nie zadziałał.
• Nie opieraj się na jednej warstwie. Farmy rozwiązujące captcha istnieją, botnety rotują IP. Wartość jest w nakładaniu warstw, nie w wyborze jednej idealnej.

Co z tego wynika dla Ciebie

Mój formularz, a raczej mój system do newsletterów, wysyłał maile do ludzi, którzy o nie nie prosili. Skąd o tym wiem? Tylko stąd, że kilkoro z nich miało włączonego autorespondera. W normalnej analityce ataku nie było widać w ogóle, bo liczba zapisów rosła, a rosnąca liczba zapisów wygląda w panelu jak wzrost, nie jak problem. Gdybym miał setki zapisów dziennie, pewnie bym nawet tego ataku nie zauważył.

Masz formularz newslettera? Poświęć pięć minut i sprawdź stosunek potwierdzonych do niepotwierdzonych. U mnie było 189 na 213. Jak masz podobnie, to zacznij sprawdzać zabezpieczenia. Albo po prostu: zacznij sprawdzać zabezpieczenia formularza :)

Źródła

• MITRE ATT&CK — T1667: Email Bombing
• Communications of the ACM — Subscription Bombing: Email under Attack
• M3AAWG — zalecenie nagłówka ograniczającego ataki list bomb
• Cloudflare Turnstile — weryfikacja tokenu po stronie serwera
• MailerLite — 9 sposobów na zapobieganie atakom botów i spamowym zapisom
• MailerLite — jak usunąć lub „zapomnieć” subskrybenta
• Vercel — Astro na Vercelu
• Astro — security.checkOrigin