Este artículo forma parte de la serie Cross-Site Scripting en WordPress. Siguiente artículo de la serie: Cross-Site Scripting en WordPress: consejos prácticos para la seguridad de su sitio
Uno de los aspectos más interesantes del actual desarrollo web es el potencial que lleva aparejada la creación de aplicaciones específicas para los navegadores web (o que se ejecutan «en la nube»).
Originalmente, Java fue una solución concebida para «ser escrita una vez, y después susceptible de ejecutarse en cualquier lugar», y parece que la web se ha convertido en el medio perfecto para eso. ¿Quién lo habría pensado, verdad?
Pero junto con los distintos navegadores que tenemos disponibles, las tecnologías que podemos usar y, sencillamente, las prácticas cosas que podemos hacer, todavía existe un lado oscuro en el desarrollo de aplicaciones web, el cross-site scripting. Y teniendo en cuenta que WordPress es una aplicación web sobre la que muchos de nosotros construimos simplemente por entretenimiento, ya sea para obtener algún beneficio, o para ganarnos la vida, es un tema que no debemos olvidar, especialmente si queremos conseguir que nuestros productos sean tan sólidos como sea posible.
En esta serie que consta de dos partes, vamos a echar un vistazo a lo que es realmente el cross-site scripting, sus peligros y cómo afecta al desarrollo con WordPress, después veremos pasos prácticos que podemos realizar para comprobar la seguridad de nuestros temas y plugins.
¿Qué es cross-site scripting?
Cross-site-scripting, comúnmente abreviado por sus siglas como XSS, se define en la Wikipedia como lo siguiente:
XSS permite a los intrusos que pretenden atacar un sitio, inyectar scripts del lado del cliente en las páginas web vistas por otros usuarios. Una vulnerabilidad de secuencias de comandos entre sitios puede ser usada por los atacantes para eludir los controles de acceso como la política del igual origen.
Creo que esta definición es útil si estás familiarizado con las clases de vulnerabilidades, la política de un mismo origen, y con lo que constituye verdaderamente una inyección de script del lado del cliente, pero, para muchos, simplemente no es suficiente.
Creo que esta definición es útil si estás familiarizado con las clases de vulnerabilidades, la política del mismo origen, y lo que constituye verdaderamente una inyección de comandos del lado del cliente, pero, para muchos, simplemente no es suficiente.
Así que echemos un vistazo al cross-site scripting de arriba a abajo antes de continuar.
Comprender las secuencias de comandos del lado del cliente
Las secuencias de comandos del lado del cliente consisten básicamente en cualquier código que es ejecutado en el cliente de un sitio o aplicación web. Indiscutiblemente, los comandos más populares del lado del cliente son las funciones JavaScript. Por el contrario, PHP sería considerado un comando del lado del servidor.
Otra manera de verlo es la siguiente: las secuencias de comandos de lado del cliente se envían desde el servidor al ordenador del usuario cuando se carga la página web. Y después se ejecuta el comando o script. A veces se emplea para hacer algo tan simple como animar un menú.
Otras veces, puede realizar algo más complejo, como hacer una llamada asíncrona al servidor, recuperar algunos datos basados en la ubicación de los usuarios y adaptar la información que estos verán según donde estén localizados.
Aunque esto podría usar la información relativa a la ubicación proporcionada por el navegador, todavía es algo seguro, ya que el navegador mantiene los datos y la información que está siendo obtenida basándose en la información disponible de forma pública.
Entonces, ¿qué es una inyección de secuencia de comandos?
Tal vez una mejor denominación para «inyección de secuencia de comandos» sería «inyección de código».
El atacante busca literalmente algún tipo de elemento de entrada en tu sitio web, esto podría ser desde un campo de búsqueda a un campo de contacto o un campo de nombre o cualquier otro elemento que envíe datos a un servidor. Esto se hace normalmente mediante el uso de un script, a veces es JavaScript malicioso, pero los atacantes pueden conseguirlo también insertando comandos PHP o MySQL.
Por último, hablamos del ataque como «inyección» porque si el atacante tiene éxito, inyecta o introduce literalmente su propio código en tu aplicación.
Y ¿qué es esta «política del mismo origen»?
El concepto de una política del mismo origen es simple: Es una norma que cumplen los navegadores para básicamente permitir el uso de secuencias de comandos del lado del cliente, por ejemplo, permite usar JavaScript, para realizar solicitudes a otras páginas y scripts del lado del servidor ubicados dentro de un mismo servidor (o, dentro de un mismo origen), pero no permite solicitudes hacia otros dominios o sitios.
Por ejemplo, podrías configurar una función JavaScript para realizar una llamada desde tutsplus.com a wordpress.com, recuperar datos y luego mostrarlos en la web tutsplus.com. Pero esto violaría la política del mismo origen.
Ahora, como aclaración, esto no quiere decir que no se pueda hacer. Mediante la combinación de funciones creativas del lado del cliente y de llamadas del lado del servidor, se pueden lograr cosas, pero los navegadores hacen todo lo posible para evitar que los scripts del lado del cliente lo consigan realmente.
¿Por qué es peligroso?
En este punto, las implicaciones deberían estar bastante claras. Las vulnerabilidades producidas mediante secuencias de comandos o scripts entre sitios pueden proporcionar control sobre nuestros sitios y aplicaciones web a los visitantes maliciosos, de manera que al final podríamos no ser capaces de administrarlos.
Por ejemplo, su gravedad puede variar, desde poca a gran importancia con consecuencias más críticas:
- Los atacantes pueden ser capaces de acceder a la base de datos e insertar en ella información que luego sea visible a los futuros visitantes
- Los atacantes pueden ser capaces de acceder a información relativa a la sesión, secuestrarla y suplantar a un usuario
- Los atacantes podrían recuperar información financiera sensible
- Los atacantes pueden hacer todo lo anterior y luego tumbar una web por completo
- … Y mucho más
Todo esto depende de las características que ofrezca el sitio y de su nivel real de seguridad.
Cualquiera que sea el caso, la seguridad de las aplicaciones web es algo que está aquí para quedarse. Concedido, creo que cada cual debería especializarse en su campo respectivo, y que los especialistas en seguridad son las personas a las que debemos consultar antes de iniciar una aplicación web que pueda contener información sensible, pero eso no significa que no podamos estar familiarizados con algunas estrategias básicas para realizar nuestras propias pruebas.
Lo que te queda por leer:
- Cómo afecta esto al desarrollo con WordPress
- Qué podemos hacer al respecto
Deja una respuesta