Ahora Google audita cómo te atacan localmente en Gmail

Buena entrada del maligno:

Cuando un servidor web quiere comunicarse con un web browser utilizar los HTTP Headers. Es en ellos donde puede configurar propiedades de funcionalidad o seguridad que quiere que se apliquen en el cliente o darle información sobre el tipo de contenido que se le está enviando y en qué formato. Esto le permite a los creadores de aplicaciones web controlar el entorno completo para, por ejemplo, hacer más difíciles los ataques locales a sus clientes, y Gmail ha comenzado a utilizarlas para ver cómo se está atacando su aplicación.

Figura 1: Google audita Gmail usando CSP

Entre la larga lista de cabeceras HTTP que se utilizan hoy en día, hay algunas estandarizadas y otras que son utilizadas por la industria en base a una necesidad puntual. Estas últimas, con el paso del tiempo, a veces acaban siendo estandarizadas para que todos los navegadores las tengan que implementar en sus características.

HTTP Headers no estándar para seguridad

Las cabeceras HTTP que no son estándar se identifican por medio de una X al comienzo del nombre. Así, por ejemplo, la HTTP Header X-Frame-Options que se utiliza para evitar que una página web de una determinada URL sea metida dentro de un frame para realizar un ataque de click-jacking, está aún sin estandarizar, aunque está implementada por la mayoría de las aplicaciones web - y por supuesto de Gmail -.

Otra de estas cabeceras de seguridad es la famosa X-XSS-Protection, utilizada para activar o desactivar el filtro Anti Cross-Site Scripting de los navegadores evitando situaciones en las que un usuario tenga un entorno inseguro o permitiendo al servidor deshabilitarlo puntualmente para evitar un fallo de funcionamiento.

Figura 2: X HTTP Headers de seguridad en Gmail

Otra muy común, tampoco estandarizada, es X-Content-Type-Options con valor nosniff, que le dice al navegador a evitar el reconocimiento de tipos MIME automático. Es decir, por defecto si un fichero es entregado desde el servidor como un Content-Type: Text/plain, y el contenido es una página HTML, los navegadores lo van a interpretar como un HTML y van a renderizar el código. Esto puede generar problemas de seguridad cuando alguien envía un fichero HTML malicioso como adjunto como fichero .TXT. Para evitar que el navegador haga ese descubrimiento automático de Content-Types, se utiliza, simplemente un HTTP Header como:

X-Content-Type-Options:nosniff.

Para terminar, no me quiero olvidar de las etiquetas que se utilizan para comunicarse con un cliente muy particular, como es el bot de Google y comunicarle cuáles son los deseos en cuanto a la indexación y cacheo, como ya vimos en los casos de Facebook o Gmail, mediante el uso de X-Robots-Tag.

Content Security Policy & Strict Transport Security

Este conjunto de propiedades, antes de estandarizarse podría encontrarse como X-Content-Security-Policies e incluso como X-Webkit-CSP. Después del proceso de estandarización, las HTTP Headers para reducir la superficie de ataque en el cliente son conocidas como CSP o Content Security Policy. Estas etiquetas permiten configurar muchos más detalles del cliente, orientados a evitar, por ejemplo, el uso de código Script en el medio del código HTML. Esto fuerza al desarrollador a colocar todo su código Script al principio, pero evita que se pueda explotar cualquier bug de XSS.

Figura 4: Configuración de CSP en Facebook

También se puede elegir de dónde se puede cargar el contenido externo de la web en el cliente, lo que reduce todos los posibles entornos de ataque por carga de contenido de terceros, o elegir qué tipo de plugins pueden ser ejecutados, lo que evita la explotación de bugs en plugins vulnerables - como algunas versiones de Flash que pudieran ser utilizadas hasta para hacer robo de cookies HTTP-Only -. El siguiente ejemplo le dice al cliente desde donde se pueden cargar los códigos script en una web desde el mismo código de la web y desde una URL concreta.

Content-Security-Policy: script-src 'self' https://js.misite.com

Se puede configurar un nivel de granularidad tal, que permitiría a un servidor web decidir desde que ubicación se pueden utilizar cada uno de los tipos de contenido y hasta cómo se pueden utilizar los WebSockets, anulando muchos de los ataques que necesitan controlar un padding en el cliente para atacar conexiones HTTPs. Todo esto se configura mediante un sencillo conjunto de variables y en HTML5 rocks tenéis muchos ejemplos de configuración granular. 

Figura 3: Política HSTS en Gmail

Otra de las características que se puede configurar con una etiqueta estándar conocida como Strict-Transport-Security HSTS es si el contenido está siendo mostrado sobre HTTPs o no, lo que anula muchas de las herramientas de SSLStrip para hacer ataques de red que no están teniendo en cuenta la limpieza de estas HTTP Headers.

CSP en modo reporting

Una de las características de las Content Security Policy es que no es necesario cambiar el funcionamiento de la aplicación si no estás seguro de haber configurado en las CSP Headers todo de forma correcta, y puedes establecer una etiqueta en modo reporting, como ha hecho Gmail. Esto se establece mediante un header de tipo Content-Security-Policy-Report-Only donde se establecen todos los parámetros de configuración de seguridad en el navegador.

Figura 5: CSP en modo Reporting en Gmail

Al final de esa etiqueta se le indica en el parámetro Report-URI la URL a la que se quiere que el navegador informe mediante un POST a esa dirección cada vez que se incumpla la política, pero que no bloquee ningún funcionamiento. Esto es para auditar si están bien configuradas las CSP y para descubrir qué partes de la aplicación son las que no cumplen.

Nosotros, por supuesto, en nuestro sistema de Pentesting Persistente Faast, buscamos desde hace tiempo todas las etiquetas citadas aquí, para informar a nuestros clientes cada vez que una web no está fortificada correctamente. Esto no siempre es un fallo de seguridad, pero sí que es una buena recomendación de seguridad para evitar la explotación de otros fallos más comunes.

Figura 6: Ver HTTP Headers de una petición

Si quieres ver los HTTP Headers que se envían en cada petición web, con Google Chrome puedes usar las Herramientas del Developer, entrar en Network, seleccionar un elemento y en el panel de la derecha seleccionar Headers.

Saludos Malignos!

Fuente: http://www.elladodelmal.com/2014/12/ahora-google-audita-como-te-atacan.html