Ogni sito web aziendale ha un modulo di contatto. E il modo piu semplice per i potenziali clienti di raggiungervi. E anche, in molti casi, il modo piu semplice per gli attaccanti di raggiungere il vostro server.
Un modulo di contatto e un'interfaccia tra il mondo esterno e la vostra applicazione web. Accetta input da chiunque su internet e lo passa al vostro server per l'elaborazione. Se quell'input non viene validato e sanitizzato correttamente, il modulo diventa un vettore di attacco. E la maggior parte dei moduli di contatto che verifichiamo sui siti web aziendali svizzeri non e adeguatamente protetta.
Come i Moduli Diventano Vettori di Attacco
Un modulo web raccoglie dati e li invia al server. Il server poi fa qualcosa con quei dati: li memorizza in un database, li invia via email, li scrive su un file o li passa a un altro servizio. Ognuna di queste operazioni puo essere sfruttata se i dati non vengono gestiti correttamente.
Il problema fondamentale e la fiducia. Se la vostra applicazione si fida che i dati provenienti da un modulo siano sicuri e ben formattati, un attaccante inviera dati che non sono ne sicuri ne ben formattati.
La Validazione Lato Client Non e Sicurezza
Molti sviluppatori (e molte web agency in Ticino) implementano la validazione dei moduli solo nel browser tramite JavaScript. Questo offre una buona esperienza utente, ma zero sicurezza. Un attaccante puo aggirare la validazione lato client disabilitando JavaScript, usando strumenti come curl o Burp Suite per inviare richieste direttamente al server, o modificando il codice sorgente della pagina.
La validazione lato client serve all'usabilita. La validazione lato server serve alla sicurezza. Servono entrambe.
SQL Injection Attraverso i Campi del Modulo
L'SQL injection avviene quando l'input del modulo viene inserito direttamente in una query SQL del database senza parametrizzazione.
Come Funziona
Il vostro modulo di contatto ha campi: nome, email, messaggio. Quando il modulo viene inviato, il server potrebbe memorizzare i dati con una query come:
INSERT INTO contacts (name, email, message) VALUES ('$name', '$email', '$message')
Se un attaccante invia un valore appositamente costruito come nome:
'); DROP TABLE contacts; --
Il database esegue due comandi: un insert e un DROP TABLE che cancella l'intera tabella dei contatti.
Cosa Puo Fare un Attaccante con SQLi
- Leggere l'intero database: dati clienti, credenziali utente, ordini, note interne
- Modificare dati: cambiare password admin, alterare record
- Eliminare dati: eliminare tabelle, troncare record
- In alcune configurazioni, leggere o scrivere file sul filesystem del server
- In casi estremi, eseguire comandi del sistema operativo
La Soluzione
Usare query parametrizzate (prepared statements). Ogni linguaggio di programmazione moderno e driver di database li supporta.
Cross-Site Scripting (XSS) Tramite Campi di Input
L'XSS attraverso i moduli funziona quando i dati inviati dall'utente vengono visualizzati su una pagina senza una codifica corretta. Se qualcuno invia codice JavaScript attraverso il vostro modulo di contatto e quell'invio viene poi visualizzato (in un pannello admin, una sezione commenti pubblica o una pagina di conferma), lo script si esegue nel browser di chiunque lo visualizzi.
XSS Persistente Attraverso i Moduli di Contatto
Scenario: il vostro modulo memorizza gli invii in un database. Quando voi o il vostro team visualizzate gli invii nel pannello admin, un attaccante invia del codice JavaScript nel campo nome. Quando un admin visualizza questo invio, il suo browser esegue lo script, che invia il cookie di sessione all'attaccante. L'attaccante ora ha la sessione dell'admin e puo accedere al vostro CMS come amministratore.
La Soluzione
Codifica dell'output. Ogni volta che visualizzate dati inviati dall'utente, codificate i caratteri speciali HTML. Implementate anche un header Content-Security-Policy (CSP) che limita l'esecuzione degli script. Vedete la nostra guida sulle vulnerabilita OWASP Top 10.
Vulnerabilita di Upload File nei Campi Allegati
Molti moduli di contatto permettono allegati: upload di CV in moduli di candidatura, upload di documenti in moduli di supporto. L'upload di file e una delle funzionalita a piu alto rischio su qualsiasi sito web.
L'Attacco
Un attaccante carica un file PHP (o qualsiasi script lato server) mascherato da immagine o documento. Tecniche di bypass comuni:
- Doppia estensione:
malware.php.jpg - Spoofing MIME type: Impostare il Content-Type come
image/jpegcaricando un file PHP. - Iniezione di byte null:
malware.php%00.jpg - Manipolazione maiuscole/minuscole:
malware.PhP - Upload di .htaccess: Caricare un file .htaccess che riconfigura il server.
La Soluzione
- Validare il contenuto del file, non solo estensioni o MIME type
- Memorizzare i file caricati fuori dalla web root
- Rinominare i file con nomi casuali (UUID)
- Impostare limiti di dimensione rigorosi
- Usare una whitelist di tipi consentiti
- Servire i file attraverso un dominio separato o script di download
Cross-Site Request Forgery (CSRF)
Il CSRF inganna un utente facendogli inviare un modulo che non intendeva inviare. Se il vostro admin e loggato nel CMS e visita una pagina malevola, quella pagina puo attivare un invio di modulo al vostro sito usando la sessione dell'admin.
La Soluzione
Token CSRF. Ogni modulo sul vostro sito dovrebbe includere un token unico e casuale che il server genera e verifica. Impostate anche l'attributo SameSite sui cookie di sessione.
Email Header Injection
La maggior parte dei moduli di contatto invia i dati via email. Se gli header email sono costruiti usando input del modulo non validato, un attaccante puo iniettare header aggiuntivi.
L'Attacco
L'attaccante inserisce nel campo email:
attacker@example.com%0ABcc:vittima1@example.com,vittima2@example.com
Il %0A e un carattere di nuova riga. Il vostro server ora invia l'email non solo a voi ma a centinaia di indirizzi. Il vostro server diventa un relay di spam.
Conseguenze
- Il vostro mail server viene inserito nelle blacklist per invio di spam
- La deliverability email cala. Le email aziendali legittime finiscono nello spam
- La reputazione del dominio e danneggiata, influenzando anche il SEO del sito
- Il vostro indirizzo IP puo finire nelle RBL, da cui e difficile farsi rimuovere
La Soluzione
Non usare mai input del modulo direttamente negli header email. Usare librerie email (PHPMailer, SwiftMailer, Nodemailer) invece della funzione mail() grezza.
Server-Side Request Forgery (SSRF) Attraverso Campi URL
Se il vostro modulo accetta URL, un attaccante puo inviare URL che puntano a risorse interne invece che a siti web esterni. Validare e limitare gli input URL. Bloccare gli intervalli IP privati.
Spam e Abuso Automatizzato
CAPTCHA vs. Honeypot
CAPTCHA (come reCAPTCHA o hCaptcha) aggiunge una sfida che i bot non possono risolvere facilmente. Funziona ma aggiunge attrito all'esperienza utente.
Campi honeypot sono campi nascosti che gli utenti umani non vedono mai. I bot che compilano ogni campo riempiranno l'honeypot, e il server rifiuta gli invii dove il campo honeypot non e vuoto.
Best practice: usare entrambi. Un campo honeypot per i bot semplici e un CAPTCHA per quelli sofisticati.
Rate Limiting
Limitare il numero di invii del modulo da un singolo indirizzo IP. Per esempio: massimo 5 invii per IP all'ora.
Come Testare i Vostri Moduli in Sicurezza
Test per XSS
In ogni campo del modulo, provate a inviare: <script>alert('test')</script>. Se vedete un popup JavaScript, il modulo e vulnerabile.
Test per Email Header Injection
Nel campo email, inviate: test@example.com%0ABcc:test2@example.com. Se il sistema invia l'email a entrambi gli indirizzi, avete una vulnerabilita.
Test per SQLi Base
In un campo testo, inviate: test' OR '1'='1. Se vedete un messaggio di errore che menziona SQL, il modulo potrebbe essere vulnerabile.
Test per Upload File
Se il modulo ha un campo di upload, provate a caricare un file con estensione .php. Se l'upload riesce e il server esegue il PHP, avete una vulnerabilita di upload file.
Questi sono test di base. Per una valutazione professionale dei moduli del vostro sito web, contattate il nostro team.
Sicurezza dei Moduli: Checklist Completa
| Misura di Sicurezza | Cosa Previene | Implementazione |
|---|---|---|
| Validazione input lato server | Tutti gli attacchi injection | Validare tipo, lunghezza, formato e caratteri consentiti |
| Query parametrizzate | SQL injection | Prepared statements per tutte le interazioni con il database |
| Codifica output | XSS | Codificare in HTML tutti i dati utente prima della visualizzazione |
| Token CSRF | Cross-site request forgery | Includere e verificare token unici in ogni modulo |
| Validazione upload file | Esecuzione codice remoto | Whitelist tipi, validare contenuto, memorizzare fuori dalla webroot |
| Sanitizzazione header email | Email header injection | Usare librerie email, eliminare newline dagli header |
| Rate limiting | Spam, brute force | Limitare invii per IP per periodo |
| CAPTCHA o honeypot | Spam automatizzato | reCAPTCHA, hCaptcha o tecnica campo nascosto |
| Header Content-Security-Policy | XSS (difesa in profondita) | Limitare le origini di esecuzione script |
Per il quadro completo degli header di sicurezza HTTP, vedete la nostra guida sugli header di sicurezza che ogni sito web necessita.
Esempi Reali da Aziende del Ticino
Caso 1: Un'Agenzia di Reclutamento
Un'agenzia di reclutamento in Ticino aveva un modulo di candidatura che accettava upload di CV. La validazione dell'upload controllava solo l'estensione lato client. Un attaccante ha caricato una web shell PHP con estensione .pdf.php. La web shell ha permesso l'accesso al database contenente informazioni personali dei candidati.
Caso 2: Un'Attivita Ricettiva
Il modulo di prenotazione di un hotel non aveva protezione CSRF. Un attaccante ha modificato i record di prenotazione e reindirizzato le email di conferma. Gli ospiti hanno ricevuto email di conferma false con dettagli di pagamento diversi.
Caso 3: Una Societa di Consulenza
Il modulo di contatto di una societa di consulenza aveva email header injection. Gli spammer lo hanno usato per inviare oltre 50.000 email di spam attraverso il server di posta dell'azienda in un singolo fine settimana. Il server e stato inserito nelle blacklist su piu RBL. Ci sono volute tre settimane per la rimozione.
Cosa Dovreste Fare Ora
- Verificate i vostri moduli. Eseguite i test base descritti sopra.
- Chiedete al vostro sviluppatore o agenzia: "I nostri input dei moduli sono validati lato server? Usiamo query parametrizzate? I nostri moduli hanno token CSRF? L'upload dei file e sicuro?"
- Implementate security headers. CSP in particolare fornisce difesa in profondita contro XSS.
- Richiedete una valutazione professionale. Contattate il nostro team per un assessment di sicurezza completo.
Il vostro modulo di contatto serve a connettervi con i clienti. Assicuratevi che non vi stia anche connettendo con gli attaccanti.
Vuoi sapere se il tuo sito è sicuro?
Richiedi un audit di sicurezza gratuito. In 48 ore ricevi un report completo.
Richiedi Audit Gratuito