Cinco preguntas que debe hacerse antes de crear un proyecto web

Hay millones de razones por las que los proyectos tecnológicos fracasan. Modelos de negocio mal calculados, demanda sobreestimada o costos burbujeantes, lo que sea. Pero a lo largo de mi vida profesional he visto bastantes proyectos con ideas brillantes y buen potencial desmoronarse por errores y descuidos aparentemente menores. Y creo que esta razón es la más amarga de todas, al menos para mí como desarrollador. En este artículo, quiero compartir mi experiencia y analizar los problemas y desafíos que enfrentan los desarrolladores backend al trabajar en aplicaciones web. Destacaré los puntos clave que a menudo se pasan por alto y explicaré cómo abordar estos obstáculos con la máxima eficiencia. Estoy seguro de que esto le ayudará a minimizar los riesgos y aumentar significativamente las posibilidades de éxito de su proyecto.

1. ¿Hay algún secreto almacenado en tu código?

No importa lo obvio que pueda parecer, este punto es crucial: nunca almacene información confidencial o sensible en su código fuente. Las infracciones pueden provocar pérdidas financieras y otros problemas graves. La información confidencial que nunca debe almacenarse en código incluye:

• Claves API y tokens de acceso a servicios internos o externos
• Contraseñas y datos de cuentas, incluidas las contraseñas de la base de datos y del sistema de administración
• Claves de cifrado
• Archivos de configuración con datos sensibles
• Respuestas a preguntas de seguridad como el apellido de soltera de la madre o el nombre de la mascota

En lugar de almacenar dicha información en el código de su proyecto, utilice variables de entorno. Para sistemas más seguros, considere utilizar soluciones sólidas de almacenamiento secreto como Bóveda de HashiCorp . Administrador de secretos de AWS o Secretos de GitHub también puede ser útil. La elección de herramientas de almacenamiento secreto depende de factores como el tipo y tamaño del proyecto, la experiencia del equipo y la tecnología.

Si cree que almacenar información confidencial en el código de la aplicación no es un problema grave, considere esto: solo en 2022, GitHub detectó más de 1,7 millones de secretos potenciales expuestos en repositorios públicos. Imagínese cuántos datos de este tipo podrían existir en proyectos privados donde los desarrolladores desconocen las posibles filtraciones hasta que ocurren.

Solución: revisa tu proyecto ahora mismo

Si ya tiene un proyecto y ahora le preocupan los secretos de su código, existen soluciones útiles que pueden brindarle tranquilidad. Las comprobaciones manuales pueden llevar mucho tiempo, por lo que la automatización es clave. Las herramientas útiles incluyen:

• TrufaHog : busca secretos en repositorios de Git escaneando el historial de confirmaciones en busca de claves API y otros datos confidenciales.
• GitLeaks : Detecta secretos codificados como contraseñas, claves API y tokens en repositorios de git.
• GitGuardian : Opera en su entorno local o CI para encontrar más de 350 tipos de secretos y otras vulnerabilidades de seguridad.
• Seguridad avanzada de GitHub : escanea automáticamente los repositorios en busca de tipos conocidos de secretos y le avisa si se encuentra alguno.

Estas herramientas son sólo algunos ejemplos; otras opciones populares incluyen SonarQube y jaquemarx . Ambos ofrecen soluciones gratuitas y de pago para satisfacer diversas necesidades y presupuestos. El objetivo aquí no es enumerar todas las herramientas disponibles, sino resaltar la existencia de estos problemas y sus posibles soluciones. Reconocer el problema es la mitad de la batalla. Ahora bien, es importante dedicar tiempo para abordarlo y elegir las herramientas adecuadas a sus necesidades.

2. ¿Qué sabes sobre las licencias de tu biblioteca?

