Cum să protejezi formularul împotriva spamului în WordPress, Joomla!, PrestaShop sau orice altă aplicație bazată pe PHP? Pe parcursul unui trimestru, am numărat aproape 15.000 de trimiteri de spam din formulare de pe doar câteva site-uri web cu o audiență medie. Ce să faci când roboții se înregistrează prin formularul tău de contact sau primești tone de spamuri prin intermediul acestuia?

Din acest articol vei învăța:

  • cum să protejezi formularul împotriva spamului?
  • cum să protejezi formularul de roboți și oameni rău intenționați?
  • cum să pregătești un formular sigur fără a enerva utilizatorii?

Securizarea formularului de contact. Recunoașterea amenințărilor populare în 2024

În primul rând, să stabilim de ce vrem să protejăm formularul. Cel mai adesea, problema protecției formularelor este legată de ceea ce face un anumit formular și de informațiile, pe care le prelucrează. Din experiența mea, ne protejăm, în primul rând, de două tipuri de amenințări:

  1. Amenințări IT generale
  2. Amenințări de conținut

Am analizat încercările de spam capturate pe propriile noastre site-uri. Ne-am uitat mai atent la cererile primite în anul precedent. Amploarea problemei este considerabilă. Cele mai multe încercări au fost făcute pentru a posta linkuri spam pe site-ul nostru web. Legăturile erau din diferite industrii și în diferite limbi.

Porn SPAM – nimic surprinzător, a constituit o parte semnificativă a cererilor, urmat de SPAM medical, adică Viagra, Cialis, remedii pentru chelie etc. Cele mai multe spamuri plasate de roboți erau din domeniul financiar și priveau oferte de investiții „cu câștiguri spectaculoase”. Și acesta este „râul”, care curge prin Internetul nostru și ajunge la formularele de pe paginile web. De aceea ai nevoie de securitate eficientă.

Protejarea formularului împotriva amenințărilor IT

Când vorbesc despre cum să protejăm formularul împotriva acestui tip de amenințări, mă refer la ceea ce este asociat cu intențiile rele ale atacatorului și ce nu afectează direct sensul meritoriu al formularului în sensul de „fraudă”. În acest domeniu, nu vorbim de o cerere de împrumut completată corect, în care cineva a introdus câștiguri false mari.

Protejarea formularului împotriva amenințărilor de conținut

Când datele sunt introduse de o ființă umană cu rea-credință, vorbim despre cum să îți securizezi formularul împotriva atacurilor de conținut. Vorbesc despre situații în care atacatorul dorește, de exemplu, să-și configureze un cont în sistemul nostru. Face acest lucru pentru a profita de un beneficiu la care nu are dreptul etc. Folosește adesea date false pentru a-și ascunde identitatea. Prin urmare, furnizează o adresă de e-mail falsă, detalii de contact false etc.

Protecția formularului. Tipuri populare de atacuri

Să încercăm să revizuim tipurile de amenințări, care se ascund în formularele de pe site-urile web. În opinia mea, cele mai importante dintre ele sunt:

  1. Spam prin formular.
  2. Atacurile XSS.
  3. Injecție SQL.
  4. Atacurile CSRF și flood fill.
  5. Brute force.

Protejarea formularului împotriva spamului – chiar trebuie să mă gândesc la asta?

Pe scurt: DA. Fiecare formular este ținta potențială a unui atac. De ce? Pentru că există.

Spamul primit prin formularul de contact presupune că datele introduse în formular sunt apoi afișate oriunde. Scopul lor în sine, este, de obicei, să nu rupă securitatea. Ele presupun, totuși, ca după completarea formularului să se întâmple următoarele:

  • afișarea informațiilor introduse,
  • persistența datelor pe site,
  • trimiterea acestora cuiva prin e-mail,
  • salvarea lor în baza de date.

Indiferent de scenariul în care se întâmplă lucrurile, atacatorul speră ca mai devreme sau mai târziu conținutul să fie vizibil pe pagină sau să poată fi citit. Este posibil ca o persoană să citească conținutul (de exemplu, reclama unor medicamente pentru potență) sau să dea click pe un link din conținut, ceea ce oferă atacatorului o gamă largă de posibilități.

De ce roboții atacă formularele?

