Sean bienvenidos una vez más a Código Seguro, en el día de hoy estimados lectores, continuaremos hablando del apasionante mundo de la seguridad en aplicaciones y desarrollo de código seguro. Vivimos en un mundo donde cada clic, cada compra y cada mensaje que enviamos requiere que demostremos quiénes somos.
Para no tener que introducir nuestra contraseña cada dos segundos, los sistemas utilizan lo que se conoce como "pases digitales". Piensa en ellos como una pulsera de un festival: la llevas puesta, la muestras en la entrada y te dejan pasar sin tener que enseñar el documento de identidad cada vez que quieres ir al baño o comprar una bebida. Son cómodos, rápidos y permiten que todo funcione sin fricciones.
En el mundo de la tecnología, uno de los pases digitales más populares se llama JWT (que son siglas en inglés, de JSON Web Tokens). La promesa de este pase es revolucionaria: contiene toda tu información en su interior y está "firmado" de forma que el sistema confía en él ciegamente. Es como si tuvieras una carta de presentación con un sello que el portero reconoce. Pero ¿qué ocurre cuando ese sello se puede falsificar, o cuando el portero no verifica bien el sello porque está demasiado ocupado?
La realidad es que esta maravillosa herramienta, diseñada para hacer la vida más fácil a los programadores y a los usuarios, se ha convertido en el talón de Aquiles de muchas aplicaciones. No porque la idea sea mala, sino porque confiamos demasiado en que todo el mundo la usa correctamente, y la historia demuestra que los atacantes se han vuelto expertos en encontrar las rendijas por donde colarse.
El truco del mago: cambiar las reglas del juego
Imagina que te dan una tarjeta de acceso a un edificio que solo funciona si la deslizas por un lector específico. Ahora imagina que, sin que nadie se dé cuenta, le dices al lector: "Oye, en realidad, esta tarjeta funciona con el lector de la puerta de al lado", y el lector, confiado, te dice: "Vale, pues entonces déjame ver si el otro lector te acepta". Eso, traducido al mundo digital, es el error más común y peligroso con estos pases.
El sistema, por pereza o por mala programación, le pregunta al propio pase: "Oye, ¿cómo quieres que te verifique?" . Y el atacante, que ha manipulado el pase, responde: "Pues con el sistema más fácil de engañar". El problema es que a veces el sistema confunde la forma de verificar la firma y termina usando la propia información del atacante para validar el pase falso. Es como si le pidieras a un falsificador que te diga cómo comprobar si su billete es auténtico. El resultado es un desastre: el atacante puede fabricar un pase que dice ser el administrador, y el sistema, engañado, le abre todas las puertas.
Esto no es una teoría conspirativa. Ha ocurrido en bibliotecas de código que millones de desarrolladores utilizan a diario. La solución siempre es la misma: no preguntar al pase cómo quiere ser verificado, sino que el sistema debe imponer sus propias reglas. Pero, como veremos, esto es solo la punta del iceberg.
El diablo está en los detalles: instrucciones ocultas en el pase
El pase digital no solo contiene tu nombre y tu foto. Lleva, en su cabecera (como la portada de un libro), pequeñas instrucciones que le dicen al sistema cómo debe tratarlo. Y aquí es donde los atacantes se vuelven creativos.
Uno de los campos más peligrosos es el que indica qué clave usar para verificar la firma. Imagina que el sistema tiene un llavero con cien llaves, y el pase le dice: "Usa la llave número 45". Si el sistema obedece sin cuestionar, un atacante podría cambiar esa instrucción y decir: "Usa la llave número 0", o incluso, "Usa la llave que está en mi servidor". De repente, el atacante le está diciendo al sistema dónde conseguir una llave que él mismo ha fabricado para abrir la cerradura.
Esto es particularmente grave porque muchos sistemas, para ser flexibles, permiten que el pase les diga dónde descargar la llave pública desde internet. Si un atacante modifica esa dirección y la cambia por la suya propia, el sistema descargará la llave del atacante, verificará el pase falso y le dará acceso. Es como si un ladrón llamara a la puerta de tu casa y le dijera al portero: "No te preocupes, mi jefe me dijo que me dejaras pasar, llámalo a este número para confirmar", y el portero, en lugar de llamar al número real del jefe, llama al número que el ladrón le ha dado y, por supuesto, el "falso jefe" confirma que todo está bien.
La información sensible viaja en un sobre transparente
Otro error garrafal, y quizás el más fácil de entender, es que estos pases digitales, aunque están codificados para que no se lean a simple vista, no están cifrados. Es decir, cualquiera que intercepte el pase puede leer su contenido con herramientas gratuitas. Es como si enviaras tus documentos de identificación, tu número de cuenta y tu dirección en una postal en lugar de en un sobre cerrado.
Esto ha provocado que, en auditorías de seguridad, se hayan encontrado pases que contienen desde correos electrónicos y nombres completos, hasta números de seguridad social, direcciones de domicilio y, en los casos más vergonzosos, contraseñas en texto plano. El 46% de las vulnerabilidades relacionadas con estos pases se deben a que la información sensible viaja a la vista de todos. La regla de oro debería ser: en el pase, solo lo imprescindible. Como un identificador único, y el resto de la información se consulta en un lugar seguro cuando sea necesario. Pero la comodidad de tenerlo todo en un solo sitio suele ganar la batalla a la seguridad.
El problema de la caducidad: un pase robado sigue siendo válido
Pongamos que te roban la pulsera del festival. Lo lógico sería que, al reportarlo, te dieran una nueva y la antigua dejara de funcionar. Pues con estos pases digitales, eso no ocurre automáticamente. El sistema, por diseño, no guarda un registro de todos los pases que ha emitido para poder revocarlos. Simplemente confía en la fecha de caducidad que lleva el propio pase.
Si un ciberdelincuente roba tu pase, puede usarlo hasta que caduque, que a veces puede ser en días, semanas o incluso meses. Es como si, al robar tu cartera, el ladrón pudiera seguir usando tu tarjeta de crédito hasta la fecha de caducidad, aunque tú la hayas cancelado. Para solucionar esto, los sistemas tienen que implementar listas negras (un registro de pases prohibidos) o usar pases de muy corta duración que se renuevan constantemente. Pero esto añade complejidad, y muchos desarrolladores prefieren ignorarlo hasta que ocurre un incidente.
El futuro: dejar de confiar, empezar a verificar
La moraleja de todo esto no es que los pases digitales sean malos. Son herramientas fantásticas que han permitido el desarrollo de aplicaciones rápidas y escalables que usamos a diario. El problema es la confianza ciega. Confiamos en que el programador lo hizo bien, en que la biblioteca que usó es segura, en que las claves no se filtran y en que el usuario no es atacante.
El enfoque que está ganando terreno en el mundo de la ciberseguridad es el de "confianza cero". Es decir, no confiar en nada de lo que venga del exterior sin verificarlo rigurosamente. El pase dice que eres administrador, pero el sistema no se lo cree hasta que no ha verificado la firma con una clave que él conoce, no la que el pase le dice. El pase dice que caduca en 2027, pero el sistema comprueba que la fecha es razonable. El pase contiene un nombre, pero el sistema no lo usa para la autorización, sino que busca ese identificador en su propia base de datos.
La ciberseguridad, al final, es un estado de alerta permanente. Es la certeza de que alguien, en algún lugar, está intentando colarse, y nuestra única defensa es no dar nada por sentado. Los pases digitales son una solución elegante, pero su seguridad depende de que los arquitectos de sistemas recuerden que el eslabón más débil siempre es la confianza mal depositada. Por hoy nos despedimos hasta la próxima semana.