Fundamentos Web: La Arquitectura del Restaurante

Objetivo de esta Guía

Desmitificar como funciona el internet por debajo del capó. No puedes hackear ni defender una página web si no entiendes sus piezas móviles. Para una persona usuaria, Internet puede parecer únicamente la interfaz del navegador; para seguridad importa comprender cada componente y límite de confianza. Para un profesional de la ciberseguridad, cada página web es un complejo sistema de tres niveles donde la confianza es la mayor vulnerabilidad.

Esta guía asume cero experiencia previa. Si ya sabes programar, saltate las primeras secciones. Si vienes del mundo de redes o sistemas operativos, presta atención a la sección de "Fallo en Cadena" porque ahí es donde los arquitectos experimentados suelen tropezar.

El Mapa General: Cliente, Servidor y Tubería

Divide el internet en exactamente tres partes. No hay una cuarta. Todo lo que haces en línea encaja en alguno de estos tres cajones.

El Cliente es tu navegador, tu app móvil, tu consola de videojuegos conectada a internet. Es el que inicia la conversación. El cliente siempre pregunta primero. Nunca espera pasivamente.

El Servidor es una computadora que vive en un centro de datos, encendida 24/7, esperando preguntas. No tiene monitor, no tiene teclado, solo tiene un cable de red y un corazón que late respondiendo peticiones. Cuando dices "el sitio se cayó", te refieres a que el servidor dejó de responder.

La Tubería es la red de routers, cables submarinos, antenas 5G y switches que conectan al cliente con el servidor. La tubería no entiende de contenido; solo sabe mover paquetes. Es la parte más ingenua de todo el sistema.

El error filosofico más común entre principiantes es pensar que "la nube" es un concepto mágico. No lo es. La nube son simplemente servidores de otras personas en edificios de Amazon, Google o Microsoft. Sigue siendo un servidor con una dirección IP, solo que no te pertenece a ti.

La Arquitectura Clásica en Tres Capas

Olvídate de las computadoras por un momento. Imagina que vas a cenar a un restaurante elegante. Ese restaurante tiene tres componentes críticos que están estrictamente separados.

La Mesa y el Menú (Frontend): Lo que tu puedes ver y tocar. Esta en tu espacio, en tu dispositivo.

El Mesero (HTTP): El que lleva tus órdenes hacia atrás y te trae la comida. Viaja entre dos mundos que nunca se tocan.

La Cocina (Backend): El lugar secreto y cerrado donde se prepara todo. Nunca ves lo que pasa ahí dentro.

La Alacena (Base de Datos): El refrigerador gigante donde están guardados los ingredientes y los secretos. Solo el cocinero tiene acceso.

Así es exactamente como funciona cualquier página web. Amazon, Facebook, tu banco, todos siguen este patrón.

El Frontend: La Mesa del Cliente

Es todo lo que ocurre dentro de tu propio dispositivo, tu celular o tu laptop. Esta construido con tres lenguajes que funcionan en equipo.

HTML (HyperText Markup Language) es la estructura. Son los huesos. Define si hay un parrafo, una imagen, un botón, una tabla. Sin HTML, la página es solo un lienzo en blanco. Cuando ves texto mal alineado o imágenes rotas, estas viendo HTML que fallo en su trabajo.

CSS (Cascading Style Sheets) es la pintura y los muebles. Define colores, tamanos, posiciones, animaciones. Sin CSS, todas las páginas web se verian como documentos de los años 90: fondo blanco, letra negra, links azules subrayados.

JavaScript es el movimiento y la lógica del cliente. Es lo que hace que un botón cambie de color cuando pasas el ratón, que un menú se despliegue, que una imagen se desvanezca. Es el único lenguaje de programación que entienden los navegadores de forma nativa.

La regla de oro del Frontend: NUNCA es de confianza. Como el menú esta en tu mesa, tu puedes tomar un bolígrafo, tachar el precio de la langosta de $100 dólares y escribir $1 dólar. El navegador te pertenece. El código que se descarga en tu máquina puede ser inspeccionado, modificado, interceptado y reescrito por ti. Cualquier programador que ponga lógica sensible en el Frontend esta regalando información a los atacantes.

