Recomendaciones básicas de seguridad en desarrollo

Hace unos días, leyendo un tweet en X, leí a una persona que denunciaba que le habían robado todas las cryptomonedas que tenía en su wallet. Esta persona es alguien técnica (se dedica a la informática profesionalmente), es decir, con conocimientos informáticos suficientes como para no haber sufrido nunca a nivel de seguridad a este nivel. En este tweet (que podéis ver abajo), explica paso a paso qué le ha ocurrido y cómo evitar que nos pase a los demás:

La lectura está orientada principalmente al tema crypto (criptomonedas y trading de monedas digitales) no obstante, como siempre me gusta ver los problemas desde varios ángulos, me dí cuenta de un problema que posiblemente a alguien más le puede ocurrir, y si con esta llamada de atención se pueden hacer algunos cambios que mejoren la seguridad de todos, mucho mejor… 😉

Resumiendo el enorme hilo (que recomiendo leer completamente), una extensión (del interfaz de desarrollo Cursor) logró acceder al archivo .env, enviar su clave privada al atacante y éste vació su wallet en cuestión de horas. La pérdida fue poca (apenas unos cientos de dólares), pero éste incidente evidencia cómo incluso los más cuidadosos pueden caer en ataques de cadena de suministro.

Hay que decir que se recomiendan que las contraseñas se almacenen en variables de entorno, por lo que un .env es un sitio habitual donde se almacenan estos valores, no obstante hoy día, para aplicaciones con contraseñas importantes y muy sensibles, se recomienda utilizar aplicaciones como:

• HashiCorp Vault (software libre)
• AWS Secrets Manager
• Google Secret Manager

Estos sistemas permiten almacenar de forma segura usuarios y contraseñas a la vez que generan tokens temporales para poder acceder a ellos de forma segura y cifrada. De esta manera, un atacante no tendría acceso más que a un token de un servicio y no a nuestros datos de acceso críticos.

Uno de los puntos en los que cualquier sistema de desarrollo seguro hace referencia es en la necesidad de «separar entornos«: Esto es: disponer de un entorno de desarrollo, completamente separado del entorno de pruebas y completamente diferente al entorno de producción (además, de otros posibles entornos gemelos y separados 100% para calidad, testeo, etc.). Esto implica que cada entorno debe tener autorizaciones diferentes para que, tanto el desarrollador, como el resto de personas que participan en el desarrollo no tengan nunca acceso a los datos de configuración de producción.

Por lo tanto y resumiendo un poco… hay que tener en cuenta las recomendaciones:

• No almacenar claves en .env,
• Verificar la autenticidad del autor del software y de las extensiones que utilicemos,
• Usar exclusivamente carteras frías para fondos importantes,
• Auditar extensiones,
• Separar entorno de trabajo para hacerlos mucho más seguro,
• Vigilar periódicamente todo…

Siempre he dicho que «la seguridad es contraria a la comodidad«. Normalmente trabajamos para solucionar y hacer la vida más sencilla a los usuarios, pero al añadir «seguridad«, esa «sencillez» a veces se transforma en «incomodidad«, no hay más que ver un ejemplo de que, para acceder a cualquier sitio de forma segura, tenemos que acceder utilizando la verificación en dos pasos, y para ello es necesaria una aplicación OTP (One Time Password) lo que implica abrir una aplicación externa (además de introducir usuario/contraseña) algo que no es precisamente cómodo.

Aún así, los que trabajamos en la trinchera, desarrollando soluciones, a veces tenemos que tomar más medidas de seguridad y trabajar con más incomodidades de las habituales en pos de la seguridad tanto del proyecto como del resto de proyectos de la empresa.

Siempre que alguien trabaja y protege su sistema únicamente con usuario contraseña me acuerdo de que:

• La gran mayoría de personas reutilizan sus contraseñas en algunos o en todos los servicios…
• Alguno de los servicios han sido atacados obteniendo datos como usuarios, contraseñas, etc… https://haveibeenpwned.com/
• Una contraseña cifrada puede ser descifrada en cuestión de…

Así que… si alguna vez piensas: ¿debería hacer esto para aumentar la seguridad? la respuesta es siempre SI. Mejor pecar de paranoico a que te roben lo que sea… y es que, el objetivo final es que no nos ocurra algo similar a lo que le ha ocurrido a este hombre. ¿o no?