Zilele trecute, liniștea dashboard-urilor mele a fost spartă de o alertă pe care niciun proprietar de site nu vrea să o vadă: un vârf de trafic absolut aberant. Peste 63.000 de request-uri aruncate înspre serverul meu într-o fereastră de timp extrem de scurtă, dintre care aproape 4.000 de interogări de tip POST direct în formularul de contact.
Am activat imediat modul „I’m Under Attack” din Cloudflare și m-am așezat să privesc logurile, pregătit să scot „artileria grea”. Dar, pe măsură ce analizam datele, adrenalina s-a transformat rapid într-un zâmbet ironic.
Nu aveam de-a face cu un sindicat de criminalitate cibernetică. Aveam de-a face, cel mai probabil, cu un coleg de breaslă invidios sau cu un „script kiddie” care abia a descoperit versiunea gratuită de Burp Suite și a decis să apese butonul de Automated Scan pe domeniul meu.
„Hackerul” cu unelte de-a gata
Să ne înțelegem: nu e nicio glorie în a lua o unealtă de penetrare de pe internet și a lansa orbește mii de payload-uri predefinite (de la Oastify la Burp Collaborator) sperând să pice ceva. În logurile mele de Nginx și în statisticile din Umami, vedeam cum scriptul acestui individ arunca disperat cu tot ce avea prin buzunare: SQL Injections (Time-Based), Path Traversals (../../windows/win.ini), încercări de execuție de comenzi în terminal și un bombardament de Cross-Site Scripting (XSS) care polua URL-urile cu apostrofuri și tag-uri sparte.
Totul rula automatizat, de pe o conexiune fixă dintr-un oraș de provincie. E o ironie tristă aici. Într-o industrie în care ar trebui să fim uniți, să construim soluții și să educăm piața, unii aleg să își consume timpul și curentul electric încercând să dărâme munca altora. Prietene, dacă citești asta: logica din spatele aplicației mele a luat injecțiile tale malițioase, le-a tratat ca pe un text inofensiv și mi le-a trimis cuminte pe mail. Nu mi-ai spart serverul, doar mi-ai umplut inbox-ul de spam.
Experimentul mental: Ce s-ar fi întâmplat dacă aveam un WordPress vulnerabil?
Acest incident m-a făcut să mă gândesc la clienții care nu înțeleg de ce un site „costă atât” sau de ce insist pe soluții scrise de la zero (cod custom/framework-uri solide) în detrimentul temelor cumpărate la reducere.
Imaginați-vă că acest atac de peste 60.000 de request-uri ar fi lovit un site de prezentare sau un magazin online făcut pe un WordPress neactualizat de doi ani, plin de plugin-uri dubioase.
La SQL Injection: Baza de date ar fi cedat, expunând adresele de email, parolele și datele personale ale clienților.
La Path Traversal: Atacatorul ar fi citit fișierele de configurare ale serverului.
La volumul de trafic: Serverul ar fi intrat în colaps (Eroare 500 sau 502), iar afacerea ar fi fost offline cu orele.
Dar pe o arhitectură curată, cu un framework modern pe backend, lucrurile stau altfel. Există protecție nativă CSRF (care respinge request-urile false automat), interogările către baza de date folosesc prepared statements (care fac injecțiile SQL imposibile), iar traficul „murdar” este filtrat elegant de un WAF (Web Application Firewall) precum Cloudflare. Nu trebuie să fii un geniu ca developer; trebuie doar să nu tai colțuri, să îți faci treaba cu responsabilitate și să folosești arhitectura corectă.
Regula de aur pentru orice antreprenor care vrea un site
Dacă ești în poziția de a contracta un dezvoltator web, nu îl întreba doar „Cât de repede e gata?” sau „Poți să faci butonul ăsta mai mare?”. Siguranța datelor tale și ale clienților tăi nu este un modul opțional pe care îl adaugi mai târziu.
Trebuie să pui întrebări incomode:
„Cum îmi protejezi baza de date de atacuri automate?”
„Ce se întâmplă dacă cineva rulează un scanner de vulnerabilități pe formularele mele?”
„Folosim un WAF (gen Cloudflare) pentru a bloca traficul malițios înainte să atingă serverul?”
Ca developer, jobul tău nu este doar să scrii niște ecrane care arată bine pe telefon. Jobul tău este să construiești o fortăreață digitală. Clientul tău trebuie să doarmă liniștit noaptea, știind că dacă vreun „hacker de duminică” decide să își verse frustrările pe serverul lui, tot ce va reuși să genereze va fi un log plin de coduri HTTP 403 (Forbidden) și 422 (Unprocessable Entity).
În rest, pentru atacatorul meu anonim: mulțumesc pentru testul gratuit de stres. Funcționează perfect.