Esto incluye: validaciones de formularios, cálculos de precios, reglas de descuento, restricciones deacceso. Todo eso debe duplicarse en el Backend. El Frontend es solo para la experiencia del usuario, jamás para la seguridad.

El Backend: La Cocina del Servidor

Es una supercomputadora en un edificio de Amazon o Google trabajando con lenguajes como Python, PHP, Java, Go, Ruby, Node.js, C#, Rust. Corre en un sistema operativo servidor, casi siempre Linux.

Su trabajo es ser el cerebro ciego del sistema. Recibe la nota del mesero que dice "El cliente de la mesa 4 quiere la langosta a $1 dólar". Si el cocinero es estúpido y mal programado, cocinará la langosta y la cobrará a $1. Si el cocinero esta bien programado, validará la orden: "Espera, la langosta cuesta $100, no $1. Orden rechazada".

El Backend alberga la lógica de negocio. Esta frase suena abstracta pero es simple: la lógica de negocio son las reglas que hacen que tu empresa funcione. Como se calculan los impuestos, como se verifica que un usuario tiene saldo suficiente, como se determina si un producto esta en stock. Si la lógica de negocio tiene fallos, el hacker no necesita exploits complejos; solo necesita entender las reglas mejor que el programador.

El Backend también maneja la sesión del usuario. Cuando inicias sesión, el servidor crea un identificador único, una sesión, y se lo entrega al navegador en forma de Cookie. El navegador guarda esa Cookie y la reenvia en cada petición para que el servidor sepa quien eres. Si un atacante roba esa Cookie, se convierte en ti.

La Base de Datos: La Alacena

Es donde se guardan de forma permanente las contraseñas, los números de tarjetas de crédito, los saldos bancarios, el historial de compras, los mensajes privados. Corre con sistemas como PostgreSQL, MySQL, MongoDB, Redis, SQL Server.

El cocinero (Backend) es el único que tiene las llaves de la alacena. La base de datos jamás debe ser accesible desde el internet público. Debe vivir en una red privada, dentro de un segmento de red aislado, donde solo el Backend pueda alcanzarla.

Si un atacante logra engañar al cocinero (por ejemplo, con una Inyección SQL), obtiene la llave de la alacena entera. No necesita forzar la puerta; el cocinero se la abre voluntariamente porque confía ciegamente en las órdenes que recibe.

La mayoría de las filtraciones masivas de datos ocurren porque alguien logró saltarse al Backend y hablar directamente con la base de datos, o porque logró manipular al Backend para que entregará información que no debia.

La Confianza como Vulnerabilidad Fundamental

Toda la seguridad web se reduce a una pregunta: "Quien confía en quien y hasta donde?"

El navegador confía en el servidor. El servidor confía en la base de datos. La base de datos confía en quien le habla desde adentro de la red. El programador confía en que el usuario va a escribir su nombre y no código malicioso. El usuario confía en que la página web no va a robar sus datos.

Cada relación de confianza es un potencial punto de quiebre. La seguridad consiste en poner verificaciones en cada salto de confianza.

Confianza Cero (Zero Trust) es la filosofía que dice: no confíes en nada ni en nadie por defecto. Verifica cada petición como si viniera de un atacante. Asume que la red interna ya fue comprometida. Asume que el usuario ya esta infectado. Diseña tu sistema como si el enemigo ya estuviera dentro.

El Modelo OSI en Términos Prácticos

No necesitas memorizar las 7 capas del modelo OSI para la seguridad web, pero si necesitas entender las que importan.

Capa 4 (Transporte): TCP y UDP. TCP es el que garantiza que los paquetes lleguen en orden. Cuando abres una página, tu navegador abre una conexión TCP con el servidor. Sin TCP, los datos llegarian revueltos o no llegarian.

Capa 3 (Red): IP. Cada dispositivo en internet tiene una dirección IP. Los servidores tienen IPs públicas. Tu celular tiene una IP privada detrás de un router (NAT). Cuando haces una petición, tu router traduce tu IP privada a su IP pública y viceversa.

