Revisión de código en una inyección de encabezado en Java: ¿ayuda?

Question

Revisión de código en una inyección de encabezado en Java: ¿ayuda?

#1 de bobince (9 votos)

6

Estoy auditando un fragmento de código Java que podría ser vulnerable a inyección de encabezado :

String headerValue =request.getParameter("headerVal");

//escaping CRLF
headerValue = headerValue.replace("\n", "");
headerValue = headerValue.replace("\r", "");
response.addHeader("myheader",redirection);

Este código está presente directamente en la vista de capa (jsp).

Por lo que sé, este fragmento de código no tiene en cuenta que CRLF podría inyectarse en una codificación diferente de acuerdo con mis lecturas.

En otras palabras, me gustaría informar al equipo de DEV como un problema de canonización.

Debido a que creo que los desarrolladores lo negarán, estoy tratando de configurar una prueba de concepto con un proyecto HelloWorld con Tomcat6, pero parece que Tomcat está evitando esto en segundo plano.

¿Tiene algún otro argumento aparte de la canonización para justificar esta falla? ¿O estoy muy equivocado y este código es seguro? Gracias de antemano.

Frenchy

injection code-review

pregunta Omar Elfada 28.12.2011 - 17:15

fuente

1 respuesta

Lea otras preguntas en las etiquetas injection code-review

¿Es esta una buena manera de administrar Incidente-Respuesta ¿Puede un CSV contener código malicioso?

score 9 · Answer 1

En principio, los encabezados HTTP son ISO-8859-1 de acuerdo con RFC 2616. En la práctica, el contenido no ASCII en encabezados HTTP estará en una codificación diferente dependiendo del navegador (y para IE también local), pero siempre un superconjunto ASCII . Por lo tanto, CR y LF se codificarán invariablemente como 0x0D y 0x0A, por lo que no debería preocuparse si los reemplaza.

El único punto en el que la codificación entraría en juego sería para las secuencias largas de UTF-8. Por ejemplo, 0x0A podría codificarse como 0xC0 0x8A. Esto no es válido, pero ha sido aceptado por varios decodificadores UTF-8 en el pasado. Entonces, si:

estás usando una codificación [por defecto] que no es UTF-8 en tu aplicación web, de modo que esta secuencia de bytes se complete sin que Java se queje de que es demasiado tiempo, y
el agente de usuario al que enviaba el encabezado debía descodificar los encabezados en bloque usando UTF-8, y
el agente de usuario permitió secuencias UTF-8 demasiado largas

entonces sí, podría obtener ataques de contrabando de encabezados reflejando un parámetro en un encabezado de respuesta.

Con los agentes de usuario de hoy en día, esta es una propuesta bastante improbable, pero en general diría que vale la pena eliminar todos los caracteres que no son ASCII de los valores de encabezado, simplemente porque se manejan de manera tan inconsistente entre los navegadores como para ser inútiles en cualquier caso. . También recomiendo filtrar todos los caracteres de control 0x00–0x1F, no solo las nuevas líneas.