ICIB

05 - Seguridad en aplicaciones

Se lee en 29 min

Seguridad en el desarrollo de aplicaciones

Objetivos: Al terminar este tema, podrás…

  • Explicar qué es una vulnerabilidad en una aplicación y por qué ocurren
  • Identificar las fallas de seguridad más comunes según OWASP
  • Describir los principios básicos que guían el desarrollo seguro
  • Reconocer, inspeccionando sitios reales, la huella observable de un buen o de un mal desarrollo seguro
  • Experimentar ataques reales contra aplicaciones en un entorno controlado

Apertura: el número que se podía cambiar

Laura entra al portal de su EPS para descargar el resultado de un examen de sangre. La dirección que aparece en el navegador termina en /resultados/ver?id=48213. Mientras espera que cargue el PDF, por curiosidad cambia el número a 48214 y presiona Enter. La pantalla le muestra el resultado de otra persona, con nombre completo, número de cédula y diagnóstico. Prueba con 48215 y aparece otro. Cierra el navegador, incómoda, y se queda pensando en quién más habrá hecho lo mismo.

(Escenario ficticio, construido a partir de un patrón de fallo real y frecuente en aplicaciones web. No corresponde a ninguna EPS en particular.)

El portal no se rompió ni mostró un error, sino que respondió a Laura igual que le responde a cualquier usuario que pide un resultado: fue a buscar el archivo 48214 y lo entregó. Lo que faltó fue la otra mitad del trabajo, comprobar que ese archivo era de quien lo estaba pidiendo. El número que viaja en la dirección después del signo de interrogación se llama parámetro, y cualquiera puede cambiarlo en la barra de direcciones antes de pulsar Enter. El problema no es que el parámetro se pueda cambiar, sino que el servidor lo haya tratado como una credencial.

Lo que le pasó a Laura tiene un nombre técnico, control de acceso roto, y es una de las cinco fallas de seguridad que vas a trabajar hoy. Las cinco comparten la misma raíz, y esa raíz es lo primero que se explica al terminar la apertura.

Explicación: por qué fallan las aplicaciones y las cinco fallas más comunes

La apertura dejó una idea sobre la mesa: una aplicación puede atender a todos sus usuarios normales sin un solo error y aun así estar rota, porque en algún punto confió en un dato que en realidad controla quien la usa. Antes de ver dónde reaparece esa idea, conviene fijar el término que va a repetirse toda la clase. Una aplicación es un conjunto de instrucciones escritas por personas, y las personas cometemos errores. Cuando un error tiene como efecto que alguien pueda leer, cambiar o impedir el acceso a algo que no le corresponde, ese error se llama vulnerabilidad. No es lo mismo que un fallo que hace que el programa se caiga o muestre un mensaje raro: una vulnerabilidad puede convivir durante años con un programa que funciona de maravilla, y solo se nota cuando alguien con mala intención la aprovecha.

Las vulnerabilidades aparecen por razones que se repiten. A veces es un error de confianza, cuando quien programa da por hecho que el usuario solo va a enviar datos válidos. A veces es un error de diseño, cuando la lógica del sistema nunca contempló que alguien pudiera actuar de mala fe. A veces es un error de implementación, cuando una idea correcta en teoría queda mal ejecutada en el código. Y a veces es un componente desactualizado, una pieza de software con fallas ya conocidas y publicadas que nadie se ocupó de cambiar. Tu trabajo como ingeniero de seguridad no es escribir todo el código, sino anticipar dónde se pueden romper esos supuestos y diseñar controles que lo impidan.

Para hablar de estas fallas con un vocabulario común, la industria usa una lista que mantiene OWASP (Open Web Application Security Project), una organización internacional sin ánimo de lucro. Esa lista, el OWASP Top 10, reúne las diez categorías de vulnerabilidades más críticas en aplicaciones web y es el punto de referencia para decidir qué problemas atender primero. En la versión vigente, de 2021, el control de acceso roto encabeza el ranking, por delante de la inyección. Esta clase trabaja cinco de esas diez categorías; las otras cinco quedan nombradas en la lectura disponible.

