Tema: Aprende cómo crear y desplegar un CRM moderno utilizando IA Studio, Supabase, GitHub y Render paso a paso. Asimismo, descubre con el Vibe Coding y la inteligencia artificial permiten agilizar el desarrollo web, automatizar procesos y construir aplicaciones modernas de manera más rápida y eficiente.| Tiempo de lectura estimado: 20 minutos

INTRODUCCION

La inteligencia artificial ha transformado el desarrollo de software moderno, permitiendo automatizar procesos que anteriormente requerían largos tiempos de programación y configuración manual. Actualmente, herramientas como IA Studio facilitan la creación de aplicaciones mediante prompts inteligentes, agilizando el desarrollo de plataformas empresariales de manera rápida y eficiente.

Este enfoque se relaciona con el Vibe Coding, una metodología de programación asistida por inteligencia artificial donde el desarrollador describe funcionalidades en lenguaje natural y la IA genera parte del código, estructuras y configuraciones necesarias. Esto permite enfocarse más en la lógica del negocio y reducir tareas repetitivas de programación.

En este proyecto se desarrolló un CRM médico utilizando IA Studio, Supabase, GitHub y Render, con el propósito de demostrar cómo la inteligencia artificial puede mejorar el desarrollo web y fortalecer la administración de aplicaciones modernas.

Durante el desarrollo se realizaron configuraciones de bases de datos, integración de variables de entorno, publicación del código en GitHub y despliegue en Render. Además, se solucionaron errores relacionados con autenticación y creación de usuarios, fortaleciendo la seguridad y funcionalidad del sistema.

El uso de IA permitió acelerar el desarrollo de componentes frontend y backend, mejorar la productividad y facilitar la implementación del proyecto, evidenciando cómo el Vibe Coding está transformando la manera en que se construyen aplicaciones modernas.

¿Qué es IA Studio y por qué es importante?

IA Studio es una herramienta basada en inteligencia artificial que permite generar aplicaciones web utilizando instrucciones o prompts personalizados. Su importancia radica en la automatización del desarrollo, reduciendo tiempos de programación y facilitando la integración con tecnologías modernas.veamos la informacion aqui.

Beneficios principales de IA Studio

Automatización del desarrollo

• Permite generar código automáticamente utilizando inteligencia artificial.

Integración rápida

• Facilita la conexión con servicios externos como bases de datos y plataformas cloud.

Optimización del tiempo

• Reduce significativamente el tiempo de construcción de aplicaciones.

Escalabilidad

• Permite crear proyectos modernos y preparados para futuras mejoras.

Creación de la base de datos en Supabase

1. Empezamos creando una base de datos en SupaBase para el proyecto. Creamos la cuenta de SupaBase y la base de datos que va a usar IA Studio para crear el proyecto.

Generación del prompt utilizando ChatGPT

1. Se le pidió a ChatGPT que creara un prompt para IA Studio, se le dieron unos parámetros (incluyendo la base de datos creada anteriormente con su nombre y contraseña) y nos dió el siguiente prompt: PROMPT IA Studio

Construcción automática del CRM con IA Studio

1. Una vez teniendo el prompt se lo dimos a IA Studio para que empezara el proceso.

Login de usuarios

Luego de unos minutos cargando, IA Studio nos pidió una variables de entorno para conectar el CRM con SupaBase.

Gestión de cuentas

Estas variables se obtuvieron desde la misma página de SupaBase de la siguiente forma: para DATABASE_URL, dentro del proyecto se debe ir a la sección “Direct” y copiar el “Connection string”. Luego, se reemplaza “[YOUR-PASSWORD]” por la contraseña real de la base de datos.

Para SUPABASE_URL, en la página principal del proyecto se puede visualizar la URL, la cual debe ser copiada directamente.

Para SUPABASE_ANON_KEY, se obtiene desde la página principal accediendo a configuración o “Settings”, luego a “API Keys”. Dentro de esta sección, se debe ir a “Legacy anon, service_role API Keys” y copiar la clave denominada “anon public”.

SUPABASE_SERVICE_ROLE_KEY: Se consigue haciendo los mismos pasos que antes y en vez de copiar “anon public” se copia el “service_role”.

Para JWT_SECRET, se debe crear manualmente, asegurándose de que sea lo más segura posible.

Integración con base de datos

El proceso de creación de la aplicación puede tardar unos momentos en completarse; en caso de que no se reflejen cambios, se puede hacer clic en “Reload Now”.

Una vez finalizado el proceso, se mostrará una vista previa de cómo queda la página creada, junto con las opciones disponibles.

Panel administrativo

Publicación del proyecto en GitHub

A continuación, se debe ir a la esquina superior derecha de IA Studio y hacer clic en “Publish” o “Publicar”. Luego, se selecciona GitHub y se elige la opción de publicación pública, de modo que la página pueda ser visible para todos.

Se debe verificar que toda la documentación que se va a subir a GitHub sea correcta y, posteriormente, hacer clic en “Stage and commit all changes”.

Una vez finalizado el proceso, se puede acceder al GitHub creado, donde se visualizará el repositorio con la información correspondiente. En este caso, se encuentra disponible en el siguiente enlace: https://github.com/CRMedica/CRMedica_Colombia.

Repositorio del proyecto

Por otra parte, se debe crear una cuenta nueva en la página de Render, ya que esta plataforma permitirá alojar y publicar la aplicación de forma rápida y sencilla.

