injection header + codeigniter

Uso la divisione dell'intestazione della risposta HTTP come un esempio qui sotto, ma la soluzione alla fine funziona ugualmente bene quando l'iniezione è nel corpo del contenuto della risposta.

Ad esempio, un attaccante fornisce un input

/
Access-Control-Allow-Origin: evil.org

e quindi il server utilizza tale input per generare intestazioni

response.setHeader("Location", input)

che risulta nelle intestazioni

 Location: /
 Access-Control-Allow-Origin: evil.org

Una soluzione consiste nel controllare attentamente tutto il codice che specifica le intestazioni e assicurarsi che non utilizzi input non filtrati / non attendibili per generare le intestazioni. Questo è soggetto a errori, richiede molto tempo e non è garantito il mantenimento in manutenzione.

Una soluzione più solida è usare metodi di libreria come response.setHeader che rifiutano input che contengono newline. Se response.setHeader ha fatto

 void setHeader(String name, String value) {
   if (!(match(name,  "^[A-Za-z\-]*\z") &&
         match(value, "[^\u0020\u0021-\u0023-\u007f]*"))) {
     throw ...;
   }
   ... 
 }

quindi un utente malintenzionato potrebbe negare il servizio, ma non sarebbe in grado di dividere le intestazioni e i registri conterrebbero tracce che puntano alla chiamata setHeader problematica.

Se utilizzi un framework, spesso puoi avvolgere gli oggetti risposta in modo che i metodi dell'intestazione facciano questo.

Generale. "Convalida l'input prima di utilizzarlo" significa che devi scrivere codice per verificare che l'input sia del modulo previsto (ad es. confrontarlo con una lista bianca) prima di utilizzarlo. Questo è parte della tua responsabilità quando scrivi il codice. Devi farlo ovunque che il tuo codice riceva input da fonti non attendibili.

L'impostazione di flag di configurazione (come la protezione XSS globale o la protezione CSRF) non sostituisce la convalida dell'input prima di utilizzarlo.

Consulta, ad esempio, le linee guida di OWASP per ulteriori informazioni su questo argomento.

Assicurati di leggere anche l'escaping dei valori prima dell'output.

Iniezione di intestazione. controlla il valore rispetto a una whitelist derivata in base al tipo di valore che ti aspetti: ad esempio, ogni carattere nell'input dovrebbe essere in una lista bianca di caratteri consentiti o la stringa di input dovrebbe corrispondere ad alcune regexp accuratamente costruite. Assicurati che la tua lista bianca non includa nessuna nuova riga o altri caratteri di controllo.

Password. Non c'è molta convalida che abbia senso. Potresti voler controllare che la password non contenga alcun '%code%' (nul) byte, proprio come un controllo di integrità. Probabilmente la prima e unica cosa che dovresti fare con una password è immediatamente cancellarla (usando bcrypt, PBKDF2, o scrypt), quindi non guardare mai o usare di nuovo la password cleartext. Fintanto che ti assicuri di seguire quel modello, probabilmente non è necessaria alcuna ulteriore convalida.

Se invii la password via email, controlla che la password non contenga newline o altri caratteri di controllo. Se si inserisce la password in un database, assicurarsi di utilizzare istruzioni preparate SQL per formare la query del database (non utilizzare la concatenazione delle stringhe). Se hai mai visualizzato la password su una pagina web includendola in HTML dinamico (probabilmente una cattiva idea ...), assicurati di eseguire l'escape HTML della password correttamente prima di includerla nell'HTML.