Las cinco categorías de hoy son variaciones de la misma idea de fondo. La inyección ocurre cuando la aplicación mezcla en un solo texto las instrucciones del sistema y lo que escribió el usuario, y termina obedeciendo órdenes disfrazadas de datos. La autenticación rota ocurre cuando los mecanismos para comprobar quién eres están mal hechos, y alguien puede hacerse pasar por otro. Las fallas criptográficas, también llamadas exposición de datos sensibles, ocurren cuando la información confidencial viaja o se guarda sin la protección debida. El control de acceso roto es lo que vivió Laura: el sistema entrega un recurso sin comprobar que quien lo pide tiene permiso sobre él. Y la configuración insegura ocurre cuando el sistema quedó mal ajustado, con contraseñas de fábrica sin cambiar o con servicios internos accesibles desde internet.

Puesto de otro modo, en casi todos los casos la aplicación confió en un dato que en realidad controla quien la usa. El texto que llega de un formulario, el número que viaja en una URL o la cookie que presenta el navegador son todos cosas que el usuario puede cambiar, y tratarlas como si fueran verdad comprobada es el origen de la falla. La defensa general tiene nombre, validación de entrada: todo dato que llega desde fuera de la aplicación se verifica antes de usarse, y nunca se trata como si fuera una instrucción. Cada una de las cinco categorías rompe además una de las propiedades que estudiaste en la clase 02; la tabla que empareja cada falla con la propiedad que rompe está en la lectura disponible «Por qué fallan las aplicaciones y las categorías de OWASP», junto con el detalle de cada categoría y las otras cinco que no vemos hoy.

Con las cinco categorías sobre la mesa, el resto de la sesión es ir a mirar: comprobar si esos principios abstractos dejan una huella visible en aplicaciones reales, y si instituciones que manejan datos igual de delicados los protegen igual de bien.

Laboratorio: predice, inspecciona, compara

Cada grupo escribe primero una predicción de lo que espera encontrar y después pasa poco más de veinte minutos inspeccionando el sitio de una institución real: una universidad pública, una EPS, un banco, un portal de trámites del Estado y una gran tienda en línea. La regla que ordena todo el ejercicio es que solo se observa. Miras lo que tu propio navegador ya recibió al cargar una página pública: no envías formularios, no escribes credenciales, no cambias identificadores en las URL y no repites peticiones de forma automática. Hacer cualquiera de esas cosas contra un sistema real sin autorización expresa es un delito en Colombia, y lo vas a ver con detalle en la clase 09.

Puesta en común

Cada grupo tiene dos minutos para contar lo que encontró en el sitio que le tocó, con vocero rotativo. Puestos los cinco reportes uno al lado del otro, en una tabla con una fila para la calificación de cabeceras, otra para la expiración de la sesión y otra para el hallazgo más grave, lo que suele aparecer es que instituciones que manejan datos igual de delicados no los protegen igual de bien. Esas diferencias, y sobre todo las que sorprenden, como un banco que quedó peor que una universidad, son el material del debrief.

Debrief y cierre

Aquí se cierran los hilos de la sesión y aparece, por primera vez en clase, el vocabulario de los principios del desarrollo seguro. A partir de lo que cada grupo vio en su sitio, la clase reúne una lista de reglas que los desarrolladores respetaron o rompieron, y esas reglas se ordenan en cinco principios: nunca confiar en datos externos, mínimo privilegio, defensa en profundidad, fallar de forma segura y seguridad desde el diseño. Dos de ellos salen casi solos de lo que se observó en el laboratorio; los otros tres hay que nombrarlos con un hallazgo concreto como ancla, porque no se dejan deducir mirando un sitio desde fuera. La versión desarrollada de los cinco, con el diagrama de capas de la defensa en profundidad y el detalle de qué significa fallar de forma segura, está en la lectura disponible «Principios del desarrollo seguro y el ciclo de vida».

Después se cierra el círculo de la apertura: la comprobación que quedó escrita en el tablero, que el servidor verifique en cada acceso que quien pide un recurso tiene permiso sobre él, es exactamente el control de acceso roto, o IDOR, que los grupos rastrearon en la Tarea C.

Lo que queda de esta clase está escrito y te espera sin fecha encima, como lectura disponible. La primera, «Por qué fallan las aplicaciones y las categorías de OWASP», recoge y ordena lo que se explicó hoy: la definición de vulnerabilidad y sus causas, qué es un parámetro de una URL, las cinco categorías con su analogía y su prevención, la tabla que empareja cada una con una propiedad de CIAAN, y las otras cinco categorías del Top 10. La segunda desarrolla los cinco principios del desarrollo seguro y cómo se integran en el ciclo de vida del software. Ninguna es obligatoria antes de la próxima sesión. Al final de la primera, la tabla de conceptos clave reúne los términos de hoy con sus enlaces al glosario.

