Metodologías OWASP en la Universidad Técnica de Eslovaquia

Tuve el privilegio de dar una sesión en la Universidad Técnica de Eslovaquia, en Bratislava (STU), dentro de la Facultad de Ingeniería Eléctrica e Informática (FEI), por invitación de la profesora Katarína Žáková. El tema: las vulnerabilidades de seguridad de las aplicaciones web escritas en PHP y cómo las metodologías OWASP permiten buscarlas de forma ordenada en lugar de a ojo.

Una sesión práctica, no una exposición

La seguridad se aprende mal en teoría. Así que entramos directamente en vulnerabilidades reales y en las defensas que les corresponden, sin el rodeo habitual por las definiciones.

Hay una razón concreta para hacerlo así. Quien está en esa aula escribe, a dos o tres años vista, el código que acaba en producción en un banco, en una administración o en la aplicación que usa media ciudad. El fallo que nunca llega a escribirse no cuesta nada. El mismo fallo detectado en un pentesting cuesta una jornada de análisis y una ventana de despliegue. Detectado por otra persona, en producción, cuesta una notificación de brecha en 72 horas y una conversación con la Agencia Española de Protección de Datos (AEPD).

1. Vulnerabilidades web habituales y metodología OWASP

Empezamos por los riesgos más frecuentes en una aplicación PHP: de la inyección SQL al cross-site scripting (XSS). Para cada uno, tres preguntas. De dónde sale. Por qué sigue ahí después de veinte años de literatura publicada. Y cómo lo explota un atacante en la práctica, que rara vez coincide con la versión de manual.

Lo que más cuesta transmitir no es la lista, sino el método. El OWASP Top 10 ordena categorías de riesgo por prevalencia e impacto —la inyección ocupa la posición A03 en la edición de 2021— y sirve para priorizar y para explicarle el problema a quien firma el presupuesto. No sirve para probar. Lo que convierte esa lista en un procedimiento es el OWASP Web Security Testing Guide: un catálogo de comprobaciones con identificador propio, del que se recorre lo que aplica al alcance y se deja constancia de lo que no. Del lado del requisito, el OWASP ASVS hace lo mismo con lo que la aplicación debería cumplir antes de salir.

La diferencia práctica es sencilla de enunciar y difícil de interiorizar: con una metodología dejas de buscar lo que se te ocurre y pasas a recorrer un catálogo. Un informe que cita el identificador de la comprobación dice qué se probó; un informe que dice «se revisó la autorización» no dice nada verificable.

Conviene recordar además que todo ese material es abierto, gratuito y no pertenece a ningún proveedor. OWASP funciona con capítulos locales —en España hay actividad regular en Madrid y Barcelona—, así que asistir a una sesión y leer las guías no depende de contratar a nadie. Nosotros trabajamos sobre esos mismos documentos: así lo contamos en nuestras metodologías de testing y, en detalle, en la página de OWASP.

2. Código PHP vulnerable y código PHP correcto, uno al lado del otro

La teoría no basta. Leímos código vulnerable, identificamos qué lo hacía peligroso y recorrimos después la versión corregida. Ver las dos juntas hace evidente algo que ninguna regla abstracta consigue.

El primer par fue el clásico:

// Vulnerable: el parámetro se concatena dentro de la consulta
$id  = $_GET['id'];
$sql = "SELECT * FROM usuarios WHERE id=" . $id;
$res = $pdo->query($sql);

// Correcto: consulta preparada, el dato nunca llega a ser código
$stmt = $pdo->prepare('SELECT * FROM usuarios WHERE id=:id');
$stmt->execute(['id' => $_GET['id']]);
$fila = $stmt->fetch();

El segundo, el equivalente en la salida:

// Vulnerable: la entrada se imprime tal cual
echo '<p>Hola, ' . $_GET['nombre'] . '</p>';

// Correcto: se escapa en el punto de salida y según el contexto
echo '<p>Hola, ' . htmlspecialchars($_GET['nombre'], ENT_QUOTES, 'UTF-8') . '</p>';

La lección no es «hay que validar la entrada», que es la conclusión que casi todo el mundo saca y la que deja la aplicación igual de rota. La lección es que el problema aparece cuando un dato acaba interpretado como código, y que se resuelve separando los dos en el punto donde se juntan: parámetros enlazados en la consulta, escapado en la salida y elegido según el contexto —HTML, atributo, JavaScript o URL no se escapan igual—. Limpiar la entrada por si acaso, a la entrada y de una sola manera, es la defensa que se cae en cuanto el dato viaja a un contexto distinto.

