Bienvenido

Orlando Flores Teomitzi — Thu, 23 Oct 2025 00:00:00 GMT

Me alegra que estés aquí. Este espacio es donde comparto mi recorrido por la tecnología, la creatividad y el aprendizaje continuo. Encontrarás publicaciones sobre desarrollo de software, proyectos personales y reflexiones sobre temas variados que me inspiran, desde la innovación y el diseño hasta la productividad y las lecciones de vida.

Mi objetivo es crear contenido que no solo muestre mi trabajo, sino que también aporte valor a quienes comparten la misma curiosidad y pasión por la tecnología. Ya sea que vengas a explorar ideas, aprender algo nuevo o simplemente inspirarte, espero que disfrutes tu visita y encuentres algo significativo.

Mis notas sobre el modelo C4

Orlando Flores Teomitzi — Wed, 19 Nov 2025 00:00:00 GMT

C4 es una forma de dibujar un sistema de software. En lugar de un solo diagrama enorme con todo adentro, haces varios diagramas, cada uno con un nivel de detalle distinto. Funciona como un mapa: primero el país, luego la ciudad y al final la calle.

flowchart TD
    L1[1. Contexto] --> L2[2. Contenedores]
    L2 --> L3[3. Componentes]
    L3 --> L4[4. Código]

Los cuatro niveles

1. Contexto. El sistema como una sola caja, con los usuarios y los otros sistemas a su alrededor. Muestra qué es el sistema y quién lo usa.

2. Contenedores. Abro la caja y veo las partes que se ejecutan por sí solas: una app web, una API, una base de datos. Muestra cómo se comunican entre sí.

3. Componentes. Abro un contenedor y veo las piezas que tiene dentro y cómo interactúan.

4. Código. Las clases e interfaces detrás de un componente.

Cómo construir uno

Voy de afuera hacia adentro:

Defino el contexto: reúno los requisitos y decido qué queda fuera del sistema.
Divido el sistema en contenedores y mapeo cómo se relacionan.
Divido cada contenedor en componentes y mapeo cómo interactúan.
Detallo el código, solo donde valga la pena.

Buenas prácticas

Ser consistente en la forma de dibujar.
Elegir el nivel de detalle y mantenerse en él.
Construir los diagramas con el equipo.
Refinarlos en iteraciones.
Agregar títulos y descripciones.
Compartir lo que aprendes.

Lo que me llevo de esto

Elige el nivel que le sirva a la persona con la que estás hablando y detente ahí. Un diagrama que intenta mostrarlo todo no le sirve a nadie.

Referencias

The C4 model

Lo que aprendí sobre XSS

Orlando Flores Teomitzi — Mon, 10 Aug 2026 00:00:00 GMT

Últimamente he estado estudiando seguridad web, y XSS es el tema que más me hizo detenerme a pensar. Para entenderlo mejor construí un repo pequeño con una demo por cada idea: devtalks-xss. Estas son mis notas, escritas tal como las entendí.

:::warning Las demos son vulnerables a propósito. Ejecútalas solo en tu propia máquina, nunca las despliegues, y prueba únicamente en sistemas donde tengas permiso de hacerlo. :::

Qué es

El navegador no puede distinguir qué partes de una página las escribió el desarrollador y cuáles vienen de un usuario. Si una app mete datos del usuario en una página sin tratarlos antes, el navegador los ejecuta como si fueran parte del sitio. Eso es XSS.

Siempre sigue el mismo camino: la app recibe algo que controla un usuario, lo pone en la página y el navegador lo ejecuta.

flowchart LR
    A[Entrada no confiable] --> B[Aplicación vulnerable]
    B --> C[Respuesta HTML o actualización del DOM]
    C --> D[Navegador de la víctima]
    D --> E[El contenido inyectado se ejecuta]

Cambiar cómo se ve una página no basta para llamarlo XSS. Eso es inyección de HTML. Solo es XSS cuando realmente se ejecuta código.

Los tres tipos

flowchart TD
    X[XSS] --> R[Reflejado]
    X --> S[Almacenado]
    X --> D[Basado en DOM]

Reflejado. El servidor devuelve la entrada tal cual en la respuesta. No se guarda nada, así que la víctima tiene que abrir un enlace preparado o enviar un formulario preparado. En mi demo (01-reflected) es una sola página con un input: lo que escriba va directo a la página con innerHTML, sin sanitizar.