Preguntas de reflexión

  1. En la puesta en común comparaste lo que encontró tu grupo con lo que encontraron los otros cuatro. Nombra el sitio que te tocó, nombra una cabecera de seguridad que le faltaba y explica con tus palabras qué ataque concreto se vuelve más fácil cuando esa cabecera no está. ¿En qué se equivocó la predicción que tu grupo escribió antes de abrir la herramienta?

  2. Elige un servicio web donde tengas cuenta y que uses de verdad (tu correo, el aula virtual, tu banco, una red social) y nómbralo. Abre su página de inicio de sesión y comprueba tres cosas: ¿carga por HTTPS con candado?; con F12 en la pestaña Elementos, usando Ctrl+F para buscar hidden, ¿cuántos campos ocultos tiene el formulario y cuál es el name de uno de ellos, copiado literal?; en F12, sección Aplicación, Cookies, ¿la cookie que parece de sesión trae la marca Secure? Describe qué encontraste en ese servicio concreto y con qué categoría del OWASP Top 10 se relaciona cada observación.

  3. Durante la puesta en común quedó en el tablero una tabla con las cinco instituciones. Copia la fila de tu institución y la de otra que te haya sorprendido (por ejemplo, una que maneja datos más sensibles y quedó peor protegida). Para cada diferencia concreta entre las dos filas, explica qué decisión de desarrollo o de configuración la produce. No basta con decir «una tiene más presupuesto»: nombra la comprobación, la cabecera o la marca de cookie que está en una fila y no en la otra.

  4. En el debrief nombramos cinco principios del desarrollo seguro a partir de lo que vieron los grupos. Toma el de «fallar de forma segura»: cuando algo va mal técnicamente, el sistema asume la posición más restrictiva y niega por defecto. Ese principio puede chocar con la disponibilidad, una de las propiedades de CIAAN que estudiaste en la clase 02: un sistema que niega ante cualquier duda también deja fuera a usuarios legítimos cuando falla. Piensa en el sitio concreto que inspeccionó tu grupo (nómbralo) y en el tipo de institución que es. Describe una situación realista en la que ese sitio tuviera que elegir entre fallar cerrado (proteger, aunque nadie pueda entrar) y fallar abierto (seguir disponible, aunque baje la protección). Toma una posición sobre qué debería priorizar ese sitio en concreto y por qué, y luego escribe el contraargumento más fuerte que te podrían hacer.

  5. El principio de mínimo privilegio y el de defensa en profundidad pueden estorbarse: cada comprobación que agregas para frenar a un atacante es también una puerta más donde una persona autorizada puede quedar bloqueada. En la Tarea C miraste identificadores en las URL de un sitio real. Describe una URL concreta que hayas visto (di el sitio y la forma de la URL, sin incluir datos personales) donde aparecía un identificador de un recurso. Si el servidor añadiera una comprobación de permiso en cada acceso a ese recurso, ¿qué uso legítimo podría romperse? Piensa en quién más, además del dueño del recurso, necesita a veces llegar a él.

Laboratorio práctico: Explorar vulnerabilidades web reales

Tiempo estimado: 90 minutos (trabajo individual fuera de la sesión) Requisitos: Navegador web, cuenta gratuita en PortSwigger Web Security Academy Ética: Practicar únicamente en los laboratorios diseñados para entrenamiento. Aplicar estas técnicas en sistemas reales sin autorización explícita es un delito.

Objetivo

Experimentar de primera mano cómo funcionan los ataques más comunes contra aplicaciones web. No necesitas saber programación para completar estos laboratorios: PortSwigger te guía paso a paso en una aplicación vulnerable diseñada para aprender.

Preparación

  1. Crea una cuenta gratuita en portswigger.net/users/register
  2. Accede a la Web Security Academy
  3. Cada laboratorio tiene un botón “Access the lab” que abre una aplicación vulnerable lista para practicar

Parte 1: Inyección SQL

Laboratorio: SQL injection vulnerability in WHERE clause allowing retrieval of hidden data (nivel Apprentice)