3. Demostración de ataque en directo

El momento fuerte de la sesión fue una inyección SQL ejecutada en directo, paso a paso, hasta sacar el contenido de la tabla de credenciales. Ver el ataque ocurrir de verdad, con la respuesta del servidor cambiando delante de todo el mundo, transmite algo que un esquema en una diapositiva no transmite: una línea escrita con prisa abre la base de datos entera, y no hace falta ninguna herramienta sofisticada para comprobarlo.

Nota sobre el marco legal, que en clase se dice siempre: la demostración se hizo sobre una aplicación de laboratorio montada para eso. La técnica es idéntica fuera del laboratorio y lo único que cambia es la autorización. Los mismos comandos contra un sistema ajeno encajan en los arts. 197 bis y 264 del Código Penal. En un proyecto real, el alcance, la ventana de ejecución y las personas de contacto se cierran por escrito y los firma quien tiene potestad para hacerlo, antes de lanzar la primera petición.

Qué conviene retener

La seguridad empieza en el código

Escribir una aplicación segura no consiste en aplicar una lista de buenas prácticas, sino en entender cómo razona un atacante. Identificar y tratar el riesgo durante el desarrollo cuesta una fracción de lo que cuesta la misma corrección en producción, y en España hay ya varios instrumentos que lo dan por supuesto:

• RGPD. El art. 25 exige protección de datos desde el diseño y por defecto. El art. 32.1.d) pide «un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas», que es, palabra por palabra, la razón por la que una aplicación se prueba de forma periódica y no una sola vez.
• ENS. Si tu organización entra en el ámbito del Esquema Nacional de Seguridad (RD 311/2022), el Anexo II dedica dos medidas al software propio: mp.sw.1 Desarrollo de aplicaciones y mp.sw.2 Aceptación y puesta en servicio, que obliga a comprobar la aplicación antes de ponerla en producción.
• Guías públicas. El CCN publica la guía CCN-STIC 812 sobre seguridad en entornos y aplicaciones web, e INCIBE mantiene material divulgativo de desarrollo seguro dirigido a empresa. Ambas cosas son documentación abierta y se citan como tal.
• NIS2. A 12 de septiembre de 2026 la Directiva (UE) 2022/2555 sigue sin estar transpuesta en España, así que no impone todavía obligaciones exigibles a las entidades; lo explicamos en NIS2 en España: qué obliga hoy y qué no.

Ninguna de esas referencias sirve de mucho en un aula de segundo curso. Sirven después, cuando el mismo código pasa por un pliego o por una auditoría, y entonces la pregunta ya no es si el fallo existe, sino quién puede demostrar que se buscó.

La defensa cuenta tanto como el ataque

Las técnicas ofensivas sirven para entender los fallos; el objetivo sigue siendo construir aplicaciones que aguanten. La seguridad forma parte del desarrollo y no llega al final como un trámite de validación, igual que no se prueba la resistencia de un puente el día de la inauguración.

Ahí está la asimetría de siempre, y merece la pena decirla tal cual: quien ataca necesita encontrar un camino, quien defiende tiene que cerrarlos todos. Ese reparto no se equilibra con más herramientas, se equilibra con método. Por eso la metodología importa más que el truco concreto, y por eso una sesión de dos horas sobre cómo se recorre un catálogo de comprobaciones vale más que una colección de exploits que caducan en seis meses.

Por qué volvemos al aula

La ciberseguridad se mueve rápido y la enseñanza es la parte que mejor amortiza. Un fallo explicado a tiempo a un aula entera de gente que va a escribir código profesionalmente rinde bastante más que el mismo fallo encontrado tarde en una aplicación. Gracias a la profesora Katarína Žáková y a la FEI STU por la invitación, y a quienes se quedaron preguntando cuando la sesión ya había terminado, que suele ser la mejor parte.

Aplicamos exactamente los mismos catálogos en proyecto. Si quieres ver cómo se traduce esto a un encargo, mira nuestras metodologías de testing y el detalle de OWASP, o directamente el servicio: pentesting de aplicaciones web.

Nuestros servicios relacionados: la metodología de nuestros tests de intrusión · pentesting de aplicaciones web y API