Pentru obținerea de linkuri, care vor fi recunoscute de roboții de căutare sau de oameni. Ce se întâmplă în continuare depinde, desigur, de pagina de destinație. Te poți aștepta, de exemplu, la următoarele scenarii:

  • un site web bazat pe phishing (detalii de conectare pentru phishing, de ex. pentru o bancă),
  • un link de spam în speranța că crawler-ul Google îl va găsi și astfel atacatorul va primi linkul către el însuși,
  • redirecționare nedorită către o ofertă mai mult sau mai puțin legală de orice tip (în principal: porno, finanțe, produse pentru potență),
  • programe malware care infectează computerul utilizatorului.

Oricum ar fi, este fără îndoială că spamul este nedorit. Începând de la scăderea poziției site-ului tău în Google, încărcarea greoaie pentru filtrarea informațiilor din baza de date, până la alerte antivirus după intrarea pe site și o pierdere reală de fonduri. Sună ca o motivație suficientă pentru a avea grijă la asta, nu-i așa?

Să protejăm formularul împotriva spamului și a roboților.

WAF – Web Application Firewall

Pentru a proteja formularul eficient, propun o abordare bazată pe mai multe linii de apărare. Prima linie este de a filtra traficul pe baza regulilor „grase”. Prin urmare, este bine să folosești o găzduire, care oferă protecție WAF (Web Application Firewall). Solicitările sunt filtrate ÎNAINTE de a fi procesate de aplicația ta. În acest fel, te poți proteja de o parte semnificativă a amenințărilor în masă.

Aceste tipuri de mecanisme se bazează pe semnături de atac – de exemplu, cererea conține trăsături specifice, caracteristice privind url-ul țintă, adresa atacatorului, metoda sau conținutul anumitor variabile, care indică destul de clar că cererea este ostilă.

Soluția poate fi instalarea unui script cât mai simplu, pe care îl vei introduce în sursa paginii, înainte de procesarea efectivă a solicitării. Astfel, poți implementa o filtrare a traficului pe baza scripturilor disponibile, dar îți recomand să fii atent aici – orice script introdus în site, dacă ar fi vulnerabil de la sine, ar putea deveni ținta unui atac.

Validare formular conform geo IP

O metodă foarte grosieră și, în același timp, foarte eficientă de filtrare a traficului este blocarea originii geografice a traficului. Poți utiliza baze de date geo IP gratuite și poți determina sursa traficului pe baza adresei IP.

În multe cazuri, vei fi interesat doar de traficul din România sau UE. Prin urmare, poți permite numai traficul, care îndeplinește criteriile geografice pentru procesarea ulterioară. Să ai în vedere faptul că aceasta este o opțiune destul de „puternică” – dacă cineva dorește să folosească formularul tău în timp ce se află într-o vacanță exotică – nu o va putea face!

Amintește-ți să actualizezi bazele de date

Când implementezi protecția formularelor bazată pe adrese IP, nu uita să actualizezi bazele de date în mod regulat. În caz contrar, eficacitatea se va diminua în timp și vei fi expus la un număr tot mai mare de fals pozitive.

Validarea formularului conform listei negre IP

Este posibil să fi auzit despre anumite adrese IP că acestea sunt mai degrabă o sursă „proastă” de trafic. Acestea includ, în principal, adrese care au fost recent abuzate. Merită să blochezi traficul de la astfel de adrese și să nu procesezi datele din formularul, care provine de la acestea.

Poți construi singur liste de IP-uri sau să te bazezi pe cele găsite în rețea. Este foarte important ca aceste liste să fie proaspete. În cazul adreselor IP variabile, este posibil ca astăzi această adresă să fie utilizată de un atacator, iar mâine de un utilizator normal.

Filtrarea pe bază de adrese IP prezintă un alt factor de risc important. Este vorba despre filtrarea eronată a traficului de la roboții de indexare, în special Google Bot. Recunoașterea roboților Google este un subiect, care merită o altă intrare, așa că nu voi detalia aici.

Captcha… adică cum să protejezi formularul împotriva unui robot

Unele, uneori chiar o parte semnificativă a formularelor de pe site-ul tău web, se vor confrunta cu încercări automate de hacking. Ar fi bine să ne putem da seama dacă există un om de „partea cealaltă” sau atacatorul este, pur și simplu, un robot.