Sorprendentemente, este tema rara vez se trata y algunos desarrolladores ni siquiera son conscientes de que el uso de soluciones de terceros puede generar problemas legales y problemas importantes para su empresa. ¿No me crees? Imagine este escenario: un desarrollador de una pequeña empresa incluye una biblioteca distribuida bajo el Licencia pública general GNU Affero (AGPL) en un producto web comercial. Como licencia copyleft, AGPL requiere que cualquier software que utilice código publicado bajo ella se distribuya bajo los mismos términos. Esto significa que todo el código de su aplicación web, incluidos los desarrollos únicos, debe estar abierto y disponible para su uso y modificación gratuitos. Dado que nuestro producto de ejemplo es comercial, hacer que su código fuente esté disponible podría socavar gravemente la ventaja competitiva y el modelo de negocio de la empresa.

También pueden surgir problemas graves con proyectos que utilizan bibliotecas con licencias que prohíben explícitamente el uso comercial. Y la cosa no mejora mucho si no existe ninguna licencia: de hecho, la ausencia de una licencia plantea un problema importante, ya que cualquier código está protegido por derechos de autor de forma predeterminada. Las licencias otorgan a los usuarios el derecho a utilizar el código bajo condiciones específicas, pero sin una licencia, no existe ningún fundamento legal para utilizar el código, incluso si es de acceso público.

Vale la pena señalar que los problemas de licencia pueden afectarlo de diferentes maneras según su jurisdicción: este asunto es particularmente relevante para los países que han firmado acuerdos internacionales de derechos de autor. Por ejemplo, el Convenio de Berna para la Protección de las Obras Literarias y Artísticas, uno de los principales tratados internacionales en este ámbito, cuenta actualmente con alrededor de 180 países miembros. Por lo tanto, usar código sin permiso explícito significaría violar las leyes de derechos de autor y podría dar lugar a batallas legales en muchos lugares del mundo. Sin embargo, esto no significa que debas mudarte a un país "cómodo" sólo para violar todas las reglas escritas y no escritas. Respetémonos unos a otros, y si alguien no quiere que su desarrollo sea utilizado para determinados fines, es mejor que no lo haga ni siquiera desde una perspectiva humana.

Solución: utilice comprobaciones y actualizaciones automáticas

Como puede ver, las cuestiones de licencias y derechos de autor son complejas. Para protegerse a usted y a su empresa con antelación, lo mejor es comprobar las licencias de las bibliotecas y el software que utiliza. Para las bibliotecas, esto no es demasiado difícil; Los administradores de paquetes modernos ya tienen herramientas para esto. Por ejemplo, en PHP Composer, puedes hacer esto con el comando ` licencias de compositor `, en Python pasa por ` licencias-pip `, y en Golang, puedes obtener esta información a través de ` ir-licencias `.

Y no olvide llamar a estos comandos cuando actualice las dependencias (es incluso mejor automatizar estas comprobaciones), porque la licencia de una biblioteca conectada puede cambiar en las nuevas versiones.

3. ¿Está restringido el acceso a su versión de desarrollo?

En el desarrollo web, es común tener varias versiones de un proyecto, como desarrollo (dev), control de calidad (QA), puesta en escena y producción. Con frecuencia, me he encontrado con escenarios en los que cualquier persona en Internet podía acceder a las versiones de desarrollo/control de calidad y de preparación de un sitio o proyecto web. Es alarmante que a veces los motores de búsqueda puedan indexar las versiones de prueba con mayor eficacia que la versión primaria, lo que suele perjudicar al producto.

El principal problema aquí es que las versiones de prueba pueden contener errores o información confidencial, tal vez incluso comprometedora. Además, las versiones beta suelen ser más vulnerables a la piratería que la producción final. Esto significa que su disponibilidad aumenta el riesgo de que un atacante obtenga acceso a datos confidenciales, código interno o incluso al propio servidor. Esto es especialmente cierto si estás desarrollando un backend para algo como una aplicación móvil, ya que el acceso no autorizado a las versiones de prueba de la API puede ser extremadamente peligroso.