Este laboratorio simula una tienda en línea con una vulnerabilidad de inyección SQL. Siguiendo las instrucciones del laboratorio, lograrás que la tienda muestre productos que normalmente están ocultos manipulando la URL de una categoría de productos.

Preguntas:

  1. ¿Qué escribiste en la URL para explotar la vulnerabilidad? En tus propias palabras, ¿qué le “dijiste” a la aplicación para que mostrara datos que no debía?
  2. La aplicación tomó tu texto como si fueran instrucciones internas. ¿Qué principio de desarrollo seguro habría prevenido esta vulnerabilidad?
  3. En una aplicación real de tienda (no un laboratorio), ¿qué otros datos podría obtener un atacante explotando esta vulnerabilidad?
  4. ¿En qué paso te trabaste y cuánto tardaste en total?

Parte 2: Cross-Site Scripting — XSS

Laboratorio: Reflected XSS into HTML context with nothing encoded (nivel Apprentice)

Este laboratorio tiene una barra de búsqueda que no valida lo que el usuario escribe. Podrás hacer que la página ejecute instrucciones que no debería ejecutar, simplemente escribiéndolas en el campo de búsqueda.

Preguntas:

  1. ¿Qué escribiste en la barra de búsqueda? ¿Qué ocurrió en la página?
  2. Imagina que esta vulnerabilidad está en la caja de comentarios de un sitio con miles de usuarios. ¿Cómo podría un atacante usar esto para robar información de otros usuarios que visiten ese comentario?
  3. ¿Por qué esta vulnerabilidad se llama “reflejado” (reflected)? ¿Qué se está reflejando y hacia dónde?
  4. ¿En qué paso te trabaste y cuánto tardaste en total?

Parte 3: Control de acceso roto — IDOR

Laboratorio: Insecure direct object references (nivel Apprentice)

Este laboratorio tiene un chat donde se pueden descargar transcripciones de conversaciones. La aplicación no verifica a quién le pertenece cada transcripción antes de permitir la descarga.

Preguntas:

  1. ¿Cómo lograste acceder a datos de otro usuario? ¿Qué modificaste y cómo lo descubriste?
  2. ¿Qué verificación debería haber hecho la aplicación antes de permitirte descargar ese archivo?
  3. Piensa en una aplicación bancaria, médica o de recursos humanos. ¿Qué información podría quedar expuesta a este mismo tipo de ataque?
  4. ¿En qué paso te trabaste y cuánto tardaste en total?

Entregable

Escribe un informe de experiencia que incluya:

  1. Para cada laboratorio (una sección por cada uno):

    • Una captura de pantalla del banner “Congratulations, you solved the lab” en la que se vean tu nombre de usuario de PortSwigger y la URL del laboratorio
    • ¿Qué hiciste para lograr el ataque? (en tus propias palabras, sin copiar del laboratorio)
    • ¿Qué impacto tendría en una aplicación real? ¿Qué datos o capacidades obtendría el atacante?
    • ¿Qué principio de desarrollo seguro se violó?

  2. Reflexión general:

    • ¿Cuál de las tres vulnerabilidades te parece más peligrosa en el contexto de una aplicación bancaria? ¿Por qué?
    • Después de experimentar estos ataques, ¿qué tan fácil te pareció explotar estas vulnerabilidades? ¿Qué implica eso para el diseño de aplicaciones?

Criterios de evaluación

CriterioPuntos
SQL Injection: laboratorio completado (con captura) y preguntas respondidas25
XSS: laboratorio completado (con captura) y preguntas respondidas25
Control de acceso: laboratorio completado (con captura) y preguntas respondidas25
Reflexión general con argumentos sólidos25

Conceptos clave