Una dintre primele încercări istorice a fost mecanismul captcha, pe care îl cunoști cu siguranță – acesta presupunea ca la sfârșitul formularului (deși din punct de vedere tehnic se putea oriunde) – să răspunzi la o întrebare (cum ar fi, de exemplu, rezultatul unei operații matematice, să complezi propoziția etc.).

De-a lungul timpului, aceste metode s-au dovedit a fi prea ineficiente, iar rescrierea textului dintr-o imagine a devenit populară. Deși omul nu a avut probleme în a citi literele, roboții nu s-au descurcat prea bine… pentru o vreme.

Cum rămâne cu experiența utilizatorului?

Orice activități suplimentare din formular, cum ar fi recunoașterea semnelor rutiere, tigrilor, vitrinelor magazinelor sau cascadelor, precum și rezolvarea unor probleme dificile de matematică – toate acestea fac utilizarea fomularului tău de contact cu adevărat grea pentru utilizator, așa că te sfătuiesc, în mod insistent, să te abții de la astfel de metode. Experiența mea arată că formularul poate fi securizat cu o eficiență satisfăcătoare fără a îngreuna viața utilizatorilor.

Protecția formularelor prin Google reCaptcha

Abordarea Google reCaptcha v2 s-a dovedit a fi o descoperire. Cine nu a dat click pe poze cu vitrine sau indicatoare rutiere? Acest mecanism a fost interesant și adaptabil. Dacă bănuia că există un robot de cealaltă parte, amploarea sarcinilor creștea treptat.

În timp ce eficacitatea acestei protecții poate fi evaluată destul de bine, confortul utilizatorilor a avut, cu siguranță, de suferit de pe urma acesteia. Te-ai distrat marcând semnele rutiere? Nu cunosc pe nimeni căruia i-ar plăcea sa facă acest lucru. Pe Internet se pot găsi informații, că în acest fel am ajutat Google să-și antreneze mecanismele învățării automate, utilizate pentru o mașină automată.

Tehnologia este într-o continuă evoluție astfel că Google ne-a pus la dispoziție Google reCaptcha v3. Este un mecanism complet diferit, practic transparent pentru utilizatorul comun. Prin acest mecanism și prin metodele sale, Google analizează comportamentul utilizatorului pe întregul site și pe această cale îi atribuie utilizatorului o „evaluare” specifică de la 0 la 1.

O evaluare de 1 înseamnă că Google este practic sigur că există un om pe cealaltă parte, 0 înseamnă că este un robot. În majoritatea cazurilor, oamenii, după o perioadă de „antrenament” a mecanismului, sunt punctați între 0,7 și 0,9. În practică, totuși, pe un site web cu trafic mare lunar, după mai multe săptămâni, în multe cazuri oamenii încă primesc doar 0,1 sau 0,3 puncte.

Google reCaptcha v.3 nu blochează nimic de la sine.

În calitate de programator, primești informații despre punctajul acordat și depinde de tine dacă permiți sau nu procesarea formularului. Eu personal am renunțat la acest mecanism, în implementările mele s-a dovedit prea des că un utilizator obișnuit a obținut scorul 0,1 sau 0,3.

Securizarea formularelor create cu extensia honeypot

Un honeypot este practic o momeală, o capcană pusă pentru roboții care completează formularul. Aceste tipuri de roboți, de obicei, nu analizează temeinic câmpurile formularului, ci încearcă să le umple pe toate cu conținut aproape aleatoriu.

Deci, dacă am pregăti un câmp, care este vizibil pentru un robot, dar nu neapărat pentru un om, există șanse mari ca robotul să-l umple și practic șanse zero ca un om să o facă.

Honeypot este, prin urmare, un câmp de formular pe care îl pregătim astfel încât un om să nu-l vadă într-un browser „uman”. Acest lucru se poate face în stiluri CSS, prin plasarea unui astfel de câmp mult dincolo de câmpul vizual uman. Exemple de tehnici, pe care le poți folosi:

  • câmp hidden;
  • proprietate css display: none;
  • proprietate CSS visibility: hidden;
  • poziționare CSS absolută, de ex. deplasare la stânga cu – 2000px;
  • transparenţă;

