Español | English
rss facebook linkedin Twitter

Cuidado con la información que ponemos en las Intranets

Hace días que en diferentes listas de correo del W3C se vienen discutiendo los pros y contras sobre la estandarización de una nueva cabecera HTTP, denominada Origin, con la única intención de servir como defensa a los ataques CSRF.

Gran parte de la discusión viene dada con argumentos de que ya existe una cabecera HTTP que sirve para ese propósito si se utiliza bien, Referer. Esta cabecera a pesar de que es trivial falsearla, tiene algunas características de privacidad, motivo por el cual muchos proxys y navegadores la descartan, ya que muestra el path de la URI. -¿Y qué problema tiene?-, más adelante lo vemos.

Adam Barth, en su paper "Robust Defenses for Cross-Site Request Forgery", en el cual expone sus argumentos para la adopción de esta nueva cabecera HTTP, hace referencia a un tipo de problema derivado del uso de Referer. Me llamó la atención porque creo que este tipo de situaciones no se tienen en cuenta si se desconocen.

Para situarnos con el uso que se le da a esta cabecera, si realizamos la búsqueda "seguridad digital" en www.ask.es y vemos las peticiones que generamos:

[1]
GET / HTTP/1.1
Host: www.ask.es
(datos omitidos)

[2]
GET /web?q=seguridad+digital&qsrc=0&o=312&l=dir&dm=lang HTTP/1.1
Host: es.ask.com
(...)

El buscador nos muestra los resultados y pinchamos sobre uno de ellos,

[3]
GET / HTTP/1.1
Host: blog.s21sec.com
(...)
Referer: http://es.ask.com/web?q=seguridad+digital&qsrc=0&o=312&l=dir&dm=lang

Esta cabecera es ampliamente utilizada en software de estadísticas web como Google Analytics para determinar cómo se llego hasta un sitio web, si fue a través de un buscador como en este caso, a través de otra página, o introduciendo la URI directamente en el navegador.

Ahora viene la parte interesante, la que comentaban como problema de privacidad de esta cabecera según el entorno donde se use. Imaginad una Intranet, donde se colocan noticias de los logros del negocio, planes futuros, o el próximo lanzamiento de un nuevo producto. Si en esa intranet colocamos un enlace a una empresa competidora para mostrar los beneficios de nuestro nuevo producto frente al suyo, nos podría suceder algo como esto:

Noticia de ejemplo en nuestra intranet. Qué tendrá una URI como esta:
http://nuestra-intranet.com/noticias/2008/12/10/Lanzamiento-del-nuevo-producto-X

"El departamento de desarrollo ha finalizado el producto X, el cual pretendemos lanzar al mercado en el periodo de 2 meses. El valor añadido que ofrece este producto frente a otros similares como el de [empresa que vera nuestra noticia] o [otra empresa que verá nuestra noticia] son las características de poder [...]"

Lo que se verá al otro lado de nuestra intranet, es decir, en las estadísticas web de las empresas que hemos enlazado como competidoras de nuestro producto sera:
X.X.X.X - - [29/Jan/2009:09:34:22 -0500] “GET /noticias/ HTTP/1.1″ 200 34659 “http://nuestra-intranet.com/noticias/2008/12/10/Lanzamiento-del-nuevo-producto-X” “Mozilla/5.0 [información eliminada]″
Este puede ser un tipo de fuga de información, muy específico, pero que puede dar detalles a los competidores sobre nuestros planes.

Otra variante de este tipo de fuga de información puede darse a través del correo. Las intranets suelen tener la opción activada para enviar correos de las noticias publicadas, con el fin de que aquellas personas que por motivos diversos no tengan acceso, puedan conocer esas noticias a través del correo. Si estas personas acceden al correo a través de un webmail y pinchan sobre los enlaces de la noticia, lo que verán estas empresas será un log del referer del tipo.

http://webmail.tudominio.com/search;_tlt=V0oG43BZHn1JFEoAVcar4Qt.

No muestra tanta información como desde la intranet, pero se ve, que algo se está preparando en la empresa competidora ya que nos están haciendo referencia por algún motivo.

¿Se os ocurren más variantes de problemas relacionados con esta cabecera?

Emilio Casbas
S21sec labs

3 comentarios:

Álvaro dijo...

Hola, tengo una duda:

¿Se podría enviar el id de la sesión en el caso de que aparezca en la cabecera (típico jsessionid), al hacer la petición?.

Porque si es así, y ese parámetro aparece en el Referrer, también se podría robar la sesión.

S21sec labs dijo...

Alvaro, efectivamente, como comentas, se podría dar ese caso.
Pero por eso mismo, en las guías de desarrollo seguro se recomienda que no se pase ningún parámetro en la URI.
http://www.owasp.org/index.php/Data_Validation#URL_encoding

Y si se hace, que se codifique adecuadamente. O que la sesión se haga mediante cookies.

La serie de artículos de Ramón, entra en más detalles relacionados.
http://blog.s21sec.com/2009/01/seguridad-en-las-sesiones-de-las_14.html

Iñaki dijo...

Entonces Alvaro, el problema no sería la cabecera Referer sino que el identificador de sesión va en el GET en lugar de un POST, error catalogado como "arquitectura y diseño": No utilizar un método GET que realice un cambio de estado o que mostrar enlaces externos si la petición GET contiene datos de la solicitud.

Extendiendo un poco más el comentario, la fuga de información (que también es un tipo de debilidad por si misma) pertenece al grupo de Exposición de recursos en el entorno (esfera) incorrecta: http://cwe.mitre.org/data/definitions/668.html, desde el que se puede llegar hasta la debilidad: "divulgación de información (sensible)" en : http://cwe.mitre.org/data/definitions/200.html, y de la que forma parte "CWE-598: Information Leak Through Query Strings in GET Request" que esta en: http://cwe.mitre.org/data/definitions/598.html.


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login