Hay numerosas referencias a las vulnerabilidades de división de respuesta HTTP (HRS) con PHP que se ha resuelto desde 4.4.2 y 5.1.2 (por ejemplo, enlace ), o por alrededor de 9 años.
Y, sin embargo, CVE-2013-2652 informó una vulnerabilidad en WebCollab usando PHP, aunque la prueba de concepto ( enlace ) especificó una versión de PHP 5.4.7. La identificación del problema utiliza "% 0d% 0a" en su declaración del problema.
Yo mismo he experimentado con PHP y, de hecho, no permite la inserción de la secuencia hexadecimal de 2 bytes 0x0d0x0a, pero no evita la inserción de la secuencia de 6 caracteres equivalente codificada en%% 0d% 0a.
Al menos en la superficie, esto parece ser un poco contradictorio. Es decir. que 1) PHP no es tan seguro para HRS como se sugiere, ya que permite insertar la secuencia de 6 caracteres "% 0d% 0a" en un encabezado o 2) la vulnerabilidad declarada en CVE-2013-2652 (que "% 0d % 0a "fue permitido escribirlo por una aplicación PHP) fue al menos significativamente exagerado.
¿Cuál de esos es verdadero? (¿O es algo completamente distinto?)
(Notas: a) Comprendo perfectamente que es mejor validar o desinfectar los datos proporcionados por el usuario, independientemente de qué otras protecciones estén en su lugar. b) La solución WebCollab fue bastante sencilla y hace exactamente eso: validar la entrada proporcionada por el usuario para los caracteres permitidos. Estoy más interesado aquí en la robustez de la seguridad de HRS de PHP y en la naturaleza de cualquier peligro, si existe.