TérminoDefinición
VulnerabilidadFalla en un sistema que puede ser explotada para causar daño
Validación de entradasVerificar que los datos recibidos cumplen el formato esperado antes de procesarlos
SQL InjectionAtaque que manipula consultas a bases de datos mediante entradas maliciosas
XSSAtaque que inyecta scripts en páginas web vistas por otros usuarios
AutenticaciónProceso de verificar la identidad de un usuario
AutorizaciónProceso de verificar qué acciones puede realizar un usuario autenticado
DevSecOpsModelo de desarrollo que integra la seguridad en todas las etapas del ciclo
OWASPOrganización que documenta y publica las vulnerabilidades más críticas en aplicaciones web
Control de acceso roto (IDOR)Un usuario llega a recursos o acciones para los que no tiene permiso, por ejemplo cambiando un identificador en la URL
Cifrado en tránsito y cifrado en reposoDos controles distintos: proteger el dato mientras viaja entre navegador y servidor, y protegerlo mientras está guardado
Cabecera de seguridad HTTPInstrucción que el servidor envía al navegador para restringir comportamientos peligrosos; su ausencia facilita varios ataques
Configuración inseguraEl sistema funciona pero quedó mal configurado, por ejemplo con contraseñas de fábrica sin cambiar o con servicios internos accesibles desde fuera de la organización

Lectura disponible — Por qué fallan las aplicaciones y las categorías de OWASP

En la clase 03 viste una lista de familias de vectores de ataque. Una de ellas, la explotación de vulnerabilidades en el software, quedó anotada para una sesión propia, y esta es esa sesión. Ya modelaste además vulnerabilidades en abstracto con el método de la clase 04; ahora vas a ver las que aparecen una y otra vez en el software real.

Por qué fallan las aplicaciones

Una aplicación de software es un conjunto de instrucciones escritas por personas, y las personas cometemos errores. Cuando esos errores tienen consecuencias de seguridad los llamamos vulnerabilidades. Imagina que diseñas una caja fuerte de cartón: funcionará perfectamente mientras nadie intente abrirla a la fuerza, pero en el momento en que alguien la ataque deliberadamente, los errores de diseño quedan expuestos. El software tiene el mismo problema, porque fue diseñado para funcionar correctamente con usuarios normales y no para resistir a alguien que intente romperlo.

Conviene detenerse en el término, porque la clase entera gira sobre él. Una vulnerabilidad no es cualquier error de programación. Es un error cuyo efecto es de seguridad: algo que alguien con mala intención puede aprovechar para leer, cambiar o impedir el acceso a información o funciones que no le corresponden. Un programa puede tener decenas de errores que solo hacen que una pantalla se vea mal o que un cálculo dé un resultado raro, y ninguno es una vulnerabilidad. Basta con que uno de esos errores le abra a un atacante una puerta que no debería existir para que sí lo sea.

Las vulnerabilidades aparecen por razones que se repiten. A veces es un error de confianza, cuando quien programa asume que el usuario solo enviará datos válidos. A veces es un error de diseño, cuando la lógica del sistema no contempla que alguien pueda actuar de mala fe. A veces es un error de implementación, cuando lo que era correcto en teoría queda mal ejecutado en la práctica. Y a veces es un componente desactualizado, software con fallas ya conocidas y publicadas que nadie se ha ocupado de actualizar. Como ingeniero de seguridad tu trabajo no es escribir todo el código del sistema, sino anticipar dónde se pueden romper esos supuestos y diseñar controles que lo impidan.

Qué es un parámetro de una URL

Una dirección web no es una sola pieza. Después del nombre del sitio suele venir una ruta, separada por barras, que indica qué sección estás viendo (/facturas/, /perfil/), y a veces un signo de interrogación seguido de pares con la forma nombre=valor, que son los parámetros. En tienda.com/pedido?id=4471 el parámetro id vale 4471 y le dice al servidor qué pedido mostrar. Ese texto está a la vista y cualquiera puede cambiarlo en la barra de direcciones antes de pulsar Enter. Que sea fácil de cambiar no es el problema; el problema aparece cuando el servidor confía en ese número sin comprobar que quien lo pide tiene derecho a ese pedido.

OWASP y el Top 10

OWASP (Open Web Application Security Project) es una organización internacional sin ánimo de lucro que publica una lista de las categorías de vulnerabilidades más críticas en aplicaciones web, conocida como el OWASP Top 10. Es el punto de referencia de la industria para priorizar problemas de seguridad. Esta clase trabaja cinco de esas categorías; las otras cinco están nombradas más abajo, en esta misma lectura. Los nombres usados aquí son los de la lista de 2021, que es la vigente; cuando un nombre cambió respecto de listas anteriores, la primera vez aparece también el nombre anterior entre paréntesis. En esa lista de 2021 el control de acceso roto encabeza el ranking, por delante de la inyección.

Las cinco categorías, una a una

1. Inyección

