Tutorial de secuencias de comandos entre sitios (XSS)

 

 

 

Guía sobre ataques de secuencias de comandos entre sitios. ¿Cómo funcionan? ¿Cómo se pueden prevenir?

 

¿Qué es XSS, también conocido como Cross Site Scripting?

XSS es el término que utilizamos para definir un tipo particular de ataque en el que un sitio web (su sitio web, si no presta atención) puede usarse como vector para atacar a sus usuarios, debido a un manejo inseguro de la entrada del usuario.

Básicamente, un mal actor (el atacante) puede inyectar JavaScript, de una forma u otra, en nuestro sitio, aprovechando una vulnerabilidad que dejamos en nuestro código.

Aprovechando esta vulnerabilidad, pueden robar información del usuario.

Según cómo se explota la vulnerabilidad XSS, tenemos tres tipos principales de ataques XSS:

  • XSS persistente
  • XSS reflejado
  • XSS basado en DOM

¿Por qué es peligroso XSS?

Imagina que tienes un sitio web. Un atacante puede, de alguna manera, inyectar código JavaScript que se ejecuta en tu sitio web y que los navegadores de los usuarios lo ejecutan sin tu voluntad y sin que lo sepas.

Esto es muy peligroso.

Debido a su negligencia al corregir una vulnerabilidad XSS, su sitio puede usarse como vector de ataque y la información de sus usuarios está en riesgo.

En particular, cuando cualquiera puede inyectar JavaScript en una página, puede tener acceso a las cookies del usuario asociadas con el sitio web y leer cualquier información que contengan y enviarla a sus propios servidores. Pueden escuchar eventos del teclado y obtener acceso a cualquier cosa que el usuario escriba en la página y enviarla a los servidores del atacante mediante fetch o XHR. Nombres de usuario y contraseñas, por ejemplo. También pueden manipular el DOM y con este poder pueden realizar muchas cosas malas.

¿XSS es un problema del frontend o del backend?

Son ambas cosas. Es un problema de arquitectura del sitio web que afecta tanto al frontend como al backend.

Un ejemplo de ataque XSS

XSS se habilita básicamente cuando permites que el usuario ingrese información, que tú almacenas (en tu backend) y luego presentas.

 

Digamos que tienes un blog y permites que los usuarios comenten en él. Si aceptas ciegamente cualquier contenido que introduzcan los usuarios, un usuario malintencionado puede intentar introducir un fragmento de código JavaScript, en su forma más básica, incluido dentro de script/script. Por ejemplo scriptalert('test')/script.

Puede almacenar este comentario en su base de datos y, cuando se vuelva a cargar la página (nuevamente, si no tiene ninguna prevención implementada), todos los usuarios que carguen esa página ejecutarán ese fragmento de JavaScript.

Utilicé una alert()llamada simple para hacer un ejemplo, pero como se mencionó anteriormente, un usuario podría ingresar cualquier tipo de secuencia de comandos. En este punto, el sitio está comprometido.

¿Qué es XSS persistente?

El XSS persistente es uno de los tres tipos de XSS que encontramos en la naturaleza. Es el que describí anteriormente en el ejemplo de la publicación del blog.

En este caso, el código de la vulnerabilidad se almacena en la base de datos o en alguna otra fuente alojada por usted.

Una vez que alguien puede ingresar un fragmento de JavaScript, su sitio lo muestra automáticamente sin necesidad de realizar ninguna otra acción.

¿Qué es XSS reflejado?

XSS reflejado es una forma de explotar una vulnerabilidad en su sitio sobre la marcha proporcionando al usuario final un enlace que tiene un script dentro.

De esta manera, el atacante proporciona un enlace similar a

yoursite.com/?example=scriptalert('test')/script

Si su sitio usa la examplevariable GET para realizar algo y mostrarlo en la página, y usted no verifica ni desinfecta su valor, ahora ese script será ejecutado por el navegador del usuario.

Un ejemplo típico es un formulario de búsqueda. Puede estar en la /searchURL y aceptar el término de búsqueda mediante la termvariable GET.

Es posible que muestres la You searched for termcadena cuando alguien la busque. Ahora bien, si no has depurado el valor, tienes un problema.

Los correos electrónicos de spam o phishing son un medio común para este tipo de ataques XSS. Por supuesto, cuanto más grande e importante sea el sitio, con mayor frecuencia los piratas informáticos intentarán piratearlo.

¿Qué es XSS basado en DOM?

Con XSS persistente, el código atacante debe enviarse al servidor, donde puede (y con suerte) desinfectarse. Con XSS reflejado, ocurre lo mismo. Juguetes educativos

El XSS basado en DOM es un tipo de XSS en el que el código malicioso nunca se envía al servidor. Es habitual que esto suceda al utilizar la parte de fragmento de una URL o al hacer referencia document.URLa / document.location.href. Algunos ejemplos que se encuentran en Internet ya no funcionan porque los navegadores modernos escapan automáticamente el código JS en la barra de direcciones. Solo funcionan si lo eliminas del escape, lo que da un poco de miedo (¡no lo hagas!).

