În ultimii ani, atacurile asupra magazinelor online au devenit tot mai sofisticate. Dacă în trecut administratorii se confruntau în principal cu atacuri DDoS clasice sau tentative de compromitere a conturilor, în anul 2026 observăm o creștere semnificativă a atacurilor HTTP care exploatează funcționalități legitime ale platformelor eCommerce.
Recent, am intervenit pentru mitigarea unui incident care afecta un magazin online PrestaShop găzduit în infrastructura noastră. La prima vedere părea un atac distribuit clasic, însă analiza logurilor Apache a scos la iveală ceva mult mai interesant: mii de crawlere automate accesau combinații aproape infinite de filtre generate de magazin.
Acest tip de atac este periculos deoarece poate genera un consum ridicat de resurse chiar și pe servere performante, fără a produce neapărat un volum impresionant de trafic. În multe cazuri, administratorii observă doar creșterea bruscă a load-ului și degradarea performanței magazinului.
Ce este un atac HTTP asupra unui magazin PrestaShop
Un atac HTTP nu urmărește saturarea conexiunii la internet, ci consumarea resurselor aplicației. Atacatorii sau crawlerele automate trimit cereri aparent legitime către pagini care necesită procesare PHP, acces la baza de date și generarea dinamică a conținutului.
În cazul analizat, magazinul folosea un sistem de filtre pentru produse. Aceste filtre generau URL-uri complexe care combinau diferite caracteristici precum numărul de nuclee, tipul procesorului, socket-ul și memoria cache.
Un exemplu real din log arăta astfel:
138.226.100.xxx - - [11/Jun/2026:01:58:58 +0300] "GET /25-procesoare/s-10/memorie_cache-1375_mb+45_mb+22_mb+2475_mb+8_mb+15_mb+25_mb+30_mb+35_mb+825_mb HTTP/2.0" 200 19990 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36"
La prima vedere, cererea pare normală: folosește metoda GET, un User-Agent de browser real și accesează o pagină a magazinului. Problema este că URL-ul conține o combinație foarte lungă de filtre, iar astfel de cereri erau repetate de mii de ori de pe adrese IP diferite. Fiecare combinație obliga PrestaShop să genereze dinamic o pagină nouă și să execute interogări suplimentare în baza de date.
Cum am identificat problema
Inițial, monitorizarea serverului indica un număr mare de conexiuni HTTP și creșterea consumului de CPU. Analiza logurilor Apache a evidențiat zeci de mii de accesări către URL-uri generate automat.
Majoritatea solicitărilor aveau structuri similare:
- memorie_cache
- tip_procesor
- nuclee_procesor
- socket-lga
La prima vedere părea trafic legitim. Totuși, investigarea mai detaliată a arătat că mii de IP-uri diferite accesau combinații unice de filtre într-un ritm constant.
În timpul investigației am identificat inclusiv subneturi care generau individual peste 50.000 de accesări într-un interval relativ scurt, toate urmărind același model de accesare.
De ce aceste URL-uri sunt periculoase pentru PrestaShop
Platforma PrestaShop generează conținut dinamic pentru fiecare combinație de filtre. Chiar dacă pagina este accesată o singură dată, aplicația trebuie să proceseze cererea, să execute interogări SQL și să construiască rezultatul.
Atunci când crawlerele generează mii sau zeci de mii de combinații diferite, avantajele cache-ului dispar aproape complet deoarece fiecare URL este nou.
Practic, serverul este forțat să genereze permanent conținut nou, ceea ce duce la creșterea consumului de CPU, RAM și resurse MySQL.
În multe situații, impactul nu este observat imediat. Magazinul continuă să funcționeze, însă timpul de răspuns crește, comenzile sunt procesate mai lent, iar experiența utilizatorilor reali începe să se degradeze.
De ce nu a fost un atac DDoS clasic
În cazul unui atac DDoS volumetric, același URL este accesat de foarte multe ori pentru a consuma lățimea de bandă sau conexiunile disponibile.
În acest caz, fiecare crawler accesa URL-uri diferite. Numărul de request-uri per IP era relativ redus, însă numărul total de combinații era uriaș.
Acesta este motivul pentru care multe soluții automate de protecție nu detectează imediat problema. Din punct de vedere tehnic, fiecare solicitare părea legitimă.
În realitate, efectul cumulat asupra aplicației era semnificativ mai mare decât în cazul multor atacuri clasice.
Analiza logurilor Apache
Verificarea logurilor a evidențiat zeci de mii de request-uri provenite din mai multe subneturi diferite. Majoritatea foloseau User-Agent-uri care imitau browsere Chrome moderne.
Acest lucru este frecvent în atacurile HTTP deoarece multe sisteme de protecție filtrează doar boții identificați explicit.
Toate solicitările vizau pagini de filtrare complexe și nu homepage-ul sau paginile standard ale magazinului.
Mai mult, fiecare accesare genera o combinație nouă de filtre, ceea ce reducea eficiența mecanismelor de cache și obliga aplicația să proceseze permanent conținut nou.
Măsurile de mitigare implementate
Pentru blocarea rapidă a traficului am analizat mai întâi logurile Apache și am identificat un tipar comun în majoritatea solicitărilor automate. Deși IP-urile proveneau din subneturi diferite și foloseau User-Agent-uri care imitau browsere reale, toate accesau URL-uri generate de sistemul de filtrare al magazinului.
Deoarece blocarea individuală a adreselor IP nu ar fi rezolvat problema pe termen lung, am ales o abordare mai eficientă: filtrarea directă a URL-urilor care generau consum excesiv de resurse.
Regula implementată a fost:
RedirectMatch 403 (?i).*(memorie_cache|tip_procesor|nuclee_procesor|socket-lga|socket-).*
Această regulă a fost aplicată la nivel de VirtualHost Apache utilizând sistemul userdata disponibil în cPanel/WHM. Astfel, configurația este păstrată chiar și după regenerarea automată a fișierului httpd.conf.
Avantajul acestei metode este că solicitările sunt respinse imediat cu codul HTTP 403 Forbidden, fără a mai ajunge să genereze procesare inutilă în PrestaShop, PHP sau MySQL.
Testarea a confirmat eficiența măsurii. Înainte de implementare, URL-urile generate de filtre răspundeau cu cod HTTP 200 și erau procesate integral de aplicație. După activarea regulii, aceleași URL-uri au început să returneze imediat codul HTTP 403 Forbidden.
După implementare, monitorizarea logurilor a confirmat eficiența măsurii. În doar câteva minute, peste 1.500 de solicitări automate au fost blocate cu succes, iar load-ul serverului a revenit la valori normale.
Un aspect important este că nu am blocat un anumit IP sau o anumită țară. Atacul provenea de la mii de adrese IP diferite, însă toate urmăreau același tipar de accesare. Prin blocarea URL-urilor problematice am eliminat cauza consumului ridicat de resurse, nu doar simptomele.
Rezultatele obținute după blocare
La scurt timp după implementarea regulilor de protecție, load-ul serverului a revenit la valori normale.
Monitorizarea logurilor a confirmat că peste 1.500 de request-uri suspecte au fost blocate în primele minute după activarea regulilor.
În același timp, utilizatorii legitimi au continuat să utilizeze magazinul fără probleme.
Această abordare a permis mitigarea atacului fără a afecta experiența clienților reali și fără a fi necesară blocarea unor țări sau intervale mari de adrese IP.
Cum poți proteja un magazin PrestaShop împotriva atacurilor HTTP
Primul pas este monitorizarea permanentă a logurilor web. Multe atacuri nu sunt evidente și pot fi confundate cu trafic normal.
Este recomandată limitarea combinațiilor de filtre indexabile și evitarea generării unui număr foarte mare de URL-uri unice.
De asemenea, dezvoltatorii ar trebui să analizeze atent modul în care funcționează filtrele și să elimine combinațiile care nu aduc valoare utilizatorilor sau motoarelor de căutare.
Pentru magazinele cu trafic ridicat, utilizarea unei infrastructuri moderne de găzduire web cu LiteSpeed, Redis, NVMe, MariaDB optimizat și protecție avansată poate reduce semnificativ impactul unor astfel de atacuri.
La NameBox monitorizăm constant astfel de situații și intervenim rapid atunci când identificăm comportamente anormale în logurile Apache, LiteSpeed sau Nginx.
De ce atacurile HTTP vor deveni mai frecvente în 2026
Instrumentele automate bazate pe inteligență artificială permit generarea rapidă a milioane de URL-uri diferite. Acest lucru transformă atacurile de tip crawl și faceted search abuse într-o problemă tot mai comună pentru magazinele online.
Nu este întotdeauna nevoie de un botnet uriaș pentru a provoca probleme unui magazin online. Uneori este suficientă exploatarea unor funcționalități legitime, precum sistemele de filtrare, pentru a genera un volum mare de procesare la nivelul aplicației și al bazei de date.
Tocmai din acest motiv, monitorizarea logurilor, optimizarea URL-urilor generate de filtre și utilizarea unei infrastructuri de găzduire performante devin elemente esențiale pentru securitatea unui magazin PrestaShop modern.