sequenceDiagram
    participant A as Atacante
    participant V as Víctima
    participant S as Sitio vulnerable
    A->>V: Envía un enlace manipulado
    V->>S: Abre la URL
    S-->>V: Devuelve la entrada sin codificar
    Note over V: El navegador ejecuta el script

Almacenado. La entrada se guarda, y cada visitante que la carga la ejecuta. Este es el que más miedo me da porque nadie tiene que hacer clic en nada. Mi demo (02-stored) es un chat pequeño con Express y SQLite. Los mensajes se guardan tal como llegan y se muestran con innerHTML, así que un solo mensaje malicioso se dispara para todos los que abran la página.

sequenceDiagram
    participant A as Atacante
    participant S as Aplicación
    participant D as Almacenamiento
    participant V as Visitantes
    A->>S: Envía contenido malicioso
    S->>D: Lo guarda
    loop En cada visita a la página
        V->>S: Piden la página
        S->>D: Lee el contenido
        S-->>V: Devuelve HTML sin sanitizar
    end

Basado en DOM. Todo ocurre en el navegador. El JavaScript del propio sitio toma datos de un lugar no confiable, como la URL, y los escribe en un lugar que interpreta HTML. El servidor nunca lo ve, así que sus logs ayudan poco. Mi demo (03-dom-based) es un router diminuto del lado del cliente que lee el nombre de la sección desde location.hash y lo escribe con innerHTML. La parte de la URL después del # nunca se envía al servidor, así que todo sucede en el navegador.

flowchart TD
    A[Origen: URL, hash o postMessage] --> B[JavaScript del sitio]
    B --> C[Destino inseguro: innerHTML o document.write]
    C --> D[DOM modificado]
    D --> E[El código inyectado se ejecuta]

Los filtros no te salvan

Mi primera idea fue simplemente bloquear las palabras peligrosas. No funciona. HTML y JavaScript pueden decir lo mismo de muchas maneras, así que una lista de bloqueo siempre deja algo fuera.

flowchart TD
    A[Filtro basado en patrones] --> B{Busca una sola forma}
    B --> C[Cambios de mayúsculas]
    B --> D[Otra etiqueta o evento]
    B --> E[Espacios y comillas]
    B --> F[Codificación]
    C --> G[Posible evasión]
    D --> G
    E --> G
    F --> G

Lo que obtiene el atacante

El código se ejecuta como el sitio, así que puede hacer lo que el sitio puede hacer. Puede leer lo que muestra la página, modificarla, actuar como el usuario o robar una sesión si la cookie está expuesta. Mientras más privilegios tenga la víctima, peor es. Otras dos demos muestran cómo XSS se combina con otras fallas:

XSS + CSRF (04-xss-csrf). Una sección de comentarios con XSS almacenado llama en silencio a un endpoint que cambia el correo de la víctima. Como el script corre dentro del sitio, el navegador envía la sesión de la víctima y el endpoint no tiene un token CSRF que lo detenga. Incluso con un token, un script que corre en la misma página podría leerlo.
XSS + SSRF (05-xss-ssrf). Una función de "vista previa de URL" hace que el servidor consulte cualquier URL. Sin una lista de permitidos, puede llegar a un servicio interno que nunca debió ser público, y luego muestra la respuesta con innerHTML. Dos fallas que se alimentan entre sí.

Lo que realmente te protege

Ninguna cosa por sí sola basta, así que lo pienso en capas:

Codifica la salida según el lugar al que va.
Evita los destinos inseguros del DOM. Usa textContent.
Si tienes que permitir HTML, usa un sanitizador mantenido. No escribas el tuyo.
Agrega una Content Security Policy.
Marca las cookies de sesión como HttpOnly, Secure y SameSite.
Valida la entrada, pero nunca dependas solo de eso.
Usa plantillas que escapen por defecto.

flowchart LR
    A[Entrada no confiable] --> B[Validación]
    B --> C[Procesamiento]
    C --> D[Codificación según el contexto]
    D --> E[Salida segura]
    F[CSP y cookies reforzadas] -. defensa adicional .-> E

Para las demos encadenadas, arregla primero el XSS. Después agrega tokens CSRF y revisa Origin en los endpoints que cambian estado. Para SSRF, define una lista de URLs que el servidor puede consultar, bloquea los rangos de IP privadas y nunca muestres contenido consultado con innerHTML.

Lo que me llevo de esto

El objetivo no es reconocer todos los payloads posibles. Es asegurarte de que los datos nunca se traten como código. Codifica a la salida y agrega capas detrás.

Puedes ejecutar las cinco demos desde el repo. Romper algo a propósito me enseñó más que leer sobre ello.