Nota del autor

Si la entrada que estás leyendo carece de imágenes, no se ve el vídeo que teóricamente lleva incrustado o el código fuente mostrado aparece sin formato, podéis conocer los motivos aquí. Poco a poco iré restableciendo la normalidad en el blog.
Este blog es un archivo de los artículos situados previamente en Lobosoft.es y ha dejado de ser actualizado. Las nuevas entradas pueden encontrarse en www.lobosoft.es. Un saludo,
Lobosoft.

martes, 23 de diciembre de 2008

Disponibilidad, nula

La seguridad informática es una disciplina que se dedica a proteger la confidencialidad, integridad y disponibilidad de la información. Para conseguir todo esto, habitualmente se realizan inversiones de mayor o menor índole en la empresa y se contrata a empresas dedicadas a dar soporte y auditar los procesos de la compañía. Pero pocas veces se forma adecuadamente al personal propio, o se le dan unas mínimas directrices a seguir cuando se produce algún problema y ha de seguirse un protocolo que minimice las pérdidas de información y, por ende, pecuniarias.
La semana pasada me encontré con ante un caso así, en el que los servicios on-line que ofrece una conocida Caja del sur de España permanecían indisponibles durante tres días consecutivos. Y lo más grave no fue esto, sino que hacían caso omiso a los clientes cuando daban aviso de la incidencia. Pero permitidme que os cuente la historia completa, desde la perspectiva que pude vivir en primera persona.
Esta “Caja del sur”, llamémosla X, ofrece como tantas otras entidades bancarias diversos servicios a través de Internet, desde la consulta de saldo y movimientos de las cuentas y tarjetas que poseamos en la misma, como la realización de transferencias, gestión de recibos, etc. Hasta ahí, lo normal. El pasado martes (hace, por tanto, una semana exacta) intenté consultar los movimientos de mi cuenta, para ver si había sido adeudada una cantidad determinada. Sin embargo, el acceso no era posible. Tras intentar acceder a la zona de la web en la que hacer login, ésta quedaba totalmente en blanco sin aparecer el formulario de autenticación. Lo dejé estar, porque tampoco me urgía, y terminé por olvidar el asunto.


Un día después, mi pareja me comentaba que no podía acceder a su cuenta, precisamente por obtener el mismo problema. Era tarde, por lo que únicamente les escribió un correo electrónico indicando el problema, pero cuál no sería la sorpresa al constatar, un día después, que la respuesta del servicio de asistencia de la Caja era, básicamente, el siguiente: “A nosotros nos funciona. Limpie las cookies y si no se soluciona el problema, pruebe a reinstalar su Internet Explorer”. Mi pareja, comprensiblemente indignada, les indicó que el problema se reproducía con Firefox y, de paso, también con Explorer. También que usamos a diario CCleaner y el ordenador está limpio, de una sesión a otra, como una patena.





Vaya, con la iglesia hemos topado. ¿Qué YO reinstale mi navegador? ¿Por un problema que se reproduce en tres ordenadores distintos, con tres navegadores distintos en cada uno de ellos (ya puestos, incluí a Chrome en el juego ya que, no os comenté, Google lo sacó de beta la semana pasada), con distintas conexiones a Internet? Molesto por la respuesta que ofrecía la entidad, decidí echar un vistazo a ver qué podía estar ocurriendo. Lo primero fue constatar que las cookies se descargaban correctamente, así como el certificado digital que daba acceso a sus servicios. Hasta ahí, todo correcto. Descargo los ficheros Javascript asociados a la página sin ningún problema, y les echo un vistazo. Vaya, contienen código encargado de la validación del usuario y el control de las cookies. Bueno, vamos a depurar. Accedo a la página con Chrome, habilitando el inspector de recursos. Et voilà: error en la carga de uno de ellos, acceso.js. Ay amiguitos, que estáis usando una variable sin declararla. Habilito el depurador Javascript, y comienzo la ejecución paso a paso del código. Para entonces ya había visto que el archivo contenía una rutina de inicialización consistente, básicamente, en llamar a tres funciones:


recogida_parametros();
analytics();
entrada();


El error está dentro del código de analytics(), donde han incluido funciones de seguimiento de Google. Al depurar ocurría exactamente lo que preveía: se produce el error, y al tratarse de una excepción no controlada el javascript no sigue ejecutándose, lo que provoca que nunca se llame a la función entrada(), que se encarga de hacer un submit automático del formulario y cargar el de login que, por tanto, nunca era mostrado.



Comprobado esto, escribí un correo a la entidad, explicando el proceso seguido, y con varias capturas adjuntas del error. Me contestaron agradeciendo el aviso, e indicando que efectivamente el martes habían hecho cambios y mejoras en la web. Diez minutos después la página estaba nuevamente operativa, pero a su vez tres días después de dar servicio.


Lo grave de todo esto, obviamente, no estuvo en el error en sí (que también), sino en la poca disposición a comprobar lo que los clientes están informando. ¿Qué pueden hacer las empresas para asegurar la disponibilidad de los servicios si sus propios empleados no llevan a cabo correctamente su trabajo? ¿Es realmente necesario que “alguien de fuera” tenga que darles mascado un trabajo tan simple que puede ser depurado y comprobado sin ningún tipo de privilegio sobre el sistema? Mi confianza en esta entidad se ha dañado irremisiblemente, pero esto no es lo malo. Lo malo será que no la recomendaré a nadie, y posiblemente cancele mis cuentas y recomiende hacer lo mismo a mis allegados. Lo malo es que sé que esto no habrá servido de mucho y seguirán haciendo mal su trabajo. Lo peor será que, por regla general, son muchas las empresas que trabajan así. Y en el caso de los bancos, bastante respaldo gubernamental están recibiendo como para que sigan de espaldas a la gente. A sus clientes, reales o potenciales.

No hay comentarios:

Publicar un comentario