inyección de cabecera + codeigniter

Uso la división del encabezado de respuesta HTTP como un ejemplo a continuación, pero la solución al final funciona igual de bien cuando la inyección está en el cuerpo del contenido de la respuesta.

Por ejemplo, un atacante proporciona una entrada

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

y luego el servidor usa esa entrada para generar encabezados

response.setHeader("Location", input)

lo que resulta en los encabezados

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

Una solución es verificar con cuidado todo el código que especifica los encabezados y asegurarse de que no use entradas sin filtro / que no sean de confianza para generar los encabezados. Esto es propenso a errores, consume mucho tiempo y no se garantiza que se mantenga durante el mantenimiento.

Una solución más robusta es usar métodos de biblioteca como response.setHeader que rechazan entradas que contienen nuevas líneas. Si response.setHeader hiciera

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

entonces un atacante podría negar el servicio, pero no podría dividir los encabezados, y sus registros contendrían rastros que apuntan a la llamada problemática setHeader .

Si está utilizando un marco, a menudo puede envolver sus objetos de respuesta para que los métodos de encabezado hagan esto.

General. "Validar entrada antes de usarla" significa que debe escribir un código para verificar que la entrada tenga la forma esperada (por ejemplo, verificarla en una lista blanca) antes de usarla. Esto es parte de su responsabilidad al escribir el código. Debe hacer esto en cualquier lugar que su código reciba entradas de fuentes no confiables.

La configuración de marcas de configuración (como la protección XSS global o la protección CSRF) no reemplaza la validación de la entrada antes de usarla.

Consulte, por ejemplo, las pautas de OWASP para obtener mucha más información sobre este tema.

Asegúrese de leer también sobre el escape de valores antes de la salida.

Inyección de encabezado. Compare el valor con una lista blanca derivada según el tipo de valor que espera: por ejemplo, cada carácter de la entrada debe estar en una determinada lista blanca de caracteres permitidos, o la cadena de entrada debe coincidir con alguna expresión regular cuidadosamente construida. Asegúrese de que su lista blanca no incluya nuevas líneas ni otros caracteres de control.

Contraseñas. No hay mucha validación que tenga sentido. Es posible que desee verificar que la contraseña no contenga ningún '%code%' (nul) bytes, solo como una comprobación de validez. Probablemente, lo primero y lo único que debe hacer con una contraseña es hacer un hash inmediatamente (usando bcrypt, PBKDF2 o scrypt), y luego nunca vuelva a mirar o usar la contraseña de cleartext. Siempre que se asegure de seguir ese patrón, probablemente no se necesite una validación adicional.

Si alguna vez envía la contraseña por correo electrónico, verifique que la contraseña no contenga líneas nuevas u otros caracteres de control. Si inserta la contraseña en una base de datos, asegúrese de usar las declaraciones preparadas de SQL para formar la consulta de la base de datos (no utilice concatenación de cadenas). Si alguna vez muestra la contraseña en una página web incluyéndola en HTML dinámico (probablemente una mala idea ...), entonces asegúrese de que HTML se escape de la contraseña correctamente antes de incluirla en el HTML.