Kodėl jūsų kontaktinė forma yra didžiausia spam rizika

Problema senesnė, nei manote

Kontaktinės formos kaip spam vektorius naudojamos nuo ankstyvųjų 2000-ųjų, tačiau problema paaštrėjo, nes el. pašto paslaugų teikėjai sugriežtino autentifikavimo reikalavimus. Dauguma kontaktinių formų vis dar kuriamos taip pat: naudotojas užpildo formą, jūsų serveris išsiunčia el. laišką naudodamas naudotojo adresą From antraštėje, o jūs laukiate atsakymų.

Tai klasikinis el. pašto klastojimo pažeidžiamumas. Spameriai gali naudoti jūsų formą el. laiškams siųsti taip, kad jie atrodytų siunčiami iš bet kurio jų norimo adreso, nukreipiant juos per jūsų serverio IP. Jei tokiu būdu išsiunčiama pakankamai spam, jūsų domenas pažymimas, o teisėti transakciniai el. laiškai nebepristatomi į gautuosius.

Pataisymas paprastas, bet dauguma mokomųjų straipsnių vis dar jį pateikia neteisingai.

Kas kontaktines formas daro taip lengvai išnaudojamas

Tipinė kontaktinė forma priima tris laukus: vardą, el. pašto adresą ir žinutę. Serverio pusės apdorojimo kodas paima tą el. pašto adresą ir tiesiogiai įdeda jį į siunčiamo SMTP pranešimo From antraštę. Tai patogu atsakymams — gautuosiuose galite tiesiog paspausti „reply“ — bet tai taip pat dovana spameriams.

Štai kas nutinka, kai spameris randa jūsų formą:

1. Jie pateikia formą su aukos el. pašto adresu „from“ lauke
2. Jūsų serveris pareigingai išsiunčia el. laišką su tos aukos adresu From antraštėje
3. Aukos pašto serveris mato el. laišką, kuris teigia esąs iš jų domeno, bet ateina iš jūsų IP
4. Jei jūsų domenas neturi tinkamų SPF/DKIM/DMARC įrašų (arba net jei juos turi), el. laiškas vis tiek gali praeiti, nes daugelis serverių kontaktinių formų srautui taiko švelnesnes taisykles
5. Auka gauna spam, kuris atrodo siunčiamas iš jos pačios adreso, arba jūsų domenas pažymimas dėl klastojimo

Tai nėra teorinė ataka. Tai vyksta nuolat. Jei turite kontaktinę formą ir niekada netikrinote savo pašto serverio žurnalų, tikriausiai jau esate taip naudojami.

Teisingas būdas siųsti kontaktinės formos el. laiškus

Sprendimas — niekada nedėti naudotojo įvestų duomenų į From antraštę. Vietoj to:

• From: [email protected] (arba bet kuris jums priklausantis adresas)
• Reply-To: Naudotojo pateiktas el. pašto adresas
• Subject: Jei norite, įtraukite naudotojo vardą, bet niekada jo el. pašto adreso
• Body: Įtraukite visus formos duomenis, aiškiai pažymėtus

Taip jūsų serveris siunčia el. laiškus tik iš adresų, kurie jums priklauso ir yra tinkamai autentifikuoti. Kai gautuosiuose paspaudžiate „reply“, atsakymas vis tiek keliauja naudotojui — tam ir skirta Reply-To. Tačiau spameriai negali naudoti jūsų formos savavališkiems adresams apsimesti.

Dauguma el. pašto bibliotekų tai palaiko iš karto. PHP PHPMailer:

$mail->setFrom('[email protected]', 'Contact Form');
$mail->addReplyTo($_POST['email'], $_POST['name']);

Python smtplib su email.mime:

msg['From'] = '[email protected]'
msg['Reply-To'] = form_data['email']

Node.js su Nodemailer:

const mailOptions = {
  from: '[email protected]',
  replyTo: req.body.email,
  // ...
};

Jei jūsų kontaktinė forma šiuo metu deda naudotojo įvestus duomenis į From antraštę, tai vienos eilutės pataisymas. Padarykite tai šiandien.

Srauto ribojimas nėra pasirenkamas

Net ir laikantis tinkamos antraščių higienos, neapsaugota kontaktinė forma vis tiek yra spam vektorius. Spameriai pateiks jūsų formą šimtus kartų su skirtingais žinučių tekstais, o jūsų gautieji prisipildys šiukšlių.

Srauto ribojimo reikia keliais lygiais:

• Pagal IP: Ne daugiau kaip 5 pateikimai per valandą iš to paties IP
• Pagal el. paštą: Ne daugiau kaip 3 pateikimai per dieną iš to paties el. pašto adreso
• Globaliai: Ne daugiau kaip 50 pateikimų per valandą per visus naudotojus (koreguokite pagal savo srautą)

Srauto ribojimas turi būti jūsų programos kode, o ne tik žiniatinklio serverio konfigūracijoje. Nginx ir Apache srauto ribojimas gali padėti, bet jie veikia užklausų lygiu ir nežino apie el. pašto adresus ar konkrečiai formai būdingus piktnaudžiavimo modelius.

Jei naudojate karkasą, greičiausiai yra srauto ribojimo middleware, kurį galite tiesiog įdiegti. Jei kuriate nuo nulio, paprastas Redis skaitiklis su pasibaigiančiais raktais veikia pakankamai gerai:

key = f"contact_form:{ip_address}"
count = redis.incr(key)
if count == 1:
    redis.expire(key, 3600)  # 1 hour
if count > 5:
    return error("Rate limit exceeded")

Tai nėra neįveikiama — spameriai gali keisti IP — bet tai reikšmingai padidina piktnaudžiavimo kainą.

CAPTCHA yra kompromisas, o ne sprendimas

Google reCAPTCHA v3 yra nematoma ir vertina naudotojus pagal elgseną, o tai skamba idealiai. Praktikoje ji dažniau nei tikėtumėtės blokuoja teisėtus naudotojus, ypač naudojančius VPN, Tor ar bendrus įmonių tinklus.

