ErrorDocument Handlers en aplicaciones web

Cuando toca hacer una auditoría de seguridad web, una de las cosas que es obligatorio revisar son los ErrorDocument Handlers, o lo que es lo mismo, cuáles son los manejadores de mensajes de errores para cada situación anómala en el servicio web. Estos mensajes pueden dar mucha información, como el de Error de conversión de Tipos en PHP, el de objeto no encontrado en servidores JSP, los errores de ASP en servidores migrados, los errores 500 de licencia en ColdFusion, o en cosas más raras como los errores TCL en WebDNA. 

También con ellos se pueden hacer cosas muy útiles como robar cookies HTTPOnly con errores 400 de Apaches no actualizados, hacer ataques SQL Injection con errores ODBC, usar los errores ODBC para lanzar Serialized SQL Injection, preparar ataques de Arithmetic Blind SQL Injection usando los errores del SGBD, descubrir ficheros con nombres acortados en IIS, o ficheros de backup con mod_negotiation. Al final, cualquier pizca de información recogida de un mensaje de error que al principio parezca inócua puede ser vital para el owned final.

A la hora de descubrir un ErrorDocument Handler hay que tener en cuenta que en una arquitectura web este depende de tres factores, como son el servidor en el que se genera el error - en el frontal de la CDN, el Reverse Proxy, el servidor web de backend, el servidor web de almacenamientos, el SGBD, etc... -, el manejador de extensión del fichero solicitado - JSP, TCL, ASP, ASPX,... - y el tipo de error que se ha producido, ya sea un 400, 404, 500, o cualquier otro.

Si quieres tener una web que evite las fugas de información por esos tipos de errores, es necesario tener una política clara que establezca de forma homogénea un tratamiento de errores estándar en todos los servidores, en todos los manejadores de extensiones de documentos y en todos los códigos de error. 

Os cuento esto porque, a raíz de un error buscando un RSS, solicité un fichero XML a un servidor web y me dio un error no controlado. Me extrañó un poco porque el sitio web tenía controlados los errores 404 para extensiones no conocidas, pero parece que XML tiene su propio manejador de errores, lo que hacía que se viera otro mensaje de error. He probado en varios sitios, y es más común de lo que pensaba.

Figura 1: Extensión a sin controlar

Figura 2: Extensión XML controlada

En un primer momento pensé que el XML lo trataba como un HTML pero no, en sitios en los que está controlado el HTML, el XML no lo estaba.

Figura 3: Todos los errores de extensión, menos el XML controlados

En otros sitios me encontrado que el servidor web daba un Error al no tener un ErrorDocument Handler para una extensión no controlada en el dominio principal con www para las extensiones no conocidas, mientras que sin www estaba controlado, algo que me ha recordado a lo de los Errores Rercursivos: Errores en los mensajes de Error.

Figura 4: Error 404 para extensión no conocida en dominio sin www controlado

Figura 5: Error 404 para extensión no conocida en dominio con www no controlado

Esto del XML me ha aparecido hasta en sitios militares donde el tratamiento de errores ya era malo de por sí para el Not Found, porque no devuelven la respuesta en HTML sino en en texto.

Figura 6: Error 404 para extensión aa

Pero para los errores XML el resultado era otro.

Figura 7: Error 404 para extensión XML

FOCA no busca errores de Not Found con extensión XML - sin con no conocidas -, y no he visto que de algún error de 404 en ficheros XML haya sacado algo de información útil, pero por si acaso he revisado los míos y las de algunos clientes para avisarles de que, en algún caso, no tenían controlado el mensaje de error. Si eres de los que le gusta tener controlados todos los códigos de error, merece la pena que hagas una prueba para ver qué pasa en tu sitio con los XML y las extensiones no conocidas.

Saludos Malignos!