OWASP Top 10: vulnerabilidades de seguridad web
Repasamos en lenguaje sencillo los diez riesgos de seguridad web más comunes y la medida concreta que debe tomar el desarrollador para cada uno, con ejemplos de código.
Aurora YazılımEquipo editorial
6 min de lectura
El OWASP Top 10 es la lista de referencia, publicada por la comunidad sin ánimo de lucro OWASP, que ordena los diez riesgos de seguridad más críticos de las aplicaciones web. Entre ellos están los fallos de control de acceso, la inyección (como la SQL injection), los fallos criptográficos y la configuración insegura. La lista se utiliza como marco de formación y auditoría para la programación segura.
¿Qué es OWASP y la lista Top 10?
OWASP (Open Worldwide Application Security Project) es una comunidad abierta que produce recursos, herramientas y guías gratuitas sobre seguridad del software. Su trabajo más conocido es la lista Top 10, que se actualiza cada pocos años.
La lista no es un estándar ni una certificación; es un documento de concienciación. Se elabora combinando datos abiertos del mundo real y opiniones de expertos, y le dice al desarrollador: «fíjese primero en esto». En este artículo tomamos como base las categorías de la versión de 2021, ampliamente aceptada.
La lista cambia con el tiempo; en las nuevas versiones las categorías se reordenan o se fusionan. Compruebe siempre la versión vigente en la fuente oficial, owasp.org.
1–2. Control de acceso y cifrado
Los dos primeros puestos de la lista tienen que ver con a quién se muestran los datos y cómo se protegen. Ambas están entre las vulnerabilidades más frecuentes y de consecuencias más graves, porque afectan directamente a los datos de los clientes.
Control de acceso defectuoso
El fallo de control de acceso consiste en que un usuario pueda acceder a datos u operaciones para los que no tiene autorización. Ejemplo clásico: un cliente que cambia el valor siparis/1052 de la barra de direcciones por 1053 y ve el pedido de otra persona.
La medida es sencilla, pero exige disciplina: en cada petición, en el lado del servidor, hay que volver a plantear la pregunta «¿puede este usuario ver este registro?». El comportamiento por defecto debe ser denegar; el acceso solo se abre en los casos expresamente permitidos.
Fallos criptográficos
En este apartado entran los datos sensibles que se transportan o se almacenan sin cifrar. Guardar contraseñas en texto plano o con métodos débiles, no usar HTTPS y emplear algoritmos de cifrado obsoletos son los ejemplos más habituales.
Para las contraseñas deben usarse métodos de hash lentos diseñados para ello, como bcrypt o Argon2; todo el tráfico debe viajar por HTTPS y las claves de cifrado deben guardarse en un entorno seguro, no dentro del código.
3. Inyección: SQL injection y XSS
Que los datos que llegan del usuario se ejecuten como parte de un comando es una vulnerabilidad de inyección. Sus tipos más conocidos son la SQL injection y el XSS. En la lista de 2021, el XSS también se trata dentro de esta categoría.
¿Qué es la SQL injection?
La SQL injection consiste en alterar la consulta a la base de datos mediante caracteres especiales escritos en un formulario o en la barra de direcciones. El atacante puede robar o borrar datos, o acceder sin autorización. La solución es construir la consulta no concatenando texto, sino con consultas preparadas (prepared statements).
// MAL: la entrada del usuario se añade directamente a la consulta
$sql = "SELECT * FROM uyeler WHERE eposta = '" . $_POST['eposta'] . "'";
// BIEN: consulta preparada
$stmt = $pdo->prepare('SELECT * FROM uyeler WHERE eposta = ?');
$stmt->execute([$_POST['eposta']]);
$uye = $stmt->fetch();¿Qué es el XSS?
El XSS (Cross-Site Scripting) consiste en que el atacante inserta JavaScript en la página. Un script introducido en un campo de comentarios puede ejecutarse en el navegador de todo el que abra esa página. Aplicar un escape adecuado al contexto al mostrar la salida en pantalla y añadir la cabecera de Política de Seguridad de Contenido (CSP) son las medidas básicas.
echo htmlspecialchars($yorum, ENT_QUOTES, 'UTF-8');4–5. Diseño inseguro y configuración
Estas dos categorías tienen que ver menos con el código en sí que con las decisiones: cómo se concibe el sistema y cómo se configura el servidor. La buena noticia es que ambas pueden prevenirse en gran medida con procesos y listas de comprobación.
Diseño inseguro
Esta categoría describe más un error de diseño que un error de código. Por ejemplo, fiarse en el restablecimiento de contraseña solo de una pregunta de seguridad fácil de adivinar, o permitir probar sin límite un código promocional. Aunque el código esté escrito a la perfección, el fallo de diseño no se cierra.
La medida es pensar en la seguridad al principio del desarrollo y no al final: el modelado de amenazas, los escenarios de uso indebido y la limitación del número de intentos (rate limiting) deben tratarse en la fase de diseño.
Errores de configuración de seguridad
Aquí entran no cambiar las contraseñas por defecto, mostrar detalles del servidor en los mensajes de error, dejar servicios innecesarios abiertos o dejar activado el listado de directorios. Muchas veces son las vulnerabilidades que se explotan con más facilidad.
Medida: preparar una lista de bastionado escrita para el servidor y la aplicación, desactivar los detalles de error en producción, añadir cabeceras de seguridad (como HSTS, CSP y X-Content-Type-Options) y auditar la configuración con regularidad.
6–7. Componentes y autenticación
Los riesgos del sexto y séptimo puesto se refieren a las piezas que la aplicación toma del exterior y a la forma de verificar quién es el usuario. Ambos requieren un mantenimiento regular; no basta con configurarlos una vez y olvidarse.
Componentes antiguos y vulnerables
Una aplicación moderna usa decenas, incluso cientos, de bibliotecas externas. Cuando se descubre una vulnerabilidad en una de ellas, su aplicación queda en riesgo aunque usted no haya cometido ni un solo error.
Medida: llevar una lista de los componentes que se usan, seguir los avisos de seguridad y actualizar con regularidad. Los comandos de auditoría de los gestores de paquetes facilitan esta tarea. Eliminar las dependencias que no se usan es también una de las medidas de seguridad más baratas.
npm audit
composer auditFallos de autenticación
En esta categoría entran permitir contraseñas débiles, estar expuesto a intentos de inicio de sesión ilimitados, guardar de forma insegura los identificadores de sesión o no cerrar la sesión al cerrar sesión el usuario.
Medida: limitar el número de intentos, ofrecer verificación en dos pasos, comprobar las contraseñas frente a listas filtradas y configurar las cookies de sesión con los atributos HttpOnly, Secure y SameSite.
8–10. Integridad, registros y SSRF
Integridad del software y de los datos
Ejecutar sin verificar actualizaciones, plugins o la cadena de despliegue automático abre una puerta al atacante. Los paquetes firmados, las fuentes de confianza y el control de la cadena de suministro son la base de la medida.
Falta de registro y monitorización
Si un ataque pasa inadvertido, el daño crece. Deben registrarse los inicios de sesión fallidos, los errores de autorización y las operaciones críticas, y generarse alertas ante situaciones anómalas. En los registros no deben escribirse datos sensibles como contraseñas.
SSRF
El SSRF (Server-Side Request Forgery) consiste en forzar al servidor a hacer una petición a una dirección procedente del usuario. Por esa vía, el atacante puede llegar a servicios de la red interna. La medida básica es usar una lista de permitidos para las direcciones a las que se puede acceder.
Lista de comprobación para una programación segura
La mayoría de las vulnerabilidades se pueden evitar con unos pocos hábitos básicos. Puede usar la siguiente lista en las revisiones de código y en las comprobaciones previas a la publicación. Cómo se relacionan los procesos de pruebas con la seguridad lo tratamos en nuestro artículo qué son las pruebas de software.
- No confíe nunca en la entrada: valide todas las entradas en el lado del servidor.
- Use consultas preparadas: no construya el SQL concatenando texto.
- Escape la salida: según el contexto HTML, URL y JavaScript.
- Compruebe la autorización en cada petición: ocultarla en la interfaz no basta.
- Separe la información secreta del código: las claves, en variables de entorno o en una caja fuerte de secretos.
- Mantenga las dependencias al día: ejecute con regularidad el comando de auditoría.
- Registre y monitorice: detecte los eventos sospechosos.
La aportación de los lenguajes y herramientas seguros
Algunos tipos de vulnerabilidades también pueden reducirse mediante la elección del lenguaje y de las herramientas. Por ejemplo, los lenguajes que garantizan la seguridad de memoria evitan en gran medida los desbordamientos de memoria, frecuentes en C y C++; este tema lo tratamos en nuestro artículo qué es Rust. WebAssembly, que se ejecuta en el navegador dentro de un entorno aislado seguro, se basa también en una lógica de aislamiento similar.
Aun así, ningún lenguaje resuelve por sí solo un fallo de control de acceso o de diseño. En las aplicaciones web, gran parte de la seguridad depende de los hábitos y los procesos del equipo.
En Aurora Yazılım, estos principios básicos se aplican como parte del proceso de desarrollo en los proyectos de soluciones de software sectoriales, de web corporativa y de plataforma e-commerce.
Preguntas frecuentes
01¿Es obligatorio por ley cumplir el OWASP Top 10?
No es una ley directamente. Pero muchas auditorías de seguridad, requisitos de infraestructuras de pago y contratos corporativos toman esta lista como referencia. En los sistemas que tratan datos personales, consulte la normativa vigente y a su asesor jurídico sobre las obligaciones de seguridad del KVKK (la ley turca de protección de datos, comparable al RGPD).
02¿Cómo sé si mi sitio tiene vulnerabilidades?
Las herramientas de escaneo automático pueden detectar errores de configuración conocidos y componentes antiguos. Para los fallos de control de acceso y de diseño se necesitan, en cambio, un test de intrusión y una revisión de código realizados por expertos. Pruebe únicamente los sistemas para los que tenga autorización.
03¿También atacan a un sitio pequeño?
Sí. La mayor parte de los ataques los realizan bots que rastrean de forma automática vulnerabilidades conocidas, sin elegir un objetivo concreto. Por eso los sitios pequeños también necesitan componentes actualizados y una configuración correcta.
El OWASP Top 10 es un mapa fiable de por dónde empezar en la seguridad web; los fallos de control de acceso, de inyección y de configuración están en el origen de la mayoría de las vulnerabilidades. Para un sistema desarrollado con principios de seguridad, puede consultar nuestras soluciones de software, abordar la velocidad y la salud de su sitio actual con nuestro servicio de velocidad y rendimiento o ponerse en contacto con nosotros.