reCAPTCHA v2 („I'm not a robot“ žymimasis langelis) yra patikimesnė, bet prideda trinties. Honeypot laukai — paslėpti formos įvesties laukai, kurių žmonės nepildys, bet botai pildys — pagauna primityvesnius botus be jokio poveikio naudotojui, tačiau bet kuriam rimtesniam spameriui juos apeiti labai paprasta.

Geriausias požiūris yra sluoksniuotas:

1. Tinkamos el. pašto antraštės (nediskutuotina)
2. Srauto ribojimas (nediskutuotina)
3. Honeypot laukas (lengva pergalė, be trūkumų)
4. CAPTCHA tik tada, jei po aukščiau nurodytų priemonių vis dar gaunate daug spam

Jei vis dėlto pridedate CAPTCHA, naudokite reCAPTCHA v3 su žemu slenksčiu (0,5 arba žemesniu) ir atsarginiu perėjimu prie v2 naudotojams, kurių įvertinimas prastas. Taip daugumai naudotojų trintis išlieka maža, o botai vis tiek blokuojami.

Kada naudoti trečiosios šalies formų paslaugą

Jei valdote nedidelę svetainę ir nenorite prižiūrėti formų infrastruktūros, trečiųjų šalių paslaugos, tokios kaip Formspree, Tally ar Netlify Forms, visa tai atlieka už jus. Jos riboja srautą, validuoja ir siunčia el. laiškus iš savo domenų, todėl jūsų reputacija lieka švari.

Kompromisas tas, kad naudotojų duomenis siunčiate trečiajai šaliai, o tai gali prieštarauti jūsų privatumo politikai ar GDPR įsipareigojimams. Duomenų apdorojimas kliento pusėje tampa vis populiaresne praktika privatumu besirūpinančioms komandoms, tačiau kontaktinėms formoms iš esmės reikia serverio pusės apdorojimo — negalite siųsti el. laiškų iš naršyklės neatskleisdami prisijungimo duomenų.

Jei tvarkote jautrias užklausas (teisines, medicinines, finansines), tikriausiai turite valdyti savo formų infrastruktūrą. Visais kitais atvejais trečiosios šalies paslauga yra pagrįstas pasirinkimas.

DMARC problema

Net jei pataisote kontaktinės formos antraštes, nesate saugūs, jei jūsų domenas neturi DMARC politikos. DMARC nurodo gaunantiems pašto serveriams, ką daryti su el. laiškais, kurie nepraeina SPF arba DKIM patikrų. Be jos spameriai vis tiek gali siųsti el. laiškus, kurie atrodo ateinantys iš jūsų domeno, net jei jie nenaudoja jūsų serverių.

DMARC nustatymas nepatenka į šio straipsnio apimtį, bet jei rimtai rūpinatės el. pašto reputacija, tai nediskutuotina. Pradėkite nuo tik stebėjimui skirtos politikos (p=none) ir palaipsniui pereikite prie p=quarantine arba p=reject, kai įsitikinsite, kad jūsų teisėtas el. paštas tinkamai autentifikuojamas.

O kaip dėl slapukų sutikimo ir formų sekimo?

Jei jūsų kontaktinė forma naudoja analitiką ar rinkodaros pikselius pateikimams sekti, jums tikriausiai taikomos GDPR ir ePrivacy taisyklės. Daugumai kontaktinių formų sekimo nereikia — jūs jau žinote, kad kažkas pateikė formą, nes gavote el. laišką — tačiau jei naudojate ką nors panašaus į Facebook Pixel ar Google Analytics įvykius, prieš įkeldami tuos skriptus turite gauti aiškų sutikimą.

Paprasčiausias požiūris — visai nesekti kontaktinės formos pateikimų. Jei privalote juos sekti, įkelkite sekimo skriptus tik po to, kai naudotojas sutinka, ir įsitikinkite, kad jūsų sutikimo juosta atitinka reikalavimus.

Pagrindinės išvados

• Niekada nedėkite naudotojo pateiktų el. pašto adresų į From antraštę. Vietoj to naudokite Reply-To.
• Srauto ribojimas privalomas. Įgyvendinkite jį programos lygiu, ne tik žiniatinklio serveryje.
• Honeypot laukai yra nemokama pergalė. CAPTCHA turėtų būti paskutinė priemonė.
• Trečiųjų šalių formų paslaugos yra pagrįstas pasirinkimas mažoms svetainėms, bet jos sukuria privatumo kompromisų.
• Jei siunčiate bet kokį el. paštą iš savo domeno, jums reikia DMARC politikos.

DUK

K: Ar galiu tiesiog išjungti kontaktinę formą ir vietoj jos naudoti mailto nuorodą?

A: Galite, bet mailto nuorodos atskleidžia jūsų el. pašto adresą duomenų rinkikliams, ir prarandate galimybę rinkti struktūrizuotus duomenis. Jei spam kiekis nevaldomas, mailto nuoroda geriau nei neveikianti kontaktinė forma, bet sutaisyti formą geriau už abu variantus.

K: O jei dėl teisėtų priežasčių man reikia siųsti el. laiškus iš naudotojo adreso?

A: Beveik neabejotinai nereikia. Jei manote, kad reikia, tikriausiai bandote spręsti darbo eigos problemą (pvz., atsakymų maršrutizavimą), kurią Reply-To jau išsprendžia. Jei jums iš tiesų reikia siųsti el. laiškus iš savavališkų adresų, jums reikia dedikuotos el. pašto paslaugos su tinkamu autentifikavimu, o ne kontaktinės formos.

K: Kaip sužinoti, ar mano kontaktine forma jau piktnaudžiaujama?

A: Patikrinkite savo pašto serverio žurnalus dėl išeinančių SMTP jungčių. Jei matote didelį išeinančių el. laiškų kiekį į adresus, kurių neatpažįstate, arba jei jūsų domeną pažymėjo spam duomenų bazės, tokios kaip Spamhaus, tikriausiai esate naudojami kaip relė. Tokie įrankiai kaip MXToolbox gali patikrinti jūsų domeno reputaciją.

K: Ar saugu naudoti nemokamą CAPTCHA paslaugą?

A: Google reCAPTCHA yra nemokama ir plačiai naudojama, bet ji siunčia naudotojų duomenis Google, o tai gali prieštarauti jūsų privatumo politikai. hCaptcha yra į privatumą orientuota alternatyva, kuri netreniruoja AI modelių naudodama jūsų naudotojus. Cloudflare Turnstile yra dar viena parinktis, mažiau įkyri nei tradicinės CAPTCHA.

K: Kuo skiriasi SPF, DKIM ir DMARC?

A: SPF nurodo, kuriems pašto serveriams leidžiama siųsti el. laiškus iš jūsų domeno. DKIM kriptografiškai pasirašo išeinančius el. laiškus, kad gavėjai galėtų patikrinti, jog jie nebuvo pakeisti. DMARC sujungia juos ir nurodo gavėjams, ką daryti, jei el. laiškas nepraeina SPF arba DKIM patikrų. Tinkamam el. pašto autentifikavimui reikia visų trijų.

Šaltiniai

• OWASP: Email Header Injection — Išsamus paaiškinimas, kaip kontaktinės formos gali būti išnaudojamos el. pašto klastojimui.
• RFC 5322: Internet Message Format — Techninis standartas, apibrėžiantis el. pašto antraštes, įskaitant From ir Reply-To.
• DMARC.org: Overview — Oficialus šaltinis DMARC politikoms suprasti ir įgyvendinti.
• Spamhaus: Domain Blocklists — Patikrinkite, ar jūsų domenas pažymėtas dėl spam, ir supraskite, kaip veikia blokavimo sąrašai.