Prevenire l'iniezione di intestazioni email nei moduli di contatto.

Come fa un modulo di contatto PHP a impedire l'inserimento di intestazioni email aggiuntive?

I valori utente non devono mai essere inseriti direttamente nei campi A, Cc, Ccn o nell'intestazione raw. Un contatto di risposta viene validato come un singolo indirizzo e controllato per CR e LF, mentre gli indirizzi fissi del mittente e del destinatario sono definiti nella configurazione; la libreria gestisce la corretta codifica e trasmissione.

Caso d'uso: "Valore Da libero"

Un modulo imposta l'indirizzo email inserito nel campo "Da" tramite concatenazione di stringhe. L'implementazione passa a un mittente con dominio fisso e a un campo "Rispondi a" validato tramite una libreria di posta; i tentativi con interruzioni di riga in Ccn codificate vengono scartati prima dell'invio.

Campo di intestazione rigoroso

1. Identificare tutti i valori della richiesta che possono attualmente influenzare il destinatario, il campo "Da", il campo "Rispondi a", l'oggetto o altre intestazioni.

2. Configurare staticamente destinazioni e mittenti, validare rigorosamente i singoli campi dell'indirizzo e rifiutare CR e LF prima della trasmissione.

3. Passa a una libreria ben mantenuta per l'invio e l'esecuzione di test con interruzioni di riga codificate, indirizzi multipli e valori lunghi.

Gratuito Dal valore

• Gratuito Dal valore – L'indirizzo del modulo viene utilizzato come indirizzo del mittente non elaborato e consente l'aggiunta di intestazioni o non viene inviato correttamente a causa delle policy di invio.

• Bypass dell'interruzione di riga – I filtri incompleti riconoscono solo le rappresentazioni CR e LF, mentre la decodifica o i valori multipli creano successivamente nuove intestazioni.

• Messaggio come intestazione – L'oggetto o il testo libero vengono scritti nella struttura dell'intestazione tramite concatenazione e non separano nettamente il contenuto dai metadati.

Indirizzi di destinazione fissi

• Indirizzi di destinazione fissi – Il destinatario e il valore tecnico provengono da una configurazione protetta e non possono essere influenzati tramite i campi della richiesta.

• Campo di intestazione rigoroso – Un campo "Rispondi a" facoltativo viene verificato come un solo indirizzo valido e rifiuta tutti i caratteri CR o LF.

• Invio basato su libreria – Un componente di posta ben gestito genera intestazioni e strutture MIME anziché stringhe generate manualmente con escape non chiari.

Invio basato su libreria

• Numero di campi di intestazione configurabili dall'utente e percentuale di percorsi di invio con destinatari fissi e codifica basata su libreria.

• Rifiuta i valori di indirizzo con interruzioni di riga, destinazioni multiple o formati non validi senza generare un messaggio.

Come "Prevenire l'iniezione di intestazioni di email" si collega ad altri argomenti

Separa "Prevenire l'iniezione di intestazioni di email" Padronanza dei percorsi relativi e assoluti nei progetti annidati. Un'importante domanda di approfondimento: Come si impedisce che gli include PHP in directory annidate utilizzino improvvisamente percorsi errati?

Chi desidera approfondire "Prevenire l'iniezione di intestazioni di email" dal punto di vista del cluster "Hosting, Server, CDN e Caching" troverà ulteriori informazioni in Configurare in modo sicuro i reverse proxy per i servizi interni. la classificazione appropriata.

Se si desidera implementare concretamente "Prevenire l'iniezione di intestazioni di email", è possibile fare riferimento a Sistemi web robusti Questo si concentra su "Input dei moduli ed elaborazione sicura" e "Indirizzi di destinazione fissi".

Conclusione: Prevenire l'iniezione di intestazioni di posta elettronica

L'iniezione di intestazioni viene impedita al confine di fiducia, non tramite successive manipolazioni del testo. Destinazioni fisse, indirizzi individuali rigorosamente definiti e una libreria di posta elettronica impediscono l'inserimento di dati utente nella struttura.

Fonti e ulteriori informazioni

Queste fonti primarie sono autorevoli per quanto riguarda il comportamento della piattaforma, la terminologia e i limiti di validazione relativi alla "prevenzione dell'iniezione di intestazioni di posta elettronica".

• Foglio riassuntivo sulla validazione dell'input — OWASPOWASP raccomanda regole di allowlisting contestualizzate, limiti di lunghezza e validazione lato server per input non attendibili.

• mail — Manuale PHPIl manuale PHP avverte esplicitamente di non includere dati esterni non verificati in intestazioni di posta elettronica aggiuntive.

• RFC 5322: Formato dei messaggi InternetLo standard IETF definisce la struttura, i campi e i limiti di riga dei messaggi Internet, e quindi la struttura che può essere sfruttata tramite l'iniezione di intestazioni.