Broken Access Control: Cómo probar los permisos en una aplicación

Modelo de permisos

En la prueba de Broken Access Control, la identidad y la autorización son dos preguntas diferentes: quién es el cliente y qué se le permite hacer con el recurso. Se examinan los Roles, Claims, Session, Object ownership y los cambios a lo largo del ciclo de vida, sin limitarse a que el usuario esté 'conectado'.

Una matriz de prueba incluye un usuario anónimo, un usuario normal, un propietario de objeto, otro usuario y un administrador. Para cada acción se compara la Response y el impacto en el lado del servidor. La modificación de un identificador o un Header es solo un medio de prueba; la evidencia es que el servidor aprobó o rechazó una acción en contra de la política.

Horizontal vs. Vertical

Para entender la diferencia en el contexto de la prueba de Broken Access Control, es importante comparar objetivos y no solo herramientas. Una opción proporciona amplitud o velocidad, y otra proporciona una validación o contexto profundo. La elección correcta depende de la pregunta: ¿se requiere descubrimiento, investigación, prueba de impacto, contención o informe?

Una tabla de comparación profesional debe incluir al menos: tipo de entrada, nivel de certeza, costo operativo, impacto potencial, limitaciones y seguimiento requerido. En caso de duda, se utiliza el enfoque menos intrusivo y se agrega una fuente complementaria en lugar de sacar una conclusión demasiado amplia.

Prueba de Endpoints y Acciones

El tema 'Prueba de Endpoints y Acciones' es una parte central del trabajo sobre la prueba de Broken Access Control. Se recomienda desglosarlo en tres preguntas: ¿cuál es la entrada, qué decisión se quiere tomar y qué evidencia es suficiente para justificarla? Estas preguntas evitan el uso automático de una herramienta sin comprender el objetivo.

En la práctica, registre la matriz de roles, los identificadores de objetos, la autorización del lado del servidor, el acceso horizontal/vertical, las diferencias de respuesta, compare con el comportamiento esperado y defina al menos un Pivot. El resultado debe ser verificable por otro analista, incluyendo limitaciones y pasos a seguir.

Evidencia y Riesgo

El tema 'Evidencia y Riesgo' es una parte central del trabajo sobre la prueba de Broken Access Control. Se recomienda desglosarlo en tres preguntas: ¿cuál es la entrada, qué decisión se quiere tomar y qué evidencia es suficiente para justificarla? Estas preguntas evitan el uso automático de una herramienta sin comprender el objetivo.

En la práctica, registre la matriz de roles, los identificadores de objetos, la autorización del lado del servidor, el acceso horizontal/vertical, las diferencias de respuesta, compare con el comportamiento esperado y defina al menos un Pivot. El resultado debe ser verificable por otro analista, incluyendo limitaciones y pasos a seguir.

Remediación y Retest

Una prueba profesional de Broken Access Control comienza con condiciones de éxito y de fracaso. Se definen un caso positivo, un caso negativo, un caso límite y una actividad legítima similar. Así se pueden identificar tanto falsos negativos como falsos positivos.

En un entorno autorizado, se utiliza la acción mínima que prueba la afirmación sin causar daño. Se guardan el Input, Output, tiempo y versión, y después de la corrección se realiza un Retest en el mismo escenario y se comprueba también la regresión en funciones adyacentes.

Puntos de prueba únicos

En este tema, se recomienda construir de antemano un mapa de evidencias enfocado. Los puntos de prueba centrales son: role matrix, object identifiers, server-side authorization, horizontal/vertical access, response differences, audit logs. La lista no es un Checklist automático; cada elemento se elige porque puede vincular una entidad, acción y tiempo o explicar un comportamiento legítimo.

• role matrix: Defina cuál es el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.
• object identifiers: Defina cuál es el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.
• server-side authorization: Defina cuál es el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.
• horizontal/vertical access: Defina cuál es el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.
• response differences: Defina cuál es el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.
• audit logs: Defina cuál es el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.

Cuando uno de los puntos no está disponible, se debe documentar la brecha y elegir una alternativa. Por ejemplo, si el Process identifier no es estable, se puede usar el tiempo, Host, User y Parent; si el Payload está cifrado, se usan Metadata, volumen, frecuencia y TLS/DNS context.

Proceso de trabajo recomendado

1. Defina el Scope y una pregunta de trabajo sobre la prueba de Broken Access Control.
2. Registre las fuentes de datos y las evidencias necesarias: role matrix, object identifiers, server-side authorization, horizontal/vertical access.
3. Cree una línea base corta de comportamiento correcto o resultado esperado.
4. Realice la prueba mínima en un entorno de laboratorio y guarde el tiempo, la entrada y la salida.
5. Construya una línea de tiempo o una tabla de comparación y separe los hechos de la interpretación.
6. Realice un Pivot a una fuente adicional para verificar o refutar la explicación inicial.
7. Resuma la decisión, las limitaciones, la acción recomendada y el criterio de Retest.

Escenario práctico

El escenario elegido es una matriz de permisos para una aplicación de laboratorio. El propósito del ejercicio no es demostrar la capacidad de ataque, sino practicar la recopilación, comparación y documentación de forma segura. Antes de comenzar el trabajo, se definen datos simulados, una ventana de tiempo y un resultado esperado.

Al final del ejercicio, se debe entregar un producto que otro analista o probador pueda revisar: una captura de pantalla o una Exportación de la evidencia, una línea de tiempo corta, una suposición inicial, una evidencia de verificación, una limitación y una recomendación. Cuando no hay evidencia suficiente, la conclusión correcta es que el escenario no ha sido probado.

Checklist práctico

• ✓Revise y documente: Role y session.
• ✓Revise y documente: Endpoint y method.
• ✓Revise y documente: Request/Response.
• ✓Revise y documente: Object identifier.
• ✓Revise y documente: Server-side effect.
• ✓Revise y documente: Control expected y remediation.
• ✓Indique la Time zone, la versión de la herramienta y la hora de recopilación.
• ✓Guarde los datos brutos antes de filtrar o modificar.
• ✓Escriba lo que el hallazgo prueba y lo que aún se desconoce.
• ✓Defina el propietario y la acción de seguimiento con una fecha límite.

Errores comunes

• Probar solo el Status code.
• Depender del cambio del Client-side.
• Usar un Payload peligroso.
• No probar diferentes Roles.
• Ignorar la lógica de negocio.
• Informar sin Request/Response limpios.

Resumen y CTA

Broken Access Control: Cómo probar los permisos en una aplicación es un tema que conecta el conocimiento técnico con la disciplina laboral. Comience con una pregunta, recopile solo evidencias relevantes, mantenga el contexto y el tiempo, y elija una acción que se pueda justificar y volver a probar.

En el curso Cybersecurity & AI de HPI se practican estos principios utilizando sistemas, registros y laboratorios. Un paso natural es pasar a los artículos relacionados, realizar el ejercicio de laboratorio y guardar el producto como parte de un portafolio profesional.

Preguntas frecuentes