Después de crear la cuenta, se debe proceder a crear un nuevo servicio, seleccionando en este caso la opción de “Web Service” o servicio web.

Despliegue de la aplicación en Render

De igual forma, se debe configurar la plataforma vinculándola con la cuenta de GitHub previamente utilizada e instalar Render en dicha cuenta.

Configuración del servicio

Una vez instalado y configurado, se podrán visualizar los repositorios disponibles en GitHub y seleccionar el que se va a utilizar.

En el siguiente paso, se deben configurar las variables de entorno necesarias para poder continuar, añadiendo las correspondientes según los requerimientos del proyecto.

En Render se podrá visualizar la información del repositorio de GitHub y, una vez verificada, se puede seleccionar la opción “Connect” para confirmar que todo esté funcionando correctamente.

1. Una vez hecho ya podemos entrar el link de la página web: https://crmedica-colombia.onrender.com/

Solución de errores encontrados

Se realizaron cambios en el frontend debido a fallos detectados en el login, como la ausencia de la opción de recuperación de contraseña y la funcionalidad para crear una cuenta. Las correcciones se implementaron en IntelliJ IDEA, específicamente modificando el script login.tsx, y posteriormente se subieron los cambios mediante un push al repositorio en GitHub.

Recuperación de contraseña

Como se puede observar en la imagen, ahora se encuentra disponible el apartado para crear una cuenta, así como la opción de recuperación o creación de contraseña.

Se presentó un error al momento de crear el usuario, indicando: “No se pudo encontrar la tabla ‘public.users’ en la caché del esquema”. Para solucionarlo, se copió el contenido del archivo schema.sql y se pegó en el SQL Editor de la base de datos en Supabase. Posteriormente, se ejecutó el script, lo que permitió crear correctamente la estructura necesaria y proceder con la creación del usuario sin inconvenientes.

Se agregó el endpoint /api/auth/forgot-password, el cual recibe el correo del usuario y utiliza el método supabase.auth.resetPasswordForEmail() de Supabase para enviar automáticamente un correo con un enlace seguro de restablecimiento. Dicho enlace redirige al usuario a la página /reset-password de la aplicación.

Adicionalmente, en Render se configuró la variable de entorno APP_URL con el valor https://crmedica-colombia.onrender.com, permitiendo que Supabase identifique el dominio al que debe redirigir al usuario después de que este haga clic en el enlace recibido por correo.

1. Reconocimiento de Red y Pruebas de Conectividad

Objetivo General 

Realizar un reconocimiento de red, utilizando herramientas de diagnóstico para realizar pruebas de conectividad, rutas y puertos.

Objetivos Específicos 

a. Comprender el uso del protocolo ICMP mediante comandos de ping

b. Identificar la ruta de paquetes usando Traceroute

c. Obtener la direccion IP publica del equipo 

d. Realizar un escaneo básico de puertos 

Herramientas Utilizadas 

• Consola de comandos CMD o Terminal
• Comando PING
• Tracert / Traceroute 
• Curl / nslookup
• Nmap

Desarrollo de las pruebas implementadas 

a. Implementación de Comando PING, prueba de conectividad 

Se usa el ping https://crmedica-colombia.onrender.com/ para verificar la conectividad entre el equipo local (pc) y un servidor remoto mediante el protocolo ICMP. 

Figura 1

Resultado Obtenido:

Al ejecutar el comando ping al dominio crmedica-colombia.onrender.com se obtuvo respuesta satisfactoria desde la dirección IP 216.24.57.251, con un total de 4 paquetes enviados, 4 recibidos y 0% de pérdida. Además, los tiempos de respuesta fueron estables, con un promedio de 58 ms, lo que indica que el servidor se encuentra activo y accesible desde la red.

El dominio resolvió correctamente hacia la infraestructura de Render y Cloudflare (gcp-us-west1-1.origin.onrender.com.cdn.cloudflare.net), evidenciando que el servicio está funcionando correctamente y que las solicitudes ICMP no están bloqueadas en este caso. Esto permite verificar la conectividad básica y disponibilidad del servidor en internet.

b. Identificación de rutas usando Traceroute / tracert 

Usaremos el comando tracert https://crmedica-colombia.onrender.com/ que nos permite la identificación de rutas.

Figura 2

Resultado Obtenido:

La prueba realizada con el comando tracert al dominio crmedica-colombia.onrender.com permitió identificar la ruta que siguen los paquetes desde el equipo local hasta el servidor de destino. Durante el recorrido se observaron varios saltos internos pertenecientes a la red privada del proveedor de internet (192.168.x.x y 10.x.x.x), antes de salir hacia direcciones públicas asociadas a la infraestructura de Cloudflare y Render.

El trazado alcanzó correctamente la dirección final 216.24.57.251 en un total de 11 saltos, con tiempos promedio cercanos a los 58 ms. En uno de los saltos se presentó el mensaje “Tiempo de espera agotado para esta solicitud”, lo cual es normal en algunos routers o firewalls que bloquean respuestas ICMP por motivos de seguridad o configuración de red. Sin embargo, esto no afectó la conectividad final, ya que la traza se completó exitosamente y el servidor respondió correctamente.

c. Resultado de nslookup 

Figura 3

Resultados Obtenidos:

