Fundamentos de Arquitectura Web, Seguridad y Protocolos de Red

P14 - Arquitectura cliente-servidor de la web actual

La web actual sigue un modelo de cliente ligero. El navegador solo se encarga de la presentación: recibe el HTML que genera el servidor y lo renderiza. Sus carencias se suplen con JavaScript, CSS y AJAX, que añaden dinamismo e interactividad en el cliente. Aunque las aplicaciones modernas incorporan cada vez más lógica en el cliente, el modelo base sigue siendo cliente ligero, ya que es el servidor quien procesa y gestiona toda la información.

P15 - Diferencia entre API REST y Sockets

La diferencia radica en el nivel de abstracción sobre la capa de aplicación:

• REST: El protocolo de aplicación es HTTP y Flask lo gestiona todo automáticamente (rutas, métodos GET/POST, cabeceras y códigos de estado). Solo hay que implementar la lógica (nivel de abstracción alto).
• Socket Python: No hay protocolo de aplicación definido; se trabaja directamente sobre TCP recibiendo bytes en crudo. El desarrollador debe gestionar manualmente el formato de los mensajes, el parseo y las conexiones, lo que ofrece mayor control pero aumenta la complejidad.

P16 - Correo HTML y Seguridad

¿Por qué se bloquean las imágenes?

Cuando se recibe un correo HTML con una etiqueta <img src="http://servidor-atacante.com/imagen.jpg">, el cliente de correo (como Outlook) intenta descargar la imagen automáticamente mediante una petición GET al servidor del atacante. En ese momento, el atacante confirma que el correo fue abierto y obtiene la dirección IP y datos del dispositivo del receptor. Por ello, los clientes bloquean las imágenes por defecto para proteger la privacidad del usuario.

¿Cómo se utiliza esto para un ataque CSRF?

Supongamos que el usuario tiene una sesión activa en su banco y este posee una URL que ejecuta una transferencia: http://mibanco.com/transferir?cantidad=1000&destino=atacante. El atacante envía un correo con la etiqueta <img src="http://mibanco.com/transferir?cantidad=1000&destino=atacante">. Si el cliente descarga la imagen automáticamente, el navegador realiza esa petición GET al banco incluyendo la cookie de sesión activa, ya que pertenece al dominio del banco. El servidor recibe la petición con una cookie válida y la ejecuta como si la hubiera iniciado el propio usuario. El atacante no necesita robar la cookie; se aprovecha de que ya está activa y de que el navegador la envía automáticamente en cada petición al dominio correspondiente.

Resumen de conceptos fundamentales

1. Sistemas distribuidos

• P2P: Simétrico (N-N).
• Cliente-servidor: Asimétrico (N-1).
• Invasivos: Nodos pequeños y móviles.
• Computación móvil: Conexión intermitente.
• Openness: Estándares e interfaces públicas (no implica código abierto ni facilidad de uso).
• Escalabilidad: Tamaño, geográfica y administrativa. (La adaptación a distintos dispositivos es heterogeneidad, no escalabilidad).
• Acoplamiento: Temporal (necesitan estar activos al mismo tiempo) y referencial (el emisor sabe a quién escribe).

2. WWW y arquitectura

• HTTP: Sin memoria; las cookies proporcionan memoria.
• Cliente ligero: El navegador solo renderiza HTML del servidor.
• Push: El servidor toma la iniciativa (necesita conocer la dirección del cliente).
• Pull: El cliente solicita la información.
• Diagrama de secuencia: Se realiza una petición GET por cada recurso externo encontrado en el HTML (CSS, imágenes).

3. Tecnologías web

• Solo cliente: CSS, DHTML.
• Solo servidor: SQL, PHP.
• Ambos: HTML, JS, AJAX, JSON, XML, Python.
• DHTML: HTML + CSS + JS manipulando el DOM en el cliente.
• AJAX: Peticiones asíncronas al servidor sin recargar la página.
• Métodos: GET (datos en URL) y POST (datos en el cuerpo). Ninguno es seguro por sí solo.

4. Cookies y sesiones

• Sesión: Relación temporal.
• Cookie: Generada por el servidor, almacenada por el cliente y enviada en cada petición.
• Problemas de seguridad: Man-in-the-middle (solución: HTTPS), CSRF (cookie activa usada por atacante), XSS (solución: HTTPOnly).
• REST: HTTP en aplicación, TCP en transporte.
• Socket Python: Indeterminado en aplicación, TCP en transporte.
• Idempotencia: PUT es idempotente; POST no lo es. GET no garantiza nada técnicamente.