Clase 03: Vulnerabilidades Comunes en Lado del Cliente

Taller de Seguridad Web

Claudio Salazar (csalazar spect cl)



Sky - Beige - Simple - Serif - Night - Default

Agenda

  • Ataques Cross Site Scripting
  • Ataques Cross Site Request Forgery
  • Ataques UI Redressing

Ataques Cross Site Scripting

Cross Site Scripting (XSS)

Considerada la vulnerabilidad más predominante en las aplicaciones web actuales [1], su relevancia se ha ido incrementando en el tiempo producto de su explotación y consecuencias.


Gran parte de esta sección hace referencia al capítulo 12 de "The Web Application Hacker's Handbook 2"

Efectos de una vulnerabilidad XSS

La explotación de una vulnerabilidad XSS puede ser realizada para llevar a cabo una serie de propósitos, tales como:


  • Robo de sesiones.
  • Defacement virtual.
  • Inyectar funcionalidad maliciosa (phishing).
  • Inducir acciones de un usuario.

Tipos de XSS

  • Reflejado.
  • Almacenado.
  • Basado en DOM.


A continuación se analizará cada tipo, con buenas prácticas recomendadas que juntas representan la solución adecuada a estos tipos de ataques.

Tipos de XSS: Reflejado

Se da cuando enviamos una petición donde incrustamos código Javascript que es reflejado a quien realiza la petición. Es fácil de encontrar y requiere cierta interacción para ser ejecutado por un tercero.

Ejemplo de caso real

Está es la forma más común de mostrar datos que se suponen inocuos.



    <p>
    <?php
      echo $_GET['nombre'];
    ?>
    <p>
    

Escenario normal

http://e.com/p.php?nombre=Juanito
<p> Juanito <p>

Escenario de vulnerabilidad

Se puede realizar una petición normal e incrustar código Javascript, algo no presupuestado por el desarrollador y que posibilita ciertos escenarios como robo de sesiones, etc.

Explotación de la vulnerabilidad

http://e.com/p.php?nombre=Juanito<script>alert(1)</script>
<p> Juanito <script>alert(1)</script><p>

El código Javascript es ejecutado en el navegador.

Buena práctica

Si se conoce el contexto de un dato solicitado, validarlo de acuerdo a su naturaleza, en este caso un nombre que sólo contenga carácteres válidos.

  • Expresiones regulares son de ayuda para esta tarea, aplicadas restrictivamente.
  • Lo ideal sería replicar las validaciones tanto en el lado del cliente como el servidor. En el lado del servidor deben ser obligatorias.

Tipos de XSS: Almacenado

Se da cuando un usuario envía Javascript embebido en los datos que son almacenados en la aplicación y luego estos datos son mostrados a otros usuarios.

Ejemplo de caso real (Simulación) [1]


    <?php
      [...]
      $address = $_POST['address'];
      [...]
      $place_id = save_place([...], $address); // 12345
    ?>
    

    <?php
      [...]
      $address = get_address($place_id)
      echo 'Dirección: '$address;
      [...]
    ?>
    

Escenario normal

  • Guardando los datos. (POST)
  • POST [...]/place/12345/edit
    [...]&address=Placeres
    Datos guardados correctamente.

  • Visitando el lugar.
  • GET [...]/place/12345
    Dirección: Placeres

Escenario de vulnerabilidad

Se puede realizar una petición normal e incrustar código Javascript, que será almacenado en la base de datos y gatillado cuando un usuario visite la página del lugar.

Explotación de la vulnerabilidad

  • Guardando los datos. (POST)
  • 
    POST [...]/place/12345/edit
    [...]&address=Placeres<img src="a.jpg"onerror=javascript:alert(6)>
    Datos guardados correctamente.

  • Visitando el lugar.
  • GET [...]/place/12345
    
    Dirección: Placeres<img src="a.jpg"onerror=javascript:alert(6)>
          

El código Javascript es ejecutado en el navegador.

Buena práctica

Para desplegar datos suministrados por el usuario, es aconsejable codificar los carácteres usando codificación HTML. Para este caso, sería útil la función htmlspecialchars(), incluida en PHP.

  • En el caso de URLs sería más apropiado codificación URL.
  • Los frameworks actuales tienen activado esto por defecto.

Tipos de XSS: Basado en DOM

Este tipo consiste en una serie de pasos:

  1. Un usuario hace una petición a una URL que contiene Javascript embebido.
  2. La respuesta del servidor no contiene referencia alguna a ese código embebido.
  3. Cuando el navegador procesa la respuesta, el código es ejecutado.

Ejemplo de caso real [1]

Escenario normal

Escenario de vulnerabilidad

Si las palabras que ingreso son agregadas al DOM y no pasan por una correcta sanitización, podría intentar crear un vector para ejecutar código Javascript arbitrario.

