Cómo verificar si su sistema de WordPress está protegido contra ataques XSS
En todo el mundo, casi el 48 por ciento de todos los sitios web son vulnerables a secuencias de comandos entre sitios (XSS). En todo el mundo, casi exactamente el 25 por ciento de todos los sitios web utilizan la plataforma WordPress.
De ello se deduce que en el diagrama de Venn de sitios web que son vulnerables a XSS y sitios web que ejecutan la plataforma WordPress, la superposición debe ser bastante grande.
Esto no es un golpe en la plataforma en sí. El equipo de WordPress ha hecho de la seguridad una parte integral de su declaración de misión y parchea agresivamente las vulnerabilidades cada vez que se conocen. Sin embargo, esto no impide que las personas codifiquen temas inseguros o instalen complementos inseguros. Estos problemas son las dos principales vías de entrada para los ataques XSS en los sitios de WordPress, y este artículo analizará cómo detenerlos.
Introducción a las secuencias de comandos entre sitios
Primero, analicemos cómo se llevan a cabo los ataques XSS. Hay más de un tipo de ataque XSS, por lo que comenzaré con una definición simplificada. En general, los ataques XSS comienzan con entradas no desinfectadas: formularios de comentarios, cuadros de comentarios, barras de búsqueda, etc. Estos ataques varían ampliamente en sofisticación. En realidad, los usuarios de WordPress ven la forma más simple de ataque XSS todos los días: el comentario de spam. Ya sabes de lo que hablo: “Gracias por el excelente artículo. Por cierto, aquí está mi sitio donde gano $5,000 a la semana trabajando desde casa: www.only-an-idiot-would-click-this-link.co.uk".
De alguna manera, los comentarios de spam son el ejemplo perfecto de un ataque XSS. Una entidad maliciosa subvierte la infraestructura de su sitio (el cuadro de comentarios) para colocar su contenido (el enlace malicioso) en su sitio. Si bien este es un buen ejemplo ilustrativo, un ataque XSS más realista será mucho más sutil. Un comentario de spam tarda unos cinco segundos en crearse. Un ataque XSS es algo en lo que un pirata informático adecuado dedicará un poco más de tiempo.
Un verdadero sombrero negro intentará aprovechar todos y cada uno de los aspectos de su sitio que envían datos al servidor, esencialmente usándolos como un editor de texto en miniatura. Si sus entradas no están protegidas, eso significa que literalmente pueden tomar su código y obligar a su aplicación a ejecutarlo y representarlo en el navegador de un usuario (y eso puede incluir su navegador). A diferencia de los comentarios de spam, solo un examen detallado del código modificado de su sitio o un análisis de las interacciones del sitio web puede revelar una infracción. Como uno podría imaginar, no hay fin a la cantidad de cosas desagradables que podrían resultar de tal incumplimiento.
El vandalismo simple es un resultado relativamente común de los ataques XSS, lo que hace que a sus usuarios se les muestren imágenes grotescas o propaganda política en lugar de su contenido. Los especialistas en marketing con pocos planes a largo plazo o preocupaciones éticas los utilizarán para anunciarse a las personas en contra de su voluntad. Un ataque más matizado y sutil podría robar las credenciales de inicio de sesión de sus usuarios. Si uno de ellos tiene privilegios de administrador, cualquier información personal que almacene en su sitio puede estar disponible. Alternativamente, podrían usar el ataque XSS inicial como palanca para abrir su sitio e instalar malware aún más avanzado.
Detención de ataques
Si usted es un individuo razonablemente experto en programación y es el único propietario de un sitio de WordPress relativamente pequeño, entonces las prácticas de codificación seguras probablemente serán la mejor manera de bloquear su sitio contra ataques de secuencias de comandos entre sitios. Incluyo esta advertencia porque si usted es parte de una organización más grande que ejecuta una aplicación más compleja, es posible que no sea humanamente posible encontrar todas las áreas donde un atacante malintencionado podría inyectar código. Los sitios web modernos pueden tener una escala enorme, y es posible que le convenga contratar a un profesional experimentado y dedicar su tiempo a otras actividades para que su sitio web sea aún mejor para sus lectores.
Otra advertencia es que si usted no es particularmente experto en programación y tiene a alguien más que construye su sitio por usted, entonces no asuma que han usado prácticas de codificación seguras. Se sabe que incluso los desarrolladores más experimentados dejan de lado la seguridad o cometen errores menores sin que alguien más verifique su trabajo. Es posible que otros desarrolladores simplemente no sepan lo que están haciendo en términos de seguridad, y otros aún pasan por alto la seguridad para ahorrar tiempo para sí mismos (a pesar de la falta de profesionalismo cuando se trata de eso). En resumen, asegúrese de contratar a un profesional aclamado que no tome atajos cuando se trata de desarrollar y proteger su sitio web.
Una vez expresada esa preocupación, una de las primeras y más sencillas cosas que puede hacer para evitar las secuencias de comandos entre sitios es validar los datos del usuario.
Supongamos que tiene un formulario de registro en su sitio y ese formulario le pide al usuario que ingrese su nombre. En cambio, un usuario malintencionado podría escribir algo como:
<script>CoughUpYourPreciousData();</script>Esto podría, por ejemplo, hacer que la próxima persona que visite esa página envíe una copia de sus cookies a un atacante.
Puede ver que en este ejemplo, la cadena de código anterior no se parece en nada al nombre de alguien. Su servidor no sabe esto, pero al usar algunos parámetros establecidos, puede enseñarlo. Por ejemplo, puede indicarle a ese campo que rechace caracteres especiales, como <>,() y ; (no son particularmente necesarios en una sección de comentarios). Puede decirle a ese campo que el nombre de una persona probablemente no tenga números. Si está dispuesto a ser un poco draconiano, puede decirle a ese campo que rechace las entradas que tengan más de quince caracteres (o puede cambiar los valores como desee). Seguir estos pasos limitará drásticamente la cantidad de daño que un atacante puede hacer con un campo en particular.
Incluso con la validación de datos, puede haber formularios o campos en los que no pueda limitar de manera realista el tipo de caracteres que se utilizan, como en un formulario de contacto o un campo de comentarios. Lo que puede hacer es desinfectar los datos. Este proceso hace que sea imposible ejecutar HTML en un campo determinado, convirtiendo todo lo que podría reconocerse como una pieza de código ejecutable en caracteres no codificables. Como ejemplo, un hipervínculo no aparecerá donde de otro modo podría haber uno.
Por último, hay casos en los que su sitio podría terminar mostrando datos que no son seguros para los usuarios. Digamos que alguien escribe un comentario malicioso en una de sus páginas, que posteriormente es indexado por la función de búsqueda de su sitio web. Cada vez que uno de sus usuarios realiza una búsqueda, ese código malicioso se ejecuta cuando su navegador carga los resultados de la búsqueda. Esto se evita mediante el escape de datos, lo que garantiza que cuando su sitio entregue datos a un usuario, el único código que se ejecuta es el código que desea ejecutar.
Para obtener más información sobre la validación de datos, la desinfección de datos y el escape de datos, el Codex de WordPress tiene un excelente recurso. Explicará los conceptos anteriores en detalle y dará más ejemplos que se pueden aplicar universalmente.
Otros metodos
Las grandes empresas tienen sitios web más grandes; es un hecho. Tal vez miles de personas usen su sitio por día. Tal vez en lugar de formularios y campos estándar, también hay animaciones, varios portales, partes escritas en Java, etc. Incluso si realiza un seguimiento de todo eso, tal vez haya un día cero en una de sus aplicaciones y no tenga forma de defenderse.
En una situación como esta, si tiene la influencia y el presupuesto para hacerlo, le recomiendo que invierta en un firewall de aplicaciones web (WAF). Un buen WAF tendrá reglas de correlación que identifiquen y bloqueen automáticamente las cadenas HTML que se asocian más comúnmente con los ataques de inyección de código. También pueden notificarle cuando las aplicaciones comienzan a exfiltrar datos cuando se supone que no deberían hacerlo o lo están haciendo en un volumen inusual, lo que ayuda a defenderse contra ataques de día cero y otras amenazas avanzadas. Un WAF no es una bala de plata, pero es una herramienta invaluable para los profesionales de la seguridad y los propietarios de sitios web que esperan proteger aplicaciones complejas.
También hay una serie de complementos que pretenden defenderse de los ataques XSS. En realidad no recomiendo estos. En lugar de reducir el riesgo, muchos de estos complementos representan solo otra superficie de ataque para que un hacker explote. Incluso uno de los complementos de seguridad más conocidos y utilizados, Akismet, resultó ser vulnerable a los ataques XSS el año pasado. Cuando se trata de desviar ataques XSS, no confíe en las medias tintas. Desarrolle las habilidades necesarias y utilice el conjunto adecuado de herramientas para mantener su sitio web seguro.
Otras aplicaciones prácticas
Esta información puede ser un poco compleja para los no iniciados, pero odiaría que la gente se desanime por las posibles complejidades de esta información. En caso de que ocurra un ataque XSS, puede estar seguro de que limpiar las consecuencias de tal evento será mucho más complejo que hacer los cambios en su sitio web. Limpiar los costos de reputación de su sitio web (los lectores habituales abandonarán su sitio web con bastante facilidad) será un problema adicional del que no querrá tener que preocuparse.
Incluso si está contratando a otra persona para que maneje el desarrollo y la seguridad de su sitio web por usted, haga lo que pueda para al menos poder responder a una emergencia y saber dónde están sus puntos débiles. Saber cómo verificar su sistema será una habilidad vital a largo plazo y será la base para otros temas de seguridad y proyectos de desarrollo de sitios web. Todo está interconectado en línea y, si bien los ataques XSS pueden ser cosa de los últimos años en el futuro (aunque esto sea poco probable), conocer los entresijos de su sitio web nunca estará desactualizado.
Pensamientos finales
El panorama de la seguridad en Internet cambia constantemente. Nunca puede estar completamente seguro de cómo podría aparecer un ataque XSS o cómo podría utilizarse en su contra, pero se lo debe a usted mismo y a sus lectores para asegurarse de que está haciendo todo lo que está a su alcance para detenerlos. Manténgase informado sobre esta amenaza y verifique regularmente (recomendaría al menos una vez al mes) cualquier desarrollo relevante en el mundo de la seguridad cibernética.
Esto tampoco significa que pueda ignorar otras amenazas. El acceso a la red pública aún requiere el uso de VPN para estar seguro. No puede descuidar la seguridad de cualquier computadora que use para acceder a su sitio web. La información de inicio de sesión aún debe cambiarse con frecuencia y estar a salvo de ataques de fuerza bruta. Los ataques XSS son brutales, pero no son la única amenaza a tener en cuenta.
También puede ser conveniente que comparta esta información (o incluso este artículo) con sus pares y partes interesadas para difundir la resistencia contra este tipo de ataques. Si bien es posible que no pueda hacer demasiado por sí mismo, si suficientes personas se protegen adecuadamente, es posible que veamos una disminución general en este tipo de ataques a medida que los piratas informáticos intentan descubrir una forma diferente de sacar provecho de los usuarios de Internet pobres.
¿Tiene alguna idea sobre cómo verificar los ataques XSS y cómo defenderse de ellos en el futuro? ¿Hay alguna otra estrategia de detección y eliminación que utilice usted mismo para luchar contra esta amenaza? ¿Hay alguna herramienta que recomendaría a sus compañeros lectores? Si es así, deje un comentario a continuación y continúe esta importante conversación con sus compañeros lectores.