Al ejecutar el comando nslookup sobre el dominio crmedica-colombia.onrender.com se obtuvo una respuesta DNS exitosa, permitiendo identificar las direcciones IP asociadas al dominio. La consulta resolvió el nombre hacia gcp-us-west1-1.origin.onrender.com.cdn.cloudflare.net, evidenciando que el sitio utiliza la infraestructura de Cloudflare como red de distribución y protección.

Además, se identificaron las direcciones IP públicas 216.24.57.7 y 216.24.57.251, asociadas al servicio alojado en Render. La respuesta fue catalogada como “no autoritativa”, lo cual significa que la información fue obtenida desde un servidor DNS intermedio o en caché y no directamente desde el servidor DNS principal del dominio. Esto es un comportamiento normal en consultas DNS realizadas desde equipos cliente.

d. Escaneo de puertos

Se utilizó el cuando nmap -F https://crmedica-colombia.onrender.com/ para la realización de un escaneo básico de puertos con el comando Nmap sobre el dominio.

Figura 4

La prueba realizada con nmap -F permitió identificar los puertos abiertos del dominio crmedica-colombia.onrender.com. El servidor respondió correctamente y se detectaron abiertos los puertos 80 (HTTP), 443 (HTTPS), 8080 y 8443, asociados a servicios web y conexiones seguras.

Además, se evidenció que la mayoría de los puertos analizados se encuentran filtrados o sin respuesta, lo cual sugiere la implementación de medidas de seguridad como firewalls o restricciones de acceso para proteger los servicios internos del servidor.

2. DNS, WHOIS y certificados

Objetivo General 

Realizar el análisis de información pública de un sitio web mediante consultas DNS, WHOIS y certificados SSL/TLS, con el fin de identificar su infraestructura, propietario y nivel de seguridad.

Objetivos Específicos 

a. Consultar registros DNS

b. Realizar busqueda de WHOIS para obtener información del registrante

c. Analizar certificados SSL/TLS de sitios web

d. Identificar subdominios y servicios asociados

Herramientas Utilizadas 

• nslookup (types)
• WHOIS
• SSL, Checker, consulta comando puerto 443
• nslookup type = NS

Desarrollo de las pruebas implementadas 

a. Consulta de registros DNS

Anteriormente se hizo la consulta de nslookup con su respectivo resultado, en este apartado podremos ver entonces los diferentes tipos específicos. Para recordar, el nslookup obtuvo este resultado:

Figura 5

Para la consulta de tipos específicos, esto fue lo que se obtuvo: 

Figura 6 (type A)

Figura 7 (type MX)

Figura 8 (type NS)

Figura 9 (type TXT)

Se realizaron consultas DNS de tipo A, MX, NS y TXT sobre el dominio crmedica-colombia.onrender.com utilizando la herramienta nslookup, con el fin de identificar información relacionada con direccionamiento IP, servidores de correo, servidores de nombres y registros de texto del dominio.

En la consulta de tipo A se evidenció que el dominio resuelve correctamente hacia las direcciones IP públicas 216.24.57.251 y 216.24.57.7, asociadas a la infraestructura de Render y protegidas mediante la red de distribución de contenido Cloudflare. Además, se identificó el alias gcp-us-west1-1.origin.onrender.com.cdn.cloudflare.net, confirmando el uso de servicios CDN y balanceo de tráfico.

Las consultas de tipo MX, NS y TXT no devolvieron registros específicos configurados directamente para el dominio analizado. En su lugar, la respuesta mostró información relacionada con cloudflare.net, incluyendo el servidor principal ns1.cloudflare.net, lo que indica que el dominio utiliza la infraestructura DNS de Cloudflare para la administración y resolución de nombres.

También se observó que las respuestas obtenidas fueron “no autoritativas”, lo cual significa que la información proviene de un servidor DNS intermedio o almacenado en caché y no directamente del servidor DNS autoritativo del dominio. En general, los resultados permiten concluir que el dominio se encuentra correctamente configurado y accesible a través de servicios de hosting y protección en la nube.

b. Consulta WHOIS

Para esta consulta se utilizó la página web https://who.is/ ya que al usar Windows no se tiene por defecto el término “whois” para ejecutar en CMD. 

Figura 10

Figura 11

Figura 12

Al realizar la consulta WHOIS sobre el dominio crmedica-colombia.onrender.com no se obtuvo información pública registrada del dominio. El sistema mostró el mensaje “No WHOIS data was found”, indicando que no existen registros WHOIS disponibles directamente para esta dirección.

Esto ocurre porque onrender.com pertenece a la plataforma de hosting Render, y el subdominio crmedica-colombia.onrender.com no corresponde a un dominio registrado de forma independiente, sino a un subdominio administrado por el proveedor del servicio. Por esta razón, la información WHOIS del subdominio no se encuentra expuesta públicamente como sucede con dominios propios registrados ante entidades oficiales.

A pesar de no contar con información WHOIS específica, las consultas DNS permitieron identificar que el servicio utiliza infraestructura de Cloudflare y Render, resolviendo hacia las direcciones IP 216.24.57.7 y 216.24.57.251. Además, el estado del servicio aparece como “Active”, lo que indica que el sitio continúa siendo accesible desde internet.

Figura 13

Figura 14

Como complemento del análisis WHOIS, se realizó una consulta sobre el dominio principal onrender.com, ya que el subdominio analizado no posee registro independiente. Los resultados evidenciaron que el dominio pertenece a Render Services, Inc. y se encuentra registrado mediante Amazon Registrar, Inc. desde el año 2015.