Completare automată – ce poate merge rău?

Când utilizezi câmpuri honeypot, asigură-te că acestea nu sunt completate automat de browser! Altfel, oamenii vor fi „prinși” în capcană… și nici nu vei ști, pentru că acest câmp nu se vede. Setăm, așadar, proprietatea de completare automată a câmpului formularului la off.

După setarea unui astfel de câmp, există încă o condiție adecvată în cod, ce presupune că, dacă se trece ceva într-o variabilă cu numele câmpului pregătit ca un Honeypot – procesarea ulterioară a formularului nu are loc. În plus, sugerez să adaugi IP-ul pe lista neagră în acest caz.

Cum se protejează formularul împotriva spamului bazat pe CSRF?

CSRF – Cross Site Request Forgery înseamnă falsificarea unei cereri pe un alt site. Prelucrarea formularului se bazează, de obicei, pe faptul că datele din acesta sunt trimise prin metoda POST sau GET la adresa scriptului, care îl poate procesa, ca regulă, pe aceeași pagină. Dacă trimiți o cerere către o altă parte și aceasta nu este protejată, solicitarea poate fi „executată” prin prelucrarea datelor ca și cum ar fi venit de la sine.

Protecția împotriva solicitărilor inițiate de non-utilizator este o parte importantă a securității formularelor. Acest tip de protecție presupune ca formularul să fie procesat doar atunci când știm că a fost completat de utilizatorul site-ului.

Uneori, aceasta este o funcționalitate dorită și gândită ca atare de programator. Cu toate acestea, în opinia mea, este foarte riscant, deoarece deschide calea tuturor roboților, care atacă site-urile web, facilitându-le astfel execuția unor atacuri masive bazate pe seturi de date generate în masă de partea lor și trimise din nou și din nou site-urilor atacate.

Drept urmare, site-ul tău poate fi, de exemplu, inundat de zeci de comentarii false la o postare, trimise într-un minut. În cazul unei intensități mari, ne referim la fenomenul de flood fill, adică completarea în masă a formularului, care arată ca un „potop” de rapoarte.

În acest scop, cel mai bine este să utilizezi mecanismul de sesiune. Utilizatorul de pe pagina de formular are o variabilă aleatorie, să o numim $ csrf, în sesiunea sa. În formular, generăm un câmp de tip hidden cu o valoare egală cu această variabilă:

<? echo ‘<input name=”protection” type=”hidden” value=”‘ . $csrf.”> ;>

Când începem procesarea formularului, verificăm dacă acesta nu transferă deloc valoarea variabilei de securitate și dacă este egală cu cea stocată în sesiune. Dacă vorbim despre comportamentul normal al utilizatorului pe site, acesta va fi întotdeauna egal, deci riscul de fals pozitiv este zero.

Dacă formularul încearcă să fie completat de un robot, eliminând conținutul variabilei cvasialeatoare prin POST sau GET la adresa formularului nostru, mecanismul său primitiv nu va cunoaște valoarea corectă a variabilei de sesiune $ csrf. În consecință, o astfel de cerere ar trebui respinsă.

Cum să protejăm formularul împotriva spamului? Analizăm timpul de completare.

O altă tehnică care merită să fie cunoscută, este protecția ce bazează pe timpul de completare al formularului. Se presupune că utilizatorul „uman” completează formularul în minim 2-3 secunde.

Între timp, atacatorii de formulare încearcă în mod masiv să completeze formularul cu o frecvență extraordinară, de obicei, zeci sau sute de formulare pe minut.

Deci, dacă timpul de completare este suspect de scurt, ar trebui să iei în considerare respingerea acestui tip de formular. Reține, totuși, că atunci când utilizezi completarea automată, timpul poate fi, de fapt, foarte scurt, ceea ce ar duce la un eveniment fals pozitiv.

Cum stabilesc durata limită?