Más allá de los riesgos de seguridad, las páginas web duplicadas pueden afectar negativamente la clasificación de los motores de búsqueda. Los motores de búsqueda como Google pueden ver estos duplicados como contenido no deseado, lo que podría reducir la clasificación de las páginas originales de su proyecto o incluso eliminarlas del índice por completo.

Solución: diseñe su estrategia de seguridad desde el principio

No escatimes en dominios. Si necesita una versión de prueba accesible en línea, compre un dominio separado específicamente para ella. Esta medida simple pero efectiva reduce los riesgos de seguridad porque los atacantes generalmente verifican primero los subdominios. Alojar su versión de prueba en cualquier subdominio del recurso principal lo convierte en un objetivo fácil.

Restrinja el acceso a todas las versiones de prueba. Asegúrese de que las versiones de desarrollo, control de calidad, preparación y otras versiones no sean de acceso público. Configúrelos para que sean accesibles solo a través de una VPN, por ejemplo. Esto reduce la probabilidad de acceso no autorizado, incluso si los actores malintencionados conocen el dominio de prueba.

Proteja las versiones de prueba para que no sean indexadas. Incluso si solo se puede acceder a sus versiones de prueba a través de VPN y están alojadas en dominios secretos separados, protéjalas de la indexación de los motores de búsqueda utilizando un archivo `robots.txt` o metaetiquetas `noindex`. Este paso es crucial, ya que los motores de búsqueda a veces pueden encontrar e indexar estas páginas de formas inesperadas.

4. ¿Está oculta tu dirección IP real? ¿Están cerrados los puertos no utilizados?

Hay reglas de seguridad que muchos desarrolladores tienden a pasar por alto, aunque son de vital importancia y se han establecido a través de lecciones aprendidas con mucho esfuerzo. Una de esas reglas es ocultar siempre la dirección IP real de su proyecto. Si la dirección IP de sus servidores se puede determinar a través del nombre de dominio, puede generar varios problemas, como:

• Ataques DDoS: al conocer la dirección IP real de su proyecto, los atacantes pueden lanzar un ataque de denegación de servicio distribuido (DDoS) en su servidor. Por ejemplo, un Amplificación de reflexión DNS Un ataque podría saturar su servidor con un volumen masivo de respuestas de servidores DNS públicos, haciendo que su servicio no esté disponible para los usuarios y causando pérdidas financieras significativas.

  
  

• Identificación de posibles vulnerabilidades: los piratas informáticos serios, no sólo los aficionados, pueden escanear puertos abiertos y software expuesto en la red para encontrar y explotar debilidades. Incluso servicios conocidos como MongoDB han sufrido importantes violaciones de datos debido a una mala configuración. Muchos de estos problemas podrían evitarse simplemente ocultando la dirección IP real.

Solución: complicar la vida del atacante potencial

Al ocultar la dirección IP real de su servidor, hace que sea mucho más difícil para los atacantes atacar su sistema. El uso de una red de entrega de contenido (CDN) o servicios de protección DDoS puede resultar muy eficaz en este caso. Las opciones populares incluyen nubeflare , que ofrece capacidades CDN y protección DDoS de forma gratuita, así como servicios como Imperva (anteriormente Incapsula) que proporciona funciones similares y Qrador , que se especializa en proteger aplicaciones web con un Firewall de aplicaciones web, pero esto puede generar costos.

Si bien estas herramientas pueden mejorar significativamente la seguridad, hay consideraciones adicionales a tener en cuenta:

• Fuga de IP del encabezado del correo electrónico: si utiliza su servidor principal para enviar correos electrónicos, la dirección IP real puede quedar expuesta en los encabezados del correo electrónico, lo que arruinará sus esfuerzos de seguridad.

  
  