La aplicación mezcla instrucciones del sistema con datos enviados por el usuario, y eso deja que un atacante inyecte sus propias instrucciones disfrazadas de datos normales. Imagina que llamas a una biblioteca y pides “el libro de García Márquez”: la bibliotecaria busca exactamente eso. Pero si dices “García Márquez, y de paso deme también acceso a todos los archivos restringidos”, una biblioteca mal diseñada podría seguir esa segunda parte al pie de la letra, porque no distingue entre una petición normal y una manipulada. El caso más común usa SQL, que es el lenguaje con el que las aplicaciones guardan y consultan información en una base de datos: un atacante que escribe instrucciones SQL donde se esperaba un término de búsqueda puede leer datos de otros usuarios, borrar registros o extraer la base de datos entera.

La regla “trata los datos del usuario como datos, nunca como instrucciones” suena obvia hasta que ves cómo se rompe. Una aplicación mal hecha arma su consulta pegando texto: toma la frase “busca los productos de la categoría” y le concatena lo que el usuario escribió. Mientras el usuario escriba algo como “zapatos” la consulta funciona, pero en cuanto escribe algo que el lenguaje de la base de datos interpreta como una orden nueva, la base de datos obedece, porque para ella todo llegó como una sola instrucción. La defensa real no es revisar lo que el usuario escribe buscando cosas raras, sino cambiar la forma de construir la consulta: el programa le pasa al motor de la base de datos la orden por un lado y los valores por otro, y el motor tiene prohibido leer un valor como parte de la orden. Lo mismo aplica cuando la aplicación arma comandos del sistema operativo o instrucciones de otros lenguajes, porque el patrón de fallo es siempre el mismo, mezclar en un solo texto lo que manda y lo que el usuario aportó.

2. Autenticación rota

Los mecanismos para verificar quién eres están mal implementados, y eso permite que un atacante se haga pasar por otro usuario. Ocurre cuando las contraseñas se guardan tal como las escribe el usuario, cuando la cuenta no se bloquea después de muchos intentos fallidos, o cuando las sesiones no expiran nunca. La prevención combina tres cosas. La primera es no guardar nunca la contraseña directa, sino transformada con una función de un solo sentido llamada hash, de la que no se puede volver de forma directa a la contraseña original; aun así, un atacante que se robó la base de datos puede ir probando contraseñas hasta dar con la que produce ese hash, y por eso la segunda cosa es limitar el número de intentos de inicio de sesión, y la tercera es pedir una credencial adicional, que es la autenticación de múltiples factores. Cómo funciona el hash por dentro es la clase 08.

Además de cómo se guardan las contraseñas, hay detalles del inicio de sesión que un atacante mira antes de intentar adivinar nada. Uno es la enumeración de usuarios: si el formulario responde “ese correo no está registrado” cuando el correo no existe, y “contraseña incorrecta” cuando sí existe, el atacante puede averiguar qué cuentas existen sin haber probado ninguna clave, y concentrar su esfuerzo solo en esas. Otro es la vida de la sesión: cuando inicias sesión, el servidor te entrega una credencial temporal que tu navegador guarda en una cookie y presenta en cada página siguiente, para no pedirte la contraseña todo el tiempo; si esa cookie no expira nunca y alguien la copia, puede usarla mientras quiera. Por eso una sesión bien hecha caduca sola tras un tiempo de inactividad y se invalida del lado del servidor cuando cierras sesión.

3. Fallas criptográficas (exposición de datos sensibles)

La aplicación no protege bien la información confidencial, ya sea mientras viaja por internet o mientras está almacenada. Enviar datos personales por internet sin cifrado es como mandar una postal, que cualquiera que la manipule durante el trayecto puede leer; con cifrado, que es lo que indica el candado del HTTPS en el navegador, es como mandar una carta sellada en un sobre que solo abre el destinatario. Un dato sensible es cualquiera cuya divulgación le haría daño real a una persona, como su diagnóstico médico, su salario o el número de su cédula, y la ley colombiana trata algunos con especial cuidado, cosa que verás en la clase 09.

