Torna al Diario
SicurezzaNº 00907 luglio 20266 min

L'attacco che nessuno vede arriva dal modulo di contatto del tuo sito

Il modulo di contatto sembra innocuo. È la porta più spalancata che hai, e quasi nessuno la chiude a chiave.

Tutti proteggono il login. Nessuno guarda il modulo di contatto. Eppure accetta input da chiunque, senza autenticazione, senza attrito, spesso senza nemmeno un limite di invii.

È questa l'asimmetria che l'attaccante cerca. Una casella di testo che parla con il tuo server di posta, con il tuo database o con un webhook interno. Tu vedi un campo "messaggio". Lui vede una riga di comando.

Perché questo bersaglio è così allettante

Un modulo di contatto riunisce tre proprietà rare nello stesso posto. Accetta input non fidato. Esegue logica sul server. E quasi mai viene sottoposto a controllo. Lo sviluppatore ha verificato che il messaggio arriva in casella. Si è fermato lì.

Il problema è che "il messaggio arriva in casella" nasconde un intero percorso. Il testo dell'utente viene assemblato dentro un'intestazione SMTP, concatenato in una query o inviato a un servizio terzo. Ognuno di questi confini è un'occasione di iniezione.

Iniezione di intestazioni email

Il caso classico si chiama email header injection. Se prendi il campo "oggetto" o "mittente" e lo incolli direttamente nell'intestazione del messaggio, un attaccante inserisce un ritorno a capo e aggiunge le proprie intestazioni. Un Bcc verso mille indirizzi, ad esempio.

All'improvviso il tuo server sta inviando spam. Non a tuo nome per caso, ma letteralmente attraverso la tua infrastruttura, con il tuo IP e il tuo dominio. Il risultato è prevedibile: i grandi provider segnalano il tuo dominio come fonte di spam e le email della tua azienda smettono di arrivare ovunque.

Il testo che diventa codice

Poi ci sono gli scenari peggiori. Se salvi il messaggio in un database senza parametrizzare la query, apri la porta alla SQL injection. Se mostri il messaggio in un pannello di amministrazione senza fare escaping dell'HTML, l'attaccante pianta uno script che gira nel browser del tuo team quando apre il lead. Questo è XSS memorizzato, ed è tra i vettori più sottovalutati che esistano.

Nota lo schema. In nessuno di questi casi l'attaccante ha "violato" qualcosa. Ha usato il modulo esattamente come è progettato per essere usato. La vulnerabilità non è una falla esotica. È l'assenza di una regola semplice: non fidarti mai di ciò che entra.

Cosa fare, in ordine di priorità

Non ti serve un WAF né un consulente di sicurezza per chiudere il 90% di questo. Ti serve disciplina su quattro punti.

  • Valida sul server, mai solo nel browser. La validazione front-end è comodità per l'utente, non è sicurezza. L'attaccante non usa il tuo modulo, fa POST diretto all'endpoint.
  • Fai escaping in output, sempre. Quando salvi nel database usa query parametrizzate. Quando mostri in un pannello fai escaping dell'HTML. Tratta ogni messaggio come ostile fino a prova contraria.
  • Rifiuta i ritorni a capo nei campi di intestazione. Oggetto, nome ed email non hanno motivo di contenere \r o \n. Filtrali prima di toccare l'SMTP.
  • Limita la frequenza degli invii e aggiungi una sfida invisibile. Rate limiting per IP e un honeypot o hCaptcha fermano i bot automatici senza rovinare l'esperienza di chi è umano.

E il lato che quasi tutti dimenticano

Un modulo di contatto raccoglie dati personali. Nome, email, spesso telefono e il contenuto del messaggio. Questo ti mette dentro il GDPR, che ti piaccia o no. Ti serve una base giuridica per trattare quei dati, e il consenso deve essere informato.

In pratica significa tre cose concrete. Una nota chiara sulla privacy collegata al modulo. Una base giuridica definita, tipicamente il legittimo interesse dell'articolo 6 o il consenso esplicito. E una politica di conservazione, perché tenere i lead per sempre non è una strategia, è una responsabilità che si accumula. Se ti rubano il database dei lead, il problema smette di essere tecnico e diventa normativo.

La sicurezza di un modulo non è un firewall costoso. È rifiutarti di fidarti del testo che uno sconosciuto ha scritto.Krivar Diário

La morale è noiosa, ed è per questo che funziona. L'attacco che nessuno vede arriva dalla porta che nessuno guarda. Tratta il tuo modulo di contatto con lo stesso rispetto che dai al login e la maggior parte di questi problemi non si presenterà mai.

Fonti
  1. 01OWASP — Injection
  2. 02OWASP — Cross Site Scripting (XSS)
  3. 03MDN — Validazione dell'input
  4. 04GDPR.eu — Articolo 6: Liceità del trattamento
  5. 05OWASP Cheat Sheet — Prevenzione della SQL Injection
Anche:
SicurezzaNº 004

Come un certificato SSL scaduto ha tolto il tuo negozio da Google in 48 ore

Un certificato scade un mercoledì alle 03:14. Venerdì mattina il traffico organico è crollato. Non è stata sfortuna, è stata negligenza misurabile.

SicurezzaNº 002

HTTPS non è più una feature. È baseline.

Nel 2026, qualsiasi sito senza certificato SSL sta dicendo al visitatore di andarsene — e il browser tiene a sottolinearlo.

Torna al Diario