Saltar al contenido principal

Asegurar proyectos basados en la web

Cualquier aplicación que gestione criptomonedas es un objetivo frecuente de actores malintencionados y debe seguir las mejores prácticas de seguridad. La siguiente lista de verificación ofrece orientación sobre las vulnerabilidades más comunes. Sin embargo, incluso si sigues todos los consejos, la seguridad no está garantizada. La seguridad web y los actores maliciosos están en constante evolución, por lo que es bueno mantener una saludable dosis de paranoia.

SSL/TLS

Asegúrate de que TLS esté habilitado. Redirige HTTP a HTTPS donde sea necesario para garantizar que no ocurran ataques Man in the Middle y que los datos sensibles se transfieran de forma segura entre el cliente y el navegador. Habilita TLS y obtén un certificado SSL gratis en LetsEncrypt.

Si no tienes SSL/TLS habilitado, detén todo y haz esto primero.

Encabezados de política de seguridad de contenido (CSP)

Los encabezados CSP indican al navegador desde dónde puede descargar recursos estáticos. Por ejemplo, si tu sitio es astralwallet.io y solicita un archivo JavaScript desde myevilsite.com, tu navegador lo bloqueará a menos que haya sido incluido en la lista blanca mediante encabezados CSP. Puedes leer cómo implementar los encabezados CSP aquí.

La mayoría de los frameworks web tienen un archivo de configuración o extensiones para especificar tu política CSP, y los encabezados se generan automáticamente para ti. Por ejemplo, mira Helmet para Node.js. Esto habría prevenido el Blackwallet Hack.

Encabezados HTTP strict-transport-security

Este es un encabezado HTTP que indica al navegador que todas las conexiones futuras a un sitio en particular deben usar HTTPS. Para implementarlo, añade el encabezado a tu sitio web. Algunos frameworks web (como Django) tienen esto incorporado. Esto habría prevenido el MyEtherWallet DNS Hack.

Almacenar datos sensibles

Idealmente, no necesitas almacenar muchos datos sensibles. Si debes hacerlo, asegúrate de proceder con cuidado. Existen muchas estrategias para almacenar datos sensibles:

  • Asegúrate de que los datos sensibles estén cifrados usando un cifrado probado como AES-256 y almacenados separadamente de los datos de la aplicación. Siempre elige el modo AEAD.
  • Toda comunicación entre el servidor de la aplicación y el servidor secreto debería estar en una red privada y/o autenticada mediante HMAC. Tu estrategia de cifrado cambiará dependiendo de si enviarás el texto cifrado múltiples veces por la red.
  • Haz respaldos offline de cualquier clave de cifrado que uses y guárdalas solo en la memoria de tu aplicación.
  • Consulta a un buen criptógrafo y estudia las mejores prácticas. Consulta la documentación de tu framework web favorito.
  • Crear tu propia criptografía es una mala idea. Usa siempre librerías probadas y testadas como NaCI.

Monitoreo

Los atacantes a menudo necesitan tiempo para explorar tu sitio en busca de comportamientos inesperados o pasados por alto. Examinar los registros defensivamente puede ayudarte a detectar qué intentan lograr. Al menos puedes bloquear su IP o automatizar el bloqueo basado en comportamientos sospechosos.

También vale la pena configurar un reporte de errores (como Sentry). A menudo, las personas desencadenan errores extraños al intentar hackear.

Debilidades en la autenticación

Debes construir tu autenticación de manera segura si tienes inicios de sesión para usuarios. La mejor forma de hacerlo es usar algo ya disponible. Tanto Ruby on Rails como Django tienen esquemas robustos y incorporados de autenticación.

Muchas implementaciones de JSON web token están mal hechas, así que asegúrate de que la librería que uses esté auditada.

Hashear contraseñas con un esquema probado es bueno. También vale la pena investigar el Balloon Hashing.

Preferimos firmemente 2FA y requerimos 2FA U2F o TOTP para acciones sensibles. El 2FA es importante ya que las cuentas de correo electrónico suelen no ser muy seguras. Tener un segundo factor de autenticación asegura que los usuarios que accidentalmente se queden conectados o cuyo password sea adivinado sigan protegidos.

Finalmente, requiere contraseñas fuertes. Contraseñas comunes y cortas pueden ser forzadas por ataques de fuerza bruta. Dropbox tiene una gran herramienta de código abierto que mide la fortaleza de las contraseñas de manera bastante rápida, haciéndola útil para la interactividad con usuarios.

Ataques de denegación de servicio (DOS)

Los ataques DOS usualmente se logran sobrecargando tus servidores web con tráfico. Para mitigar este riesgo, limita el ritmo de tráfico desde IPs y huellas digitales del navegador. A veces las personas usarán proxies para evadir la limitación de velocidad de IP. Al final, los actores maliciosos siempre pueden encontrar formas de falsificar su identidad, así que la forma más segura de bloquear ataques DOS es implementar verificaciones de prueba de trabajo en tu cliente o usar un servicio gestionado como Cloudflare.

Bloquea puertos no usados

Los atacantes a menudo escanean tus puertos para ver si fuiste negligente y dejaste alguno abierto. Servicios como Heroku hacen esto por ti- lee cómo habilitar esto en AWS.

Phishing e ingeniería social

Los ataques de phishing socavan cualquier infraestructura de seguridad bien creada. Ten políticas claras publicadas en tu sitio web y explícalas a los usuarios cuando se registren (nunca pedirás su contraseña, etc.). Firma mensajes a tus usuarios y pídeles que verifiquen el dominio del sitio web en el que están.

Escanea tu sitio web y las librerías en busca de vulnerabilidades

Usa una herramienta como Snyk para escanear las librerías de terceros de tu cliente en busca de vulnerabilidades. Asegúrate de mantener actualizadas tus librerías de terceros. A menudo, las actualizaciones son provocadas por exploits de seguridad. También puedes usar Mozilla Observatory para comprobar la seguridad HTTP de tu sitio.

Protección contra Cross-Site Request Forgery (CSRF), inyecciones SQL

La mayoría de los frameworks web y móviles modernos manejan tanto la protección CSRF como las inyecciones SQL. Asegúrate de que la protección CSRF esté habilitada y de usar un ORM de base de datos en lugar de ejecutar SQL sin procesar basado en la entrada del usuario. Por ejemplo, consulta qué dice la documentación de Ruby on Rails sobre las inyecciones SQL.