Nu există o regulă de aur pentru a spune ce durată este „bună” ca și criteriu. În cazul meu, un timp de 1-2 secunde a funcționat bine. Depinde, cu siguranță, de complexitatea formularului în sine, de numărul de câmpuri și de scara dificultății. Timpul de completare de către un om este, de asemenea, influențat de câte câmpuri vor fi utilizate de auto-completare sau de UX-ul formularului în sine. Înainte de a implementa protecția ai putea să-ți notezi cât timp ți-a luat completarea formularului. Aplicațiile pentru analizarea comportamentului utilizatorilor pe site-ul web (de exemplu, HotJar, MouseFlow etc.) pot fi, de asemenea, utile.

Protejarea formularului în funcție de informațiile introduse – validare avansată. Exemple.

Cum să protejezi formularul împotriva spamului într-o limbă străină?

Multe spamuri sunt în engleză sau chineză. Dacă conținutul variabilelor este clasificat pentru acest tip de limbaj și nu îți pasă, de exemplu, de comentariile de pe blog în această limbă, poți implementa un sistem de detectare al limbii destul de eficient și pe această bază să iei decizii privind oprirea procesării.

În acest sens, recomand trei abordări, care diferă prin consumul de muncă, versatilitate și rapiditate.

În primul rând: poți construi o listă de cuvinte interzise precum „viagra” etc. Atunci toate trimiterile, care conțin cuvântul dat, vor fi respinse.

În al doilea rând: poți construi liste de codificare a caracterelor pentru a detecta caractere din alte alfabete. Eu, spre exemplu, nu am vrut spam chinezesc pe site-ul meu și am rezolvat problema acestuia folosind o expresie regulată, care detectează caractere chinezești:

preg_match(‘/\p{Han}+/iU’,$string);

În al treilea rând: poți utiliza metode avansate pentru a recunoaște limba, în care au fot introduse datele. Metodele folosite se bazează pe frecvența cuvintelor specifice fiecărei limbi.

Există biblioteci care returnează informații despre o limbă pe baza unui eșantion de text și care pot fi, de asemenea, folosite gratuit.

Securizarea formularului – adresă e-mail validă.

Îți recomand cu căldură validarea e-mailului în trei pași. În primul pas, verifică dacă adresa are sintaxa corectă – adică un „@” urmat de numele domeniului.

În al doilea pas, îți sugerez să verifici dacă domeniul, pe care îl poți „scoate” cu ușurință din adresă, are înregistrări MX. În acest fel, vei putea să identifici adrese complet false în domenii inexistente sau domenii fără o gestionare a e-mailului configurată.

Fiabilitatea e-mailului în securizarea formularului împotriva spamului.

În al treilea pas, îți propun să verifici adresa de e-mail din punct de vedere meritoriu, atât ceea ce este înainte de „@”, cât si după „@”. Este vorba despre surprinderea situațiilor în care avem de-a face cu:

  • o adresă de e-mail temporară;
  • o adresă de e-mail creată printr-un furnizor de servicii de e-mail gratuite;
  • o adresă care conține cuvinte îngrijorătoare în ceea ce privește integritatea;

Mailul deținut de un operator temporar înseamnă că persoana respectivă nu intenționează să citească ceea ce îi trimiți. Ea și-a configurat adresa de e-mail pentru un timp pentru a face click pe linkul de confirmare sau activare. Există sute de domenii populare ale operatorilor temporari. 

Mailul gratuit poate să nu însemne nimic greșit, dar, pe de altă parte, nu este un cont la fel de fiabil ca o adresă din propriul domeniu. Datorită popularității tot mai mari a gmailului gratuit și a miilor de cutii poștale întreținute de onet sau wp, te sfătuiesc să nu respingi acest tip de set de date doar pe baza de mail „gratuit”. În unele aplicații, merită să „semnalizezi” un astfel de set de date pentru o verificare ulterioară.

Ultimul sfat este mai ales pentru mărcile populare. Dacă adresa include, de exemplu, numele unei bănci, al unui mare operator de telecomunicații, al unei companii de curierat etc., atunci poți presupune, cu siguranță, că șansa ca aceasta să fie o adresă reală este mică. Ei bine, cu excepția cazului în care formularul tău este destinat angajaților din sectorul bancar sau al companiilor de curierat. Merită să arunci o privire mai atentă la e-mailurile care conțin astfel de nume de brand. Un exemplu de e-mail este support@paypal-support-center.com. Acesta nu este domeniul oficial al PayPal și poți vedea cu ochiul liber că proprietarul adresei plănuiește să uzurpeze identitatea PayPal.