Para protegerlos hay dos momentos distintos y cada uno necesita su propio control. Mientras el dato viaja de tu navegador al servidor lo protege el cifrado en tránsito, que es lo que activa el candado del HTTPS. Mientras el dato está guardado y quieto en la base de datos lo protege el cifrado en reposo, que es una decisión aparte y que muchos sistemas no toman: un atacante que se roba una copia de esa base de datos sin cifrado en reposo se lleva todo legible, por impecable que sea el HTTPS del sitio. Existe además una tercera defensa, más barata que las dos anteriores, que es no guardar el dato que no necesitas, porque lo que no está en la base de datos no se puede filtrar.

4. Control de acceso roto

Los usuarios pueden llegar a recursos o realizar acciones para las que no tienen permiso. Es lo que vivió Laura en el escenario de apertura: el enlace de su resultado terminaba en ?id=48213 y, al cambiar el número, aparecía el resultado de otra persona. Esa falla concreta se llama IDOR, por “referencia directa e insegura a un objeto”. La defensa es que el servidor compruebe, en cada petición, que quien la hace tiene permiso sobre ese recurso específico; el número que aparece en la URL no es un control de seguridad. En la clase 06 verás los tres modelos (DAC, MAC y RBAC) para diseñar bien quién puede hacer qué.

5. Configuración insegura

Un sistema mal configurado funciona igual de bien que uno bien configurado, y por eso el problema pasa meses sin que nadie lo note. Piensa en un panel de administración, esa pantalla desde la que el equipo técnico crea usuarios, cambia precios o consulta la base de datos. En condiciones normales solo se llega a él desde la red interna de la organización. Cuando por un descuido queda accesible desde internet, cualquiera que dé con la dirección lo encuentra, y si además conserva la contraseña que traía de fábrica, entra sin necesidad de atacar nada. En ese caso no hubo inyección ni robo de sesión, solo una puerta de servicio que quedó abierta y con la llave puesta. La relación con el mínimo privilegio es directa: ese panel estaba expuesto mucho más allá de lo que su función necesitaba, y configurar con seguridad consiste precisamente en apagar y cerrar todo lo que no tiene una razón activa para estar encendido y al alcance de cualquiera.

Los descuidos que causan esta categoría son casi siempre los mismos. El primero es conservar las contraseñas que el software trae de fábrica, en el router, en el panel de administración o en la base de datos. El segundo es mantener encendidas funciones que nadie usa, porque cada una es una entrada más que hay que vigilar. El tercero, y el más grave, es exponer a internet algo que solo debería alcanzarse desde dentro de la organización. A eso se suma mostrar hacia afuera mensajes de error con detalles técnicos internos, cuando lo correcto es enseñar un mensaje genérico y guardar el detalle en registros internos.

Las otras cinco categorías del OWASP Top 10

El nombre “Top 10” promete diez categorías y esta clase trabajó cinco. Las otras cinco existen y conviene que sepas que la lista es más larga. Tres se pueden describir ya.

El diseño inseguro son fallas que vienen de cómo se pensó el sistema y no de un error de programación puntual. Es la diferencia entre una casa con una cerradura mal instalada y una casa a la que, de plano, nadie le puso puerta en la entrada de servicio: no hay un tornillo que apretar, porque el problema es el plano. La defensa no es revisar código, sino incluir la pregunta de seguridad en la etapa de diseño, antes de que exista una sola línea.

Los componentes con fallas conocidas y sin actualizar son piezas de software de terceros (librerías, marcos de trabajo, servidores) que el sistema usa y que tienen vulnerabilidades ya publicadas. Es como levantar un edificio con un lote de vigas que el fabricante ya retiró del mercado por defectuosas: el error no lo cometió el arquitecto, pero el edificio y la viga son igual de suyos, y la única defensa es llevar la cuenta de qué piezas prestadas usa el sistema y cambiarlas cuando se anuncia que fallan.

El registro y monitoreo insuficientes consiste en no dejar rastro de lo que pasa en el sistema, de modo que un ataque en curso no se nota hasta que el daño ya está hecho. Es la tienda sin cámaras que se entera del robo cuando abre al día siguiente y ve los estantes vacíos.

Las dos categorías restantes tienen sentido cuando ya conoces la arquitectura de una aplicación web, así que las verás con ese contexto en la clase 07. La lista completa y su explicación oficial están en https://owasp.org/www-project-top-ten/.

Cada falla rompe una propiedad de CIAAN