Capa 7 (Aplicación): HTTP, HTTPS, DNS, FTP, SSH. Es el lenguaje que hablan las aplicaciones. HTTP es el que nos interesa para la web.

El DNS: La Guía Telefónica de Internet

Cuando escribes google.com en tu navegador, tu computadora no sabe donde esta Google. Necesita traducir ese nombre a una dirección IP. Eso lo hace el DNS (Domain Name System).

Tu computadora le pregunta a un servidor DNS: "Oye, cual es la IP de google.com?" El servidor DNS responde: "Es 142.250.80.46". Tu navegador entonces abre una conexión a esa IP.

El DNS es como la guía telefónica del internet. Si un atacante logra envenenar tu DNS (DNS Spoofing), puede hacer que cuando escribas mibanco.com, tu navegador viaje a la IP del hacker, que tiene una copia falsa del banco. Tu le escribiras tu contraseña al hacker y el la reenviara al banco real para que no notes el robo (Ataque de Intermediario).

El DNS también es usado por los atacantes para la exfiltración de datos. Cuando un hacker ya esta dentro de una red y quiere sacar información sin ser detectado, puede codificar los datos robados en consultas DNS. Como el tráfico DNS suele estar permitido en los firewalls, los datos pasan desapercibidos.

El Proxy y el VPN: Intermediarios Necesarios

Un Proxy es un intermediario entre tu y el servidor. Tu le dices al proxy "Tráeme google.com". El proxy va, trae la página y te la entrega. El servidor de Google ve la IP del proxy, no la tuya.

Los proxies se usan para:

• Ocultar la IP del cliente
• Filtrar contenido (proxies corporativos que bloquean redes sociales)
• Cachear respuestas para acelerar la navegación
• Interceptar tráfico para inspeccionarlo (como hacen las empresas con certificados SSL propios)

Una VPN (Virtual Private Network) es diferente. No solo oculta tu IP, sino que crea un túnel encriptado entre tu dispositivo y el servidor VPN. Todo tu tráfico viaja dentro de ese túnel. Para el mundo exterior, estas saliendo desde la IP de la VPN.

La diferencia crucial: el proxy solo intercepta el tráfico que configuras (típicamente HTTP/HTTPS). La VPN intercepta TODO el tráfico de tu computadora, incluso el que no es web.

Sin embargo, ni el proxy ni la VPN te hacen anónimo. El proveedor de la VPN ve todo tu tráfico. Si el proveedor guarda logs y es requerido por una autoridad, tu anonimato se desvanece.

El Puerto: La Puerta de Entrada al Servidor

Un servidor tiene una sola dirección IP pero miles de puertos. Piensa en la IP como la dirección de un edificio y los puertos como los departamentos.

• Puerto 80: HTTP (sin encriptar)
• Puerto 443: HTTPS (encriptado)
• Puerto 22: SSH (acceso remoto al servidor)
• Puerto 21: FTP (transferencia de archivos)
• Puerto 3306: MySQL (base de datos)

Los atacantes escanean puertos para descubrir que servicios están corriendo en un servidor. Si encuentran el puerto 3306 abierto al internet público, saben que hay una base de datos MySQL expuesta, lo cual es un error grave de configuración.

Un escaneo de puertos con herramientas como Nmap revela el "mapa" del servidor. Por eso los firewalls deben cerrar todos los puertos excepto los estrictamente necesarios.

No necesitan exploits complejos.

La Sesión y las Cookies en Profundidad

HTTP no tiene memoria. No recuerda quien eres entre una petición y la siguiente. Para solucionar esto, los programadores inventaron las sesiones y las cookies.

Cuando inicias sesión en un sitio, el servidor crea un identificador único de sesión (un string larguísimo y aleatorio) y lo guarda en su memoria o en una base de datos de sesiones. Luego le dice al navegador: "Guarda esta Cookie y mandamela cada vez que me pidas algo".

El navegador guarda la Cookie y la reenvia obedientemente en cada petición al mismo dominio. El servidor recibe la Cookie, busca la sesión en su almacén y sabe quien eres.

Problemas de seguridad comunes con sesiones:

Sesión sin caducidad: Si la sesión nunca expira, cualquiera que encuentre la Cookie puede usarla para siempre. Las sesiones deben caducar después de un tiempo de inactividad y definitivamente al cerrar sesión.

Sesión predecible: Si el identificador de sesión es secuencial (ej. usuario_1, usuario_2), un atacante puede adivinar sesiones activas. Los identificadores deben ser criptográficamente aleatorios.

Cookie sin banderas de seguridad: Las cookies deben tener las banderas HttpOnly (no accesible via JavaScript), Secure (solo via HTTPS) y SameSite (no enviada en peticiones de otros sitios).

Fijacion de Sesión (Session Fixation): El atacante obliga a la víctima a usar un identificador de sesión que el atacante ya conoce. Si el sitio no regenera el ID de sesión al iniciar sesión, el atacante puede secuestrar la sesión después de que la víctima se autentique.

Fallo en Cadena: Como se Rompe Todo

Las vulnerabilidades no viven aisladas. Un error pequeño en una capa puede desencadenar una cascada de destrucción.

Ejemplo real de fallo en cadena:

1. Un programador deja abierto el puerto 27017 de MongoDB en el servidor de desarrollo (Error de configuración).
2. Un atacante escanea internet, encuentra el puerto abierto y extrae la base de datos completa (Error de red).
3. La base de datos contenía contraseñas en texto plano porque el programador no implementó hashing (Error de criptografía).
4. Con esas contraseñas, el atacante prueba suerte en otros servicios de la empresa usando las mismas credenciales (Reutilizacion de contraseñas).
5. El atacante accede al correo electrónico del administrador y desde ahí solicita un reseteo de contraseña del servidor principal (Escalada de privilegios).

Ninguno de estos errores por si solo habría sido catastrófico. Pero encadenados, destruyen la empresa.

La lección: la seguridad no es una característica, es una propiedad emergente del sistema. No basta con asegurar una parte; hay que asegurar todo el ecosistema.

Modos de Falla del Arquitecto Web

Estos son los errores más comunes que cometen los arquitectos al diseñar sistemas web, incluso los experimentados.

Confundir autenticación con autorización. Asumen que si el usuario paso el login, puede hacer cualquier cosa dentro del sistema. Esto es el origen del ataque IDOR y de la escalada de privilegios horizontal.

Exponer la base de datos al internet. Directamente. Con puerto abierto. Sin autenticación. Suena increíble pero es el error #1 en filtraciones de datos según los informes de breach de Verizon.

Usar el Frontend para tomar decisiones de seguridad. Poner la validación de "El usuario puede borrar esto?" en JavaScript del navegador. Cualquiera con Burp Suite bypasea esto en segundos.

No validar entradas del usuario. Asumir que el usuario va a enviar exactamente lo que el formulario espera. La realidad es que el usuario (o el atacante) puede enviar cualquier cosa.

Logging insuficiente. No registrar las acciones importantes. Cuando ocurre un breach, no saber que paso, cuando paso ni como entró el atacante. Sin logs, no hay investigación forense posible.

Dependencias sin actualizar. Usar librerías de terceros con vulnerabilidades conocidas. El ataque a Equifax en 2017 ocurrió porque no actualizaron Apache Struts, a pesar de que el parche existia desde meses antes.

El Ángulo del Hacker: Como Piensa un Atacante

Cuando un hacker se enfrenta a una página web desconocida, sigue un proceso mental estructurado. No es un genio del mal sentado en un sótano; es un profesional siguiendo una metodología.

Paso 1: Reconocimiento pasivo. No toca el sitio. Busca información en Google, en registros DNS, en redes sociales de los empleados, en GitHub en busca de código filtrado. Busca subdominios, tecnologías utilizadas, empleados que trabajan ahí.

Paso 2: Reconocimiento activo. Escanea puertos, identifica tecnologías con herramientas como WhatWeb o Wappalyzer, busca archivos robados de configuración, robots.txt, archivos de respaldo.

Paso 3: Enumeración. Identifica parámetros en las URLs, formularios, endpoints de API, cookies. Mapea toda la superficie de ataque. Cada input es un potencial vector.