Securizarea formularului – validarea numelui și prenumelui

Validarea numelui și prenumelui pentru limba română este atât de plăcută încât există o regulă simplă, cu doar câteva excepții. Atâta timp cât formularul tău este destinat românilor, poți presupune cu siguranță că numele care se termină în „-a” sunt feminine, cu doar câteva excepții. Această metodă nu este 100% exactă, deoarece se întâmplă ca în România utilizatorul formularului să folosească o caracteristică a numelui pentru un alt sex.

Securizarea formularului – validarea adresei

Ultima problemă, pe care am vrut să o împărtășesc cu tine, este validarea adresei. Presupun că adresa ta din România este importantă pentru tine. Ceea ce te poate ajuta să obții date de o calitate mai bună este, cu siguranță, o validare bună a codului poștal. Desigur, sintaxa sa este de șase cifre.

Poți găsi cu ușurință o listă de localități pe Internet, astfel încât să poți verifica dacă există un anumit oraș. Desigur, este de asemenea posibil să combini un cod poștal cu un oraș, sau chiar o stradă cu un oraș, pentru a verifica dacă o anumită stradă există într-un anumit oraș.

Aceste metode par să ofere o verificare promițător de precisă, dar eu personal nu le folosesc deoarece apar două complicații:

  1. Sunt slab rezistente la greșelile de scriere în denumirea străzilor;
  2. Necesită actualizarea constantă a bazei de cunoștințe despre străzi, coduri, orașe etc.;

Liste de adrese IP – protecție împotriva roboților și a spamului.

Poate dorești să păstrezi o listă cu ultimele adrese IP de la care au fost trimise datele către formular. Acest lucru îți oferă mai multe opțiuni de protecție. Pentru protecția suplimentară a datelor, este suficient să scrii hash-ul adresei, nu trebuie să fie o adresă explicită. Poți „roti” o astfel de listă. Apoi, în primul pas, vei verifica dacă adresa IP, de la care provine solicitarea, nu se mai află pe listă.

Lista este utilă și pentru blocarea atacurilor „brute-force” și „flood-fill”, pentru a observa, dacă o anumită adresă IP trimite formularul de mai multe ori, într-o perioadă scurtă de timp – cel mai probabil un astfel de IP va fi inclus pe lista neagră.

De asemenea, poți fi tentat să blochezi și să pui pe lista neagră adresele IP atunci când este detectată o solicitare, care conține alte tipuri de amenințări. Un exemplu, în acest sens, pot fi solicitările care conțin încercări de injectare SQL sau XSS, adică injectare de cod, care manipulează baza de date sau plasează / execută un script nedorit.

Dacă dorești să creezi o soluție „ușoară”, poți face această sarcină chiar și fără date. Listele de IP pot fi stocate într-un fișier temporar. Atunci vei avea nevoie de funcții PHP. Poate că vei avea nevoie de funcții precum json_encode () sau serialize (). Cu ele poți transforma o serie de adrese IP și marcaje temporale într-o singură variabilă text. Îl poți scrie și citi cu funcțiile file_put_contents () și file_get_contents ().

La mai mult trafic, probabil că va fi o idee mai bună să folosești o bază de date.

Cum să protejezi formularul? Concluzie.

După ce vei implementa tehnicile descrise aici, spamul va fi doar o amintire neplăcută. Desigur, nicio metodă nu poate oferi o garanție de 100%. Cu toate acestea, pașii pe care i-am descris mai sus mi-au permis să reduc cantitatea de spam din formular cu 90-99%.

După implementarea metodelor menționate mai sus, am obținut o reducere de intrări de spammer lunar făcute de roboții, care atacă formularul, de la câteva mii la maxim câteva pe lună.

Care este experiența ta cu spamul formularelor completate de boți? Te invit să discutăm în comentarii și să distribui postarea pe rețelele sociale.

>
Artur Pajkert
De 20 ani împărtășește cunoștințe și sfaturi despre e-marketing și găzduire în calitate de manager, autor de publicații, speaker, blogger și lector universitar.

Adaugă comentariul

Adresa ta de e-mail nu va fi publicată.

Cauți mai departe?