Explotación de la vulnerabilidad


a"</li><<iframe/onload=alert("XSS")>
      

El código Javascript es ejecutado en el navegador.

Buena práctica

En el lado del cliente también se deben realizar revisiones de la entrada de datos y como estos son agregados al DOM, debe ser aplicada una correcta codificación para evitar este tipo de ataques.

Diferencias entre tipos de XSS

  • Un ataque reflejado o basado en DOM supone pasos adicionales para que sea gatillado respecto a un ataque almacenado.

  • Un ataque basado en DOM puede ser explotado sin que su vector se envíe a la aplicación, a diferencia de los otros donde el vector si es recibido por ésta.

Factores en la explotación de XSS

La explotación exitosa de una página susceptible a XSS depende en una serie de factores, tales como:

  • Mecanismos de seguridad de la aplicación: filtrado como sanitización.
  • Adecuación al contexto donde el vector es ejecutado.
  • El navegador y sus mecanismos de protección.

Formas de incrustar código Javascript en contexto HTML

  • Etiquetas de script.
  • <script>alert(1)</script>
  • Manejadores de eventos.
  • <img src=x onerror=alert(1)>
  • Pseudo protocolos de script.
  • <embed src=javascript:alert(1)>
  • Estilos evaluados dinámicamente.
  • <x style=x:expression(alert(1))>

Formas de incrustar código Javascript en otros contextos

La idea es básicamente incrustar nuestro vector sin que esto provoque errores de síntaxis. Es necesario tener claro que:


  • No siempre nuestro input será en el cuerpo del documento HTML.
  • No siempre tendremos que escapar de comillas.

Demo de ataques XSS

Prevención de ataques XSS

  • Validar la entrada de datos.
  • Validar la salida de datos.
  • Eliminar puntos de inserción peligrosos.
  • Evitar scripts que procesen y modifiquen el DOM.
  • Ayuda de las cabeceras que existen actualmente.

Prevención de ataques XSS: Entrada de datos

Aplicar una validación dependiente del contexto de los datos.

  • Especificar el largo de los datos.
  • Los datos solo contienen un set de caracteres permitidos.
  • Los datos coinciden con una expresión regular.

Prevención de ataques XSS: Salida de datos

Aplicar codificación a los datos antes de desplegarlos en la aplicación.

  • Usar codificación HTML sobre los datos.
  • En enlaces es común ver codificación URL.
  • La mayoría de los frameworks provee de funciones para esta tarea.

Ataques Cross Site Request Forgery

Cross Site Request Forgery (CSRF)

El propósito es enviar una petición a la aplicación vulnerable donde la víctima se encuentra autenticada para realizar acciones sin su consentimiento.


Esta vulnerabilidad viene dada porque la aplicación usa solo las cookies para llevar la pista de una sesión.

Ejemplo de caso real [1]

La petición de invitación en LinkedIn:


POST /fetch/manual-invite-create HTTP/1.1
Host: www.linkedin.com
[...]

emailAddresses=&subject=Invitation+to+connect+on+LinkedIn&csrfToken=ajax:1234567890123456789[...]
    

Podía ser simplificada a:


GET /fetch/manual-invite-create?emailAddresses=&subject=Invitation+to+connect+on+LinkedIn
    

Escenario de vulnerabilidad

Si no hay una verificación desde donde fue enviada la petición y la única validación de sesión se realiza mediante cookies, podría enviar esta petición aprovechando el hecho que un usuario se encuentra logueado en el sitio.

Explotación de la vulnerabilidad


<img
src="http://www.linkedin.com/fetch/manual-invite-create?emailAddresses=<attacker_email>&subject="
width=0 height=0>
    

Buena práctica

Para evitar este comportamiento, agregar un token al formulario y validarlo en el lado del servidor, con el objetivo de que no pueda ser realizada una petición cross-site éxitosamente.

  • La mayoría de los frameworks ofrecen la posibilidad de agregar y validar este token.
  • Es importante validar el token, no basta con solo agregarlo.
  • Esto no soluciona todo, imaginar el caso XSS+CSRF.

Ataques UI Redressing

Ataques UI Redressing

La página objetivo en un iframe transparente, y se induce a la víctima a interactuar con objetos visibles (botones, imágenes, etc) siendo que realmente está haciendo click en la página dentro del iframe.


También es conocido como ClickJacking, StrokeJacking, entre otros nombres.

Video Demostración (por Dianamic)

Previniendo ataques UI Redressing

  • Framebusting code, que puede ser esquivable de varias formas.
  • 
    <script>
      if (top.location != self.location)
        { top.location = self.location }
    </script>
      
  • El uso de la cabecera X-Frame-Options, que es lo recomendado.

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.