La programación web es un mundo complejo e inseguro. La seguridad de nuestra aplicación depende de muchos factores que debemos tener en cuenta, desde la seguridad del servidor donde se aloja, hasta las técnicas de programación empleadas en esta.
Una de las vulnerabilidades que más se ha explotado útimamente han sido las basadas en ataques XSS (Cross Site Scripting), que consiste en inyectar código malicioso en un sitio web para que se ejecute automáticamente al abrirlo en el navegador.
Imagina por un momento que eres un Webmaster de una comunidad de usuarios y utilizas el CMS Joomla para administrarla. Imagina que usas un componente de terceros para administrar los roles de usuarios, etc.. algo muy común. Un buen día llegas a casa y abres una sesión como administrador de tu sitio, y te quedas logueado con la pestaña abierta. Ahora abres otra pestaña, y en esta pestaña hay un código Javascript que hace algo como lo siguiente:
window.location.href= "http://tuSitioJoomla/administrator/index2.php?option=com_users&task=deleteall..."
Al estar logueado como administrador, si el componente no está debidamente protegido es posible que llegue a borrar todos los datos de nuestros usuarios, y nuestra amada comunidad se irá al garete en menos que canta un gallo. Si encima, estó lo combinamos con una política de copias de seguridad insuficiente o inexistente, nos encontraremos ante una situación bastante dificil de resolver y que seguro que nadie le gustaría vivir.
Esta técnica de construir consultas maliciosas aprovechandose de la sesión de un administrador es una rama del XSS denominada como CSRF(Cross Site Request Forgery).
Para evitar estos problemas de seguridad, el API de Joomla proporciona unos métodos interesantes cuya finalidad es comprobar que la petición se ha realizado desde un sitio seguro, y no la está relizando cualquiera. Estos métodos generan un Token, (en español testigo) que es único para cada sesión que se genera en el servidor. Este token es un conjunto de carácteres generados en base a tu dirección IP, hora y algunos parámetros variables, con el fin de dificultar o imposibilitar la recreación del mismo token por el atacante (que académico me ha quedado este párrafo 😉 ). Cuando recibamos los datos en el servidor, deberemos comprobar que el testigo se encuantra intacto en la petición, y que por lo tanto se puede garantizar la autenticidad de la petición, es decir, que esta petición la hemos generado nosotros y no la ha generado un script malintencionado. La implementación con el API de Joomla es muy sencilla. Si no tienes conocimientso sobre el API de Joomla es recomendable que te leas los tutoriales sobre desarrollo de extensiones en Joomla.
Método POST
Tenemos el siguiente formulario:
Mediante el siguiente código:
se genera el token, que valida que realmente es el usuario el que ha enviado la petición. Después, en el task, se valida que el token sea correcto. El token, en este caso es un campo de tipo hidden con una cadena de caracteres aleatoria para cada sesión. 
function enviarEmail(){
JRequest::checkToken() or die( 'Token invalido' );
echo "email enviado!!";
}
Si todo a funcionado correctamente, se mostrará un mensaje por pantalla indicando que el email a sido enviado correctamente. En caso de que la petición haya sido creada desde un sitio diferente que no sea la página de administración de Joomla aparecerá un mensaje advirtiendonos que el Token es invalido, y se interrumpirá la aplicación. La comprobación la realiza el método checkToken, que genera el mismo Token y lo compara con el que viene desde el cliente, en caso de ser diferentes se cancela la ejecución del script.
Método GET
Para usar los tokens con el método GET se hace usando el objeto JUtility. A continuación se muetsra el código de una típica tabla donde se muestra una lista de usuarios con enlaces para borrar cada usuario, muy tipico.
| David | Eliminar |
| Pepe | Eliminar |
| Juan | Eliminar |
La orden de borrar se envía al task eliminar. A continuación se muestra el código.
function eliminar(){
JRequest::checkToken( 'get' ) or die( 'Token invalido' );
echo "Usuario eliminado!!";
}
Una vez introducida la protección en el task, si alguien intenta enviar una dirección del estilo «index.php?option=com_prueba&task=eliminar&usuario=Juan», obtendrá el mensaje «Token invalido», de hecho, si intentas eliminar a Juan, como no se le ha introducido el token, dará error y no será borrado.
Conclusión
Usando este método solventaremos casi todos los problemas de Cross Site Request Forgery y spoofing que nos podamos encontrar, y es muy recomendable (yo diría que obligado) utilizar está tecnica, que resulta muy sencilla y fácil de implementar. Descargar código de componente con el ejemplo.