Asimismo, se identificó el uso de servidores DNS de AWS Route 53, además de políticas de seguridad que restringen modificaciones y transferencias no autorizadas del dominio. Esta información confirma que la infraestructura del servicio web analizado se encuentra soportada sobre plataformas cloud reconocidas como Render, Amazon Web Services y Cloudflare.

c. Análisis de certificados SSL/TLS

Para el análisis de certificados se utilizaron dos diferentes formas de verificarlo, desde la página web viendo el certificado usando el candado al lado de la dirección web, y también se utilizó la página SSL Checker.

Figura 15

Figura 16

Durante la verificación de certificados SSL/TLS se evidenció que el sitio cuenta con un certificado digital válido y correctamente configurado. El certificado fue emitido para el dominio onrender.com por la entidad certificadora Google Trust Services, utilizando el emisor intermedio WE1, lo que garantiza la autenticidad y confiabilidad de la conexión segura HTTPS.

El análisis mostró que el certificado es reconocido por los principales navegadores web y que la cadena de confianza (certificate chain) se encuentra correctamente instalada, incluyendo las autoridades WE1 y GTS Root R4. Asimismo, se verificó que el hostname del sitio coincide correctamente con la información contenida en el certificado digital, evitando problemas de validación o suplantación de identidad.

El certificado utiliza el algoritmo de firma ecdsa-with-SHA256, considerado actualmente un estándar seguro para conexiones cifradas modernas. Además, la validez del certificado se encuentra activa desde el 28 de marzo de 2026 hasta el 26 de junio de 2026, garantizando que las comunicaciones entre el cliente y el servidor se realizan de manera cifrada y protegida contra interceptaciones.

También se identificó que la infraestructura utiliza servicios de Cloudflare, lo que contribuye a mejorar la seguridad, disponibilidad y protección frente a ataques externos mediante mecanismos de proxy inverso, CDN y mitigación de amenazas.

d. Posibles riesgos

Aunque el certificado SSL/TLS se encuentra correctamente configurado, se identifican algunos posibles riesgos asociados a la infraestructura y configuración del servicio:

• Dependencia de servicios externos como Cloudflare y Render, lo que puede generar afectaciones en caso de fallos, caídas o problemas de disponibilidad en dichas plataformas.
• El certificado tiene una vigencia relativamente corta, por lo que si no se renueva oportunamente podría provocar advertencias de seguridad o interrupciones en el acceso HTTPS.
• La exposición de puertos adicionales como 8080 y 8443 podría representar una superficie de ataque adicional si existen servicios mal configurados o vulnerables.
• El uso de subdominios públicos en plataformas cloud puede facilitar actividades de reconocimiento por parte de atacantes, permitiendo identificar tecnologías y proveedores utilizados por el servicio.

Aunque la conexión HTTPS protege la transmisión de datos, esto no garantiza por sí solo la seguridad de la aplicación web frente a vulnerabilidades como inyecciones SQL, XSS o configuraciones inseguras.

OWASP Metodología 

A01: Broken Access Control (Control de Acceso Roto)

Descripción: Ocurre cuando los usuarios pueden acceder a recursos sin la debida autorización.

Posible análisis en el sitio: No se evidenció directamente acceso a paneles administrativos, sin embargo, al ser un sitio web en hosting gratuito, podría existir riesgo si no se controlan correctamente rutas como /admin o /wp-admin.

Se utilizó la herramienta de línea de comandos (CMD) con el siguiente comando:

A02: Cryptographic Failures (Fallas Criptográficas)

Descripción

Las fallas criptográficas ocurren cuando la información sensible no está correctamente protegida mediante cifrado, lo que puede permitir su exposición o interceptación por atacantes.

Procedimiento realizado 

Para verificar el uso de cifrado en el sitio web, se realizó:

• Acceso al sitio desde el navegador verificando el protocolo HTTPS
• Inspección del certificado SSL/TLS desde el candado del navegador
• Validación del puerto seguro (443) previamente identificado con Nmap

Análisis de resultados

• El sitio utiliza el protocolo:
• Se confirmó que:
  • El certificado SSL es válido
  • Emitido por ZeroSSL
  • La comunicación está cifrada

A03: Injection

Análisis: No se evidencia sanitización en cliente.

Conclusión: Riesgo potencial de inyección (dependiente del backend)

A04: Insecure Design (Diseño Inseguro)

Descripción: Problemas desde la arquitectura del sistema.

Análisis: El uso de hosting gratuito y subdominios indica una arquitectura básica con limitaciones de seguridad.

Riesgo: Falta de controles de seguridad desde el diseño.

Mitigación:

• Aplicar principios de diseño seguro
• Análisis de amenazas
• Uso de buenas prácticas desde el desarrollo

A05: Security Mis configuration (Mala Configuración)

Descripción: Configuraciones incorrectas en servidores o aplicaciones.

Análisis: Se detectaron puertos abiertos (80, 443, 2049), lo cual puede representar exposición de servicios.

Riesgo: Acceso no autorizado a servicios.

Mitigación:

• Cerrar puertos innecesarios
• Configurar correctamente el servidor
• Uso de firewalls

A06: Vulnerable and Outdated Components

Descripción: La vulnerabilidad A06 hace referencia al uso de componentes, librerías, frameworks o tecnologías desactualizadas o potencialmente vulnerables dentro de una aplicación web. El uso de componentes sin actualización puede permitir la explotación de vulnerabilidades conocidas públicamente. 