A continuación, se muestra un ejemplo sencillo de funcionamiento. Supongamos que tiene una página que escucha en https://127.0.0.1:8081/testxss.html . El JavaScript del lado del cliente analiza la testvariable que se pasa en la parte del fragmento de la URL:

 

https://127.0.0.1:8081/testxss.html#test=algo

El #test=somethingvalor nunca se envía al servidor. Es solo local. El XSS persistente/reflejado no funcionaría. Pero supongamos que su script accede a ese valor mediante:

const pos = document.URL.indexOf("test=") + 5;const value = document.URL.substring(document.URL.indexOf("test=") + 5, document.URL.length)

y lo escribes directamente en el DOM:

document.write(value)

Todo está bien, hasta que alguien llama a la URL así:

https://127.0.0.1:8081/testxss.html#test=

Ahora, l escape automático que se produce al hacer referencia, document.URLno debería ocurrir nada en este caso específico.

Lo conseguirías

%3Cscript%3Ealert('x')%3C/script%3E

Se imprime en la página. El valor se escapa, por lo que no se interpreta como HTML.

Pero si por alguna razón anulas el escape del valor document.URL, tendrás un problema, ya que se ejecuta JavaScript. Cualquier código JS se puede ejecutar en los navegadores de tus usuarios.

En navegadores más antiguos, esto era un problema mucho mayor, ya que no escapaban automáticamente el código JavaScript colocado en la barra de direcciones.

¿Los sitios estáticos son vulnerables a XSS?

¡Sí! Cualquier tipo de sitio, en realidad. Porque ser estático no significa que no se cargue información de otras fuentes. Por ejemplo, puedes crear tu propio formulario o comentarios, incluso sin una base de datos.

O bien, podríamos tener una función de búsqueda que acepte la entrada de una variable HTTP GET o POST. No eres inmune por el simple hecho de no tener una base de datos.

¿Cómo podemos prevenir el XSS?

Hay 3 técnicas que podemos utilizar:

  • codificación
  • validación
  • CSP

La codificación se realiza para escapar los datos. Al hacerlo, el navegador no interpretará el JavaScript porque, por ejemplo, scriptse codificará como %3Cscript%3E.

La codificación, como regla general, debe realizarse siempre.

Los marcos del lado del servidor generalmente proporcionan funciones auxiliares para brindarle esta funcionalidad.

En JavaScript del lado del cliente utilizamos un mecanismo de codificación diferente según el caso de uso.

Si necesita agregar contenido a un elemento HTML , la mejor manera es asignar la entrada generada por el usuario a ese elemento mediante la textContentpropiedad. El navegador se encargará de todo el proceso de escape por usted:

document.querySelector('#myElement').textContent = theUserGeneratedInput

Si necesitas crear un elemento utiliza document.createTextNode():

const el = document.createTextNode(theUserGeneratedInput)

Si necesita agregar contenido a un atributo HTML , utilice el setAttribute()método del elemento:

document.querySelector('#myElement').setAttribute('attributeName', theUserGeneratedInput)

Si necesita agregar contenido a la URL, utilice la window.encodeURIComponent()función:

window.location.href = window.location.href + '?test=' + window.encodeURIComponent(theUserGeneratedInput)

La validación se realiza normalmente cuando no se puede utilizar el escape para filtrar la entrada. Un ejemplo común es un CMS que permite al usuario definir el contenido de la página en HTML. No se puede escapar de eso.

Para la validación, se utiliza una estrategia de lista negra o de lista blanca. La diferencia es que con la lista negra se decide qué etiquetas se quieren prohibir, mientras que con la lista blanca se decide qué etiquetas se quieren permitir. La lista blanca es más segura porque la lista negra es propensa a errores, es compleja y no está preparada para el futuro.

CSP significa Content Security Policy (Política de seguridad de contenido). Es un nuevo estándar implementado por los navegadores para exigir que solo se ejecute código JavaScript que provenga de fuentes seguras y confiables, y puede prohibir la ejecución de JavaScript en línea en su código. El tipo de JavaScript que permitió los exploits XSS mencionados anteriormente, por ejemplo.

El servidor web habilita CSP al agregar el Content‑Security‑Policyencabezado HTTP al servir la página.




Tal vez te puede interesar:

  1. Introducción a React
  2. Agregar evento de clic a los elementos DOM devueltos desde querySelectorAll
  3. Cómo cambiar el valor de un nodo DOM
  4. Cómo comprobar si un elemento DOM tiene una clase

Tutorial de secuencias de comandos entre sitios (XSS)

Tutorial de secuencias de comandos entre sitios (XSS)

¿Qué es XSS, también conocido como Cross Site Scripting?¿Por qué es peligroso XSS?¿XSS es un problema del frontend o del backend?Un ejemplo de ataque XSS

programar

es

https://aprendeprogramando.es/static/images/programar-tutorial-de-secuencias-de-comandos-entre-sitios-xss-2130-0.jpg

2024-11-02

 

Tutorial de secuencias de comandos entre sitios (XSS)
Tutorial de secuencias de comandos entre sitios (XSS)

Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

 

 

Update cookies preferences