Ya viste en la clase 02 qué propiedades debe proteger un sistema. Cada falla de esta lista es una de esas propiedades rompiéndose por una causa concreta del software. Esta tabla resuelve la ambigüedad de la pregunta “¿qué principio se viola aquí?”, que puede referirse a un principio de diseño o a una propiedad de CIAAN.

Categoría OWASPPropiedad de CIAAN que rompeEn una frase
InyecciónIntegridad y confidencialidadel atacante lee o altera datos que no le corresponden
Autenticación rotaAutenticaciónel sistema ya no puede afirmar quién es quien dice ser
Fallas criptográficas / exposición de datosConfidencialidadinformación privada queda legible para quien no debía
Control de acceso rotoConfidencialidad o integridadsegún si quien no está autorizado solo mira, o además modifica
Configuración inseguraCasi siempre confidencialidadse filtran datos, o detalles internos del sistema

Lectura disponible — Principios del desarrollo seguro y el ciclo de vida

Independientemente de los detalles técnicos de cada aplicación, el desarrollo seguro se guía por unos pocos principios fundamentales. Los vas a ver reaparecer en el resto del bloque: el mínimo privilegio vuelve como eje del control de acceso en la clase 06, y el cifrado, que aquí se nombra como una barrera más, se desarrolla en la clase 08.

Nunca confiar en datos externos

Todo dato que llega desde fuera de la aplicación (formularios web, parámetros en URLs, archivos cargados, datos de otras aplicaciones) debe ser verificado antes de procesarse. Asumir que el usuario siempre enviará datos correctos es el origen de muchas vulnerabilidades.

Mínimo privilegio

Cada parte del sistema solo debe tener acceso a lo que necesita para funcionar. Una sección que solo necesita leer datos no debe tener permiso para borrarlos. Si esa parte es comprometida, el daño queda limitado.

Defensa en profundidad

No hay que depender de una sola barrera de seguridad. Si un atacante supera una capa, las siguientes deben detenerlo. Un sistema bien diseñado tiene varias capas independientes:

[Usuario] → [Verificar formato] → [Verificar identidad] → [Verificar permiso] → [Datos cifrados]
               ↑                         ↑                       ↑                    ↑
         Primera barrera          Segunda barrera          Tercera barrera       Última barrera

Fallar de forma segura

Cuando algo sale mal técnicamente, el sistema debe asumir la posición más restrictiva. Si una verificación de permisos falla por un error inesperado, la respuesta correcta es “denegar acceso”, no “asumir que está permitido”.

Seguridad desde el diseño

Es mucho más fácil y económico contemplar la seguridad desde el inicio que agregarla después de que el sistema ya está construido. Una vulnerabilidad descubierta en la fase de diseño puede corregirse en horas. La misma vulnerabilidad descubierta en producción puede costar semanas de trabajo y mucho dinero en daños.

La seguridad en el ciclo de desarrollo

Durante años la seguridad fue el último paso: se construía el sistema entero y, justo antes de lanzarlo, alguien lo revisaba. El problema de revisar al final es que cualquier hallazgo llega cuando ya es caro arreglarlo. Imagina que en el diseño alguien decidió guardar las contraseñas sin cifrar, para que el equipo de soporte pudiera leérselas al usuario por teléfono. Esa misma decisión se corrige en una reunión de diez minutos si alguien la cuestiona durante el diseño, pero obliga a reprogramar la base de datos, a forzar el cambio de contraseña de millones de cuentas y a dar explicaciones a un regulador si se descubre un año después con el sistema ya en producción.

Por eso el modelo moderno, que la industria llama DevSecOps y también “desplazar la seguridad a la izquierda”, mete la pregunta de seguridad en cada etapa del proceso:

DevSecOps:    [Diseño] → [Desarrollo] → [Pruebas] → [Lanzamiento]
                  ↑           ↑              ↑             ↑
              Seguridad   Seguridad      Seguridad     Seguridad

En la práctica esto significa que al diseñar el sistema ya se piensa en amenazas, durante el desarrollo se revisa el código buscando errores de seguridad, durante las pruebas se intenta atacar el sistema de forma controlada, y al lanzarlo se configuran alertas y monitoreo. La idea de fondo es la misma que la de “seguridad desde el diseño”, llevada a todo el ciclo: cuanto antes se encuentra un problema, más barato es cerrarlo.

Navegación: ← Anterior | Inicio | Siguiente: Control de acceso →

Vista Gráfica

Retroenlaces