Análisis: Durante el reconocimiento de la aplicación CRM se realizó una inspección manual de los recursos cargados por el frontend mediante DevTools del navegador.

Se identificó el uso de archivos JavaScript empaquetados y minimizados, entre ellos:

La utilización de bundles minimizados dificulta parcialmente la identificación directa de tecnologías y versiones específicas; sin embargo, evidencia el uso de componentes frontend modernos y dependencias externas cargadas dinámicamente desde el navegador.

Adicionalmente, durante la revisión de encabezados HTTP se identificó información relacionada con políticas de acceso y configuración del servidor, lo que podría facilitar tareas de fingerprinting tecnológico por parte de un atacante.

Riesgo: 

• Explotación de vulnerabilidades conocidas en componentes desactualizados.
• Incremento de la superficie de ataque mediante librerías externas.
• Exposición de información técnica de la aplicación.
• Riesgo de ejecución de código malicioso si existen dependencias vulnerables.

Mitigación:

• Mantener actualizadas todas las dependencias y componentes del sistema.
• Implementar monitoreo continuo de vulnerabilidades (CVE).
• Eliminar librerías o módulos innecesarios.
• Reducir la exposición de información técnica mediante headers seguros.
• Realizar auditorías periódicas de componentes utilizados por la aplicación.

A07: Identification and Authentication Failures

Descripción: La vulnerabilidad A07 hace referencia a fallas en los mecanismos de identificación, autenticación y gestión de sesiones de los usuarios. Estas fallas pueden permitir ataques de fuerza bruta, enumeración de usuarios o accesos no autorizados.

Análisis: Durante las pruebas realizadas sobre el sistema de autenticación del CRM se evidenciaron múltiples debilidades relacionadas con la validación y protección del proceso de inicio de sesión.

El sistema diferencia los mensajes de error dependiendo de la credencial ingresada:

• Cuando el usuario no existe, el sistema responde con:

Cuando el correo es válido pero la contraseña es incorrecta, el sistema responde con:

Esto permite la enumeración de usuarios, ya que un atacante puede identificar correos válidos dentro de la plataforma mediante las respuestas del sistema.

Adicionalmente, se observó que el formulario de autenticación no implementa mecanismos adicionales de protección como CAPTCHA, autenticación multifactor (MFA) o limitación de intentos fallidos de inicio de sesión.

Durante las pruebas realizadas, la aplicación permitió múltiples intentos consecutivos de autenticación sin bloqueo temporal ni restricciones visibles.

Riesgo

• Enumeración de usuarios válidos.
• Ataques de fuerza bruta.
• Acceso no autorizado a cuentas.
• Compromiso de credenciales.
• Secuestro o abuso de sesiones autenticadas.

Mitigación:

• Implementar autenticación multifactor (MFA).
• Configurar bloqueo temporal tras múltiples intentos fallidos.
• Implementar CAPTCHA o mecanismos anti-bot.
• Unificar mensajes de error para evitar enumeración de usuarios.
• Aplicar políticas robustas de contraseñas y monitoreo de accesos sospechosos.

A08: Software and Data Integrity Failures

Descripción

La vulnerabilidad A08 hace referencia a fallos en la verificación de integridad del software y los datos. Ocurre cuando una aplicación carga recursos externos (scripts, librerías, actualizaciones) sin comprobar que no hayan sido manipulados por un tercero. El mecanismo estándar de protección es el atributo Subresource Integrity (SRI), que permite al navegador verificar que el contenido de un recurso externo coincide con un hash criptográfico esperado. Si este atributo no está presente, un atacante que comprometa el servidor externo puede inyectar código malicioso que el sitio ejecutará sin advertencia alguna.

Herramientas Utilizadas

•       Google Chrome DevTools – pestaña Elements

•       Google Chrome DevTools – pestaña Network (filtro JS)

•       Búsqueda en código fuente con Ctrl+U

Objetivos Específicos

•       Verificar si los scripts JavaScript cargados por el sitio incluyen el atributo integrity (SRI).

•       Identificar si existen scripts cargados desde CDN externos sin verificación de integridad.

•       Determinar el riesgo asociado a la ausencia de controles de integridad en el frontend.

Desarrollo de las Pruebas Implementadas

a. Inspección de scripts en la pestaña Elements

Se accedió al sitio crmedica-colombia.onrender.com y se abrió la pestaña Elements de Chrome DevTools. Se realizó una búsqueda del término <script src= para identificar etiquetas de scripts externos con posible atributo integrity. La búsqueda arrojó 0 de 0 resultados, lo que indica que el sitio no incluye scripts externos con etiqueta <script src= directamente en el HTML. La aplicación utiliza un bundle generado dinámicamente (arquitectura React/Vite), donde los scripts se inyectan en tiempo de ejecución.

Figura 33 Búsqueda de <script src= en DevTools – 0 resultados encontrados

Análisis de Resultados

Las pruebas realizadas sobre el sitio crmedica-colombia.onrender.com evidenciaron la ausencia total del atributo Subresource Integrity (SRI) en los recursos JavaScript cargados por la aplicación. Si bien el sitio utiliza un bundle interno generado por Vite/React (lo que reduce parcialmente el riesgo de scripts CDN externos), la falta de cualquier mecanismo de verificación de integridad representa una debilidad en la cadena de suministro de software.

Adicionalmente, la arquitectura de bundle único sin SRI implica que cualquier modificación no autorizada en el archivo servido por el servidor no sería detectada por el navegador del usuario, facilitando potenciales ataques de tipo supply chain.