Paso 4: Prueba de vulnerabilidades. Prueba inyecciones SQL, XSS, CSRF, SSRF, IDOR, subida de archivos, etc. Empieza por lo más fácil y va subiendo en complejidad.

Paso 5: Explotación. Confirma la vulnerabilidad y la explota para obtener acceso o datos.

Paso 6: Movimiento lateral. Una vez dentro, busca otros sistemas, escalar privilegios, encontrar datos más valiosos.

Herramientas que usa: Burp Suite para interceptar y modificar tráfico HTTP, Nmap para escaneo de puertos, SQLMap para automatizar inyecciones SQL, Gobuster para descubrir directorios ocultos, Metasploit para explotación.

Casos Reales de Falla Arquitectónica

Caso Sony PlayStation Network (2011): Un atacante exploto una vulnerabilidad en la versión desactualizada de Apache HTTP Server que corria en los servidores de Sony. El servidor mal configurado permitió acceso a la base de datos de usuarios. Se robaron datos de 77 millones de cuentas, incluyendo números de tarjetas de crédito. Sony tuvo que apagar el servicio durante 23 días, con un costo estimado de $171 millones de dólares.

Caso Equifax (2017): La vulnerabilidad en Apache Struts (CVE-2017-5638) permitió a los atacantes ejecutar código remoto en los servidores de Equifax. La empresa tenía más de 3 meses para aplicar el parche pero no lo hizo. Se expusieron datos de 147 millones de personas: nombres, números de seguro social, fechas de nacimiento, direcciones. La multa y los costos totales superaron los $1,400 millones de dólares.

La lección de Equifax: No es que la vulnerabilidad fuera sofisticada. Es que el proceso de actualización de parches era manual y lento. La seguridad no es solo el código; es el proceso alrededor del código.

Caso Marriott/Starwood (2018): Atacantes estuvieron dentro de la red de Starwood desde 2014. Accedieron a la base de datos de reservas que contenia datos de 500 millones de huespedes. La vulnerabilidad inicial? Un acceso no autorizado a través de herramientas de administración remota mal configuradas. No fue un exploit complejo; fue una puerta abierta que nadie cerró.

Autoevaluación

Revisa si tu mente ya separó el concepto de "Internet" en sus componentes reales:

1. Modificas el código de un juego de navegador usando la consola de Chrome y cambias tus monedas de oro de 10 a 9,999,000. Cuando refrescas la página, vuelves a tener 10 monedas. Por qué el hackeo fallo? (Piensa en la diferencia entre el Menú y la Cocina).

2. Por qué es un error fatal de diseño guardar la regla precio_del_zapato = 50.00 en el código JavaScript que se descarga en el navegador del cliente en lugar de verificarlo en el Servidor?

3. Si un atacante logra robar la Base de Datos entera de contraseñas de los usuarios, a que nivel de la arquitectura tuvo que engañar para acceder a ella?

4. Un arquitecto diseña un sistema donde el Frontend, el Backend y la Base de Datos están en el mismo servidor físico, sin segmentación de red. Que riesgos de seguridad introduce esta decisión frente a un escenario donde el atacante logra subir un archivo malicioso?

5. Tu empresa recibe un reporte de que el identificador de sesión que usas es un número secuencial (12581, 12582, 12583...). Por qué esto es una vulnerabilidad y como deberías generar los IDs de sesión correctamente?

6. Encuentras que el servidor de base de datos de tu empresa tiene el puerto 3306 abierto al internet público. El equipo de sistemas argumenta que "tiene contraseña fuerte, es seguro". Por qué esta confianza esta mal colocada y que podría hacer un atacante incluso sin conocer la contraseña?

7. Durante una auditoría, descubres que la aplicación mobile de la empresa guarda la dirección IP y puerto del servidor de base de datos en texto plano dentro del código de la app. Explica por qué esto es peligroso, incluso si la base de datos requiere autenticación.

8. Un hacker realiza un escaneo de puertos a tu servidor web y encuentra abiertos los puertos 80, 443, y 22. Tu servidor usa contraseñas SSH débiles. Usando el concepto de "Fallo en Cadena", describe como estos dos hallazgos aislados podrían combinarse para comprometer la base de datos.