• Historial de IP y solicitudes de Whois: servicios como Historial de DNS o Solicitud Whois puede revelar las direcciones IP históricas asociadas con un dominio. Si su IP real alguna vez estuvo vinculada a su dominio de trabajo, debe cambiarla.

  
  

• Protección DDoS y puntos finales API: tenga cuidado al utilizar la protección DDoS para dominios que sirven como puntos finales API. Los sistemas de protección pueden introducir pasos de verificación de usuario que podrían interrumpir el funcionamiento de sus aplicaciones del lado del cliente al reemplazar las respuestas JSON/XML con código HTML.

  
  

• Solicitudes de API salientes: cuando su servidor envía solicitudes a API de terceros, puede revelar inadvertidamente su dirección IP. El uso de servidores proxy para dichas solicitudes puede ayudar, ya que cambiar un proxy es más fácil que lidiar con las consecuencias de un ataque.

Es importante recordar que ocultar la dirección IP real de su proyecto no es una panacea. Cerrar los puertos utilizados por su software desde la red externa es crucial siempre que sea posible. Cambiar los puertos estándar es una práctica discutible; algunos expertos argumentan que complica la configuración sin beneficios significativos. A menudo, es preferible configurar el software para interactuar a través de sockets Unix en lugar de conexiones de red TCP (si tanto su proyecto como el software se ejecutan en el mismo servidor). Este enfoque no sólo aumenta la velocidad de interacción sino que también mejora la seguridad al eliminar la necesidad de puertos abiertos.

Para sistemas de administración de bases de datos (DBMS) u otros servicios internos en servidores separados, asegúrese de que el acceso esté restringido a direcciones IP específicas que usted controle estrictamente. Esta configuración evita el acceso no autorizado a sistemas críticos, agrega una capa de seguridad adicional y minimiza los riesgos de ataques externos y fugas de datos.

5. ¿Actualizan las dependencias y el software del proyecto?

Este consejo es bastante sencillo pero, una vez más, a menudo se pasa por alto: actualice periódicamente las dependencias y el software del servidor de su proyecto. El código obsoleto y vulnerable es el sueño de los atacantes que pueden explotarlo fácilmente.

Solución: automatice sus actualizaciones

No es necesario actualizar todo manualmente; Muchas herramientas de automatización pueden ayudar. Por ejemplo, robot dependiente en GitHub detecta automáticamente dependencias obsoletas o vulnerables y sugiere actualizaciones.

Automatizar la renovación de los certificados de seguridad también es crucial. Si utiliza Vamos a cifrar certificados, puedes automatizar su renovación con Certbot . Los certificados caducados pueden causar verdaderas molestias, pero automatizar su renovación es una tarea sencilla.

\El mismo principio se aplica al software de servidor. Si está trabajando con Linux, especialmente distribuciones basadas en Debian/Ubuntu, Actualizaciones desatendidas puede manejar fácilmente la tarea. Para proyectos más grandes con muchos servidores, herramientas como ansible , Cocinero , Marioneta , o Sal están disponibles.

Pensamientos finales

Los consejos que se proporcionan aquí son sólo una fracción de lo que los desarrolladores de backend deben recordar. Elegí resaltar temas cruciales pero que se discuten con menos frecuencia en comparación con los comunes como inyección SQL o CSRF ataques.

Para una comprensión más profunda de la seguridad de las aplicaciones web, considere explorar el Fundación OWASP , una organización sin fines de lucro que ofrece recursos valiosos. El Los diez mejores de OWASP El documento, disponible en su sitio web, enumera los riesgos de seguridad de aplicaciones web más comunes y críticos. También encontrará información sobre ataques menos conocidos pero igualmente peligrosos.

Creo que la comunidad de desarrolladores debería estar bien informada y ser solidaria a la hora de compartir ideas y experiencias. Por lo tanto, invito a todos a compartir sus observaciones y comentarios, ¡que son valiosos para todos los que trabajan en el desarrollo backend!