Riesgos Identificados

•       Ausencia del atributo integrity en scripts JavaScript: el navegador no puede verificar que el contenido no haya sido alterado.

•       Riesgo de ataques de cadena de suministro (supply chain): si el servidor de Render o Cloudflare es comprometido, el código malicioso se ejecutaría en todos los clientes.

•       Falta de política de Content Security Policy (CSP) estricta que restrinja la ejecución de scripts no autorizados.

•       Los bundles minificados dificultan la auditoría manual del código cargado.

Mitigación

•       Implementar el atributo integrity con hash SHA-384 o SHA-512 en todos los scripts externos cargados desde CDN.

•       Configurar una política Content Security Policy (CSP) estricta que bloquee la ejecución de scripts no incluidos en la lista blanca.

•       Utilizar herramientas como SRI Hash Generator (https://www.srihash.org/) para generar los hashes de integridad correspondientes.

•       Revisar periódicamente las dependencias del proyecto mediante herramientas como npm audit o Snyk.

•       Considerar el uso de Trusted Types API para prevenir inyecciones de scripts en tiempo de ejecución.

A09: Security Logging and Monitoring Failures

Descripción

La vulnerabilidad A09 hace referencia a la ausencia o deficiencia en los mecanismos de registro (logging) y monitoreo de eventos de seguridad dentro de una aplicación web. Sin un registro adecuado de eventos como intentos de acceso fallidos, errores del servidor, rutas no autorizadas y actividades anómalas, los administradores del sistema son incapaces de detectar, investigar o responder oportunamente ante incidentes de seguridad. Esta categoría también incluye la exposición involuntaria de información técnica sensible a través de mensajes de error o cabeceras HTTP.

Herramientas Utilizadas

•       Google Chrome – navegación a rutas inexistentes

•       Chrome DevTools – pestaña Network (filtro All)

•       Inspección de Response Headers en DevTools

Objetivos Específicos

•       Verificar el comportamiento del servidor ante rutas inválidas o no existentes.

•       Analizar los códigos de respuesta HTTP devueltos ante solicitudes a rutas inexistentes.

•       Inspeccionar los encabezados de respuesta HTTP en busca de información técnica expuesta.

•       Determinar si el sistema implementa respuestas de error estandarizadas que dificulten el reconocimiento por parte de atacantes.

Desarrollo de las Pruebas Implementadas

a. Inspección de Response Headers – Recurso principal

Se inspeccionaron los encabezados de respuesta del recurso principal index-6fsZL0J0.js mediante la pestaña Network de Chrome DevTools. Los encabezados revelan información relevante sobre la infraestructura del servidor: el campo Server expone el valor cloudflare, lo que permite a un atacante identificar el proveedor de CDN/proxy utilizado. Se observó la presencia de los headers de seguridad Strict-Transport-Security, X-Content-Type-Options: nosniff y X-Frame-Options: SAMEORIGIN, lo cual representa buenas prácticas de configuración. Sin embargo, la exposición del campo Server con el valor del proveedor constituye una filtración de información técnica que facilita tareas de reconocimiento.

Figura 35 Response Headers del recurso principal – Server: cloudflare expuesto

b. Comportamiento ante rutas inexistentes

Se realizaron solicitudes a rutas inexistentes del sitio, incluyendo /ruta-que-no-existe, /admin y /api. En todos los casos, el servidor devolvió un Status Code 200 OK en lugar del código de error esperado (404 Not Found), redirigiendo al usuario a la interfaz de login de la aplicación. Este comportamiento es propio de aplicaciones de página única (SPA) que manejan el enrutamiento en el frontend, pero implica que el servidor no registra ni diferencia entre rutas válidas e inválidas, dificultando la detección de intentos de enumeración de rutas o reconocimiento por parte de atacantes.

Figura 36 Solicitud a ruta inexistente retorna Status 200 OK en lugar de 404

Análisis de Resultados

El análisis de los mecanismos de logging y monitoreo del sitio crmedica-colombia.onrender.com reveló dos hallazgos principales. En primer lugar, el servidor expone el campo Server: cloudflare en todos sus encabezados de respuesta, proporcionando a posibles atacantes información sobre la infraestructura tecnológica utilizada. En segundo lugar, el sitio responde con código HTTP 200 OK ante cualquier ruta inválida, redirigiendo siempre al login, lo que impide distinguir a nivel de servidor entre peticiones legítimas y actividad maliciosa de reconocimiento.

Riesgos Identificados

•       Exposición del campo Server: cloudflare en headers HTTP facilita la identificación de la infraestructura por parte de atacantes.

•       El código de respuesta 200 OK ante rutas inexistentes impide detectar intentos de enumeración de rutas y directorios.

•       Sin diferenciación de respuestas HTTP, los intentos de reconocimiento automatizado (scanners, bots) no generan alertas distinguibles.

•       La ausencia de evidencia de logging centralizado dificulta la investigación forense ante un incidente de seguridad.

•       No se observan mecanismos visibles de rate limiting o detección de comportamiento anómalo en las respuestas del servidor.

Mitigación

•       Configurar el servidor para devolver códigos HTTP correctos (404, 403) ante rutas no existentes o no autorizadas, incluso en arquitecturas SPA.

•       Eliminar o reemplazar el header Server por un valor genérico que no revele el proveedor de infraestructura.

•       Implementar un sistema de logging centralizado (SIEM) que registre accesos, errores y eventos de seguridad.

•       Establecer alertas automáticas ante patrones de acceso anómalos como múltiples intentos a rutas inexistentes en corto tiempo.

•       Integrar herramientas de monitoreo como Cloudflare Analytics, Datadog o similares para visibilidad en tiempo real.

•       Implementar el header X-Powered-By oculto para no revelar tecnologías del backend.

A10: Server-Side Request Forgery (SSRF)

Descripción

La vulnerabilidad A10 hace referencia a ataques de tipo Server-Side Request Forgery (SSRF), en los que un atacante logra que el servidor realice solicitudes HTTP hacia destinos arbitrarios, incluyendo recursos internos de la infraestructura que normalmente no serían accesibles desde el exterior. Esta vulnerabilidad ocurre cuando la aplicación acepta URLs proporcionadas por el usuario y las procesa en el backend sin una validación o restricción adecuada. En entornos cloud, el objetivo más crítico de un ataque SSRF es el servicio de metadatos de la instancia (169.254.169.254), que puede revelar credenciales, tokens de acceso y configuración interna de la infraestructura.

Herramientas Utilizadas

•       Navegador web Google Chrome

•       Chrome DevTools – pestaña Network (filtro Fetch/XHR)

•       Formulario de registro de productos del CRM analizado

a. Reconocimiento del panel de control

Se accedió al panel de control del CRM Respira CRM Colombia con credenciales de prueba. El dashboard mostró información comercial sensible incluyendo métricas de ventas, prospectos activos, clientes y órdenes de servicio. Se identificaron los módulos disponibles: Prospectos, Clientes, Productos, Cotizaciones y Ventas, los cuales fueron revisados en busca de funcionalidades que acepten URLs externas.

Figura 37 Panel de control del CRM – módulos identificados para análisis SSRF

b. Identificación del vector de ataque en módulo de Productos

Al acceder al módulo Productos y seleccionar “Registrar Nuevo Producto”, se identificó un campo denominado “O USAR URL EXTERNA (PERMANENCIA TOTAL)” que permite al usuario ingresar una URL de imagen que el servidor procesará para asociarla al producto. Este campo representa un vector de ataque SSRF directo, ya que la URL ingresada es procesada por el backend del servidor para obtener el recurso externo.

Figura 38 Formulario de registro de producto con campo de URL externa identificado

c. Revisión de otros formularios del sistema

Se revisaron los demás formularios del CRM: Registrar Nuevo Cliente y Generación de Cotización. El formulario de clientes contiene campos de texto estándar (nombre, NIT, teléfono, email, dirección) sin campos de URL. El formulario de cotizaciones permite seleccionar clientes y productos del inventario. Ninguno de estos formularios presentó campos de URL adicionales, confirmando que el vector principal de SSRF se encuentra en el módulo de Productos.

Formulario de registro de cliente – sin campos de URL externa

Formulario de cotización – sin campos de URL externa

Prueba de explotación SSRF con dirección de metadatos AWS

Para confirmar la vulnerabilidad SSRF, se ingresó en el campo de URL externa del formulario de productos la dirección del servicio de metadatos de instancia de AWS: http://169.254.169.254/latest/meta-data/. Esta dirección es inaccesible desde el exterior pero accesible desde el servidor si este se ejecuta en infraestructura cloud de Amazon Web Services.

El producto fue guardado exitosamente con el nombre “Owasp” para identificar la prueba. El resultado mostró el producto creado con la imagen en blanco (sin carga), lo que indica que el servidor intentó realizar la solicitud HTTP a la dirección interna pero no pudo obtener el contenido. Crucialmente, en la pestaña Network de DevTools se observó la petición a meta-data/ con estado “(pendiente)”, confirmando que el backend procesó la URL y realizó la solicitud hacia la dirección interna antes de que la conexión expirara.

Producto “Owasp” creado con imagen en blanco – servidor intentó acceder a metadatos

Network DevTools – petición a meta-data/ con estado pendiente confirma SSRF

Análisis de Resultados

La prueba realizada confirmó la existencia de una vulnerabilidad SSRF activa en el módulo de Productos del CRM crmedica-colombia.onrender.com. El campo “O USAR URL EXTERNA (PERMANENCIA TOTAL)” del formulario de registro de productos permite al usuario proporcionar una URL arbitraria que el servidor procesa sin validación ni restricción de destino.

La petición a http://169.254.169.254/latest/meta-data/ quedó en estado pendiente en la red, lo que indica que el servidor realizó efectivamente la solicitud hacia la dirección interna de metadatos de AWS antes de que la conexión expirara por timeout. En un escenario real de ataque, si el servidor tiene acceso a este endpoint (lo cual es frecuente en instancias EC2 de AWS sin IMDSv2 habilitado), un atacante podría obtener credenciales temporales de IAM, tokens de seguridad y configuración interna de la infraestructura cloud.

Riesgos Identificados

•       Vulnerabilidad SSRF confirmada: el servidor procesa URLs externas proporcionadas por el usuario sin validación de destino.

•       Exposición potencial del servicio de metadatos de AWS (169.254.169.254), que puede revelar credenciales IAM temporales y configuración interna.

•       Posibilidad de escaneo de puertos internos y enumeración de servicios de la red privada del proveedor cloud.

•       Riesgo de acceso a servicios internos no expuestos públicamente (bases de datos, APIs internas, paneles de administración).

•       En caso de comprometer credenciales IAM mediante SSRF, un atacante podría escalar privilegios y tomar control de recursos cloud completos.

•       La funcionalidad de URL externa no tiene restricción de esquemas, permitiendo el uso de protocolos como file://, dict://, gopher:// que amplían la superficie de ataque.

Mitigación

•       Implementar una lista blanca (allowlist) de dominios permitidos para el campo de URL externa, rechazando cualquier dominio no autorizado.

•       Bloquear explícitamente el acceso a rangos de IP privadas y de metadatos cloud (169.254.0.0/16, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) en las solicitudes salientes del servidor.

•       Habilitar IMDSv2 (Instance Metadata Service v2) en la infraestructura AWS para requerir tokens de sesión en solicitudes al servicio de metadatos, mitigando el impacto de SSRF.

•       Procesar imágenes de productos en el frontend o mediante un servicio intermediario aislado que no tenga acceso a la red interna.

•       Restringir los esquemas de URL permitidos únicamente a https:// y bloquear file://, dict://, gopher://, ftp:// y otros protocolos.

•       Implementar un proxy de salida controlado para todas las solicitudes HTTP del servidor con reglas de filtrado estrictas.

•       Realizar validación y sanitización de URLs en el backend antes de procesar cualquier solicitud.

Conclusiones -Desarrollo de un CRM médico utilizando inteligencia artificial y tecnologías cloud modernas

El desarrollo del CRM utilizando IA Studio permitió demostrar cómo la inteligencia artificial puede acelerar significativamente el desarrollo de aplicaciones web modernas. La integración con Supabase facilitó la administración de bases de datos y autenticación, mientras que GitHub y Render permitieron desplegar la aplicación de forma rápida y eficiente.

Además, la solución de errores relacionados con login, sesiones y recuperación de contraseñas fortaleció el sistema y permitió comprender la importancia de las configuraciones cloud y la seguridad en aplicaciones modernas.

Este proyecto evidencia que la inteligencia artificial se está convirtiendo en una herramienta fundamental dentro del desarrollo de software, permitiendo construir aplicaciones más rápidas, escalables y eficientes.

Autores: Ana Catalina Parra Arias – Gina Marcela Acosta Ruiz – Nelson Stiven Otavo Paredes–Juan Sebastian Polanco Santofimio
Editor: Magister Ingeniero Carlos Iván Pinzón Romero
Código: UCHEG1-9
Universidad: Universidad Central

FUENTES:

Chirou, A. (2023, 29 de diciembre). 
Guía de hacking y pentesting - Capítulo 2: Herramientas para pentesters. https://achirou.com/guia-de-hacking-y-pentesting-capitulo-2-herramientas-para-pentesters/

Chirou, A. (2024, 1 de enero). Guía de hacking y pentesting - Capítulo 3: Nmap reconocimiento y enumeración. https://achirou.com/guia-de-hacking-y-pentesting-capitulo-3-nmap-reconocimiento-y-enumeracion/

Chirou, A. (2024, 22 de noviembre). Linux para hackers #18: Comandos de red. https://achirou.com/linux-para-hackers-18-comandos-de-red/
DC Seguridad. (s.f.). Pentesting paso a paso: máquinas TryHackMe. DCSeguridad. https://dcseguridad.es/tag/pentesting/

Instituto Nacional de Ciberseguridad (INCIBE-CERT). (2023). Estudio de herramientas para la actividad de reconocimiento. https://www.incibe.es/sites/default/files/2023-08/INCIBE-CERT_ESTUDIO_DE_HERRAMIENTAS_DE_RECONOCIMIENTO_2023_v1.0.pdf

Paramissuperiores. (2025, 26 de noviembre). Nmap: Guía completa 2025 – Tutorial de comandos, escaneo de puertos y hacking ético.

 https://paramissuperiores.es/2025/11/26/nmap-tutorial-comandos-escaneo-puertos/
Revista de Seguridad UNAM. (s.f.). Pruebas de penetración para principiantes: 5 herramientas para empezar. Universidad Nacional Autónoma de México. 

https://revista.seguridad.unam.mx/print/2233Viafirma. (2025, 10 de noviembre). Hacking ético: identificación de servicios con nmap.

 https://www.viafirma.com/es/identificacion-de-servicios-con-nmap/
WeLiveSecurity. (s.f.). Herramientas de pentesting para principiantes. ESET. 

https://www.welivesecurity.com/es/recursos-herramientas/herramientas-pentesting-para-principiantes/onrender.com WHOIS Domain Name Lookup - Who.is. (2023). Who.Is. https://who.is/whois/onrender.com

SSL Checker. (2026). Sslshopper.Com. https://www.sslshopper.com/ssl-checker.html#hostname=https://crmedica-colombia.onrender.com
OWASP Foundation. (2021). OWASP Top 10: The ten most critical web application security risks.
 https://owasp.org/www-project-top-ten/
OWASP Foundation. (s.f.). Server-Side Request Forgery Prevention Cheat Sheet.
 https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html
OWASP Foundation. (s.f.). Content Security Policy Cheat Sheet.
 https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
Nmap Project. (s.f.). Nmap Reference Guide.
 https://nmap.org/book/man.html
Cloudflare. (s.f.). What is DNS?
 https://www.cloudflare.com/learning/dns/what-is-dns/
Cloudflare. (s.f.). What is SSL/TLS?
 https://www.cloudflare.com/learning/ssl/what-is-ssl/