La prueba de seguridad OTG-AUTHZ-003 tiene como objetivo determinar hasta qué punto es posible que un usuario pueda modificar sus privilegios o roles dentro de la aplicación web. Este comportamiento se denomina Ataque de Escalada de Privilegios (privilege escalation attack) y puede ser de tipo horizontal cuando es posible acceder a recursos de usuarios con privilegios similares y vertical cuando el usuario adquiere más privilegios que los asignados a este (como los de un administrador).
Para la conducción de la prueba de seguridad debe analizarse si la aplicación web posee algún mecanismo de autorización que tenga como base la información proveniente del cliente. Por ejemplo, puede ocurrir que exista una cookie o parámetro que establezca el nivel de acceso del usuario y por tanto puede ser propensa a su manipulada del lado del cliente. Por las características de la información y comportamiento que se está analizando, es muy difícil que pueda automatizarse de forma genérica esta prueba de seguridad. Por ello su resultado dependerá de la experiencia del especialista y el tiempo disponible para su realización. A continuación, se describirán tres ejemplos para representar como puede ser llevada a cabo.
Un primer ejemplo de lo expuesto puede ser el que aparece en la página 83 de la OTG. En este caso se plantea un proceso de creación de un usuario en una aplicación web:
POST /admin/addUser.jsp HTTP/1.1 Host: www.example.com [other HTTP headers] userID=fakeuser&role=3&group=grp001
Podemos apreciar que cuando se envía los datos del usuario en el cuerpo de la petición HTTP aparece el campo role y el campo group. La prueba de seguridad en este caso se centraría en modificar estos valores para tratar de registrar un usuario con un rol diferente y acceso a datos de otros grupos que los normales.
Otro ejemplo que propone la OTG ocurre luego que un usuario se ha autenticado en la aplicación web y el servidor le envía la siguiente respuesta HTTP:
HTTP/1.1 200 OK Server: Netscape-Enterprise/6.0 Date: Wed, 1 Apr 2006 13:51:20 GMT Set-Cookie: USER=aW78ryrGrTWs4MnOd32Fs51yDqp; path=/; domain=www.example.com Set-Cookie: SESSION=k+KmKeHXTgDi1J5fT7Zz; path=/; domain= www.example.com Cache-Control: no-cache Pragma: No-cache Content-length: 247 Content-Type: text/html Expires: Thu, 01 Jan 1970 00:00:00 GMT Connection: close <form name=”autoriz” method=”POST” action = “visual.jsp”> <input type=”hidden” name=”profile” value=”SysAdmin”> <body onload=”document.forms.autoriz.submit()”>
En este caso podemos ver como en el cuerpo de la respuesta HTTP aparece un campo oculto de formulario con valor SysAdmin. ¿Qué pudiera ocurrir si es modificado este valor en una petición HTTP posterior?
Dentro de las aplicaciones web que vienen en la máquina virtual del proyecto BWA de OWASP se encuentra OWASP Security Shepherd (Figura 1).
Figura 1. OWASP Security Shepherd. Elaboración propia.
Esta brinda un conjunto de escenarios de pruebas de seguridad dentro de la cual se encuentra el acceso a un código reservado solamente a los usuarios que tengan el rol de administrador (Figura 2).
Figura 2. Reto de Seguridad asociado al rompimiento de la Autenticación y Manejo de Sesiones. Elaboración propia.
Supongamos que queremos comprobar hasta qué punto es seguro el mecanismo de autorización de esta funcionalidad. Para ello realizaremos clic en el botón Administrators Only Button para analizar como se conforma la petición HTTP y determinar si hay alguna información sobre roles o privilegios que podamos aprovechar. En la Figura 3 podemos comprobar de una primera mirada que los campos que viajan en el cuerpo de la petición son muy promisorios. Tenemos nombres como adminDetected y upgradeUserToAdmin que resultan más que sugerentes, sin embargo, son una trampa de detección de intrusos debido a que su envió modificado levanta una alerta en la aplicación web.
Figura 3. Estructura y contenido de la petición HTTP generada por Administrators Only Button. Se muestra la decodificación Base64 de la cookie checksum. Visualizado con OWASP ZAP. Elaboración propia.
Para un especialista familiarizado con las cookies y rutas de la aplicación web OWASP Security Shepherd, no encontrará ninguna información inusual, más allá de la que ya explicamos. No obstante, podemos apreciar una cookie nueva que se denomina checksum con valor dXNlclJvbGU9dXNlcg==, que a todas luces es una cadena codificada con Base64. En la Figura 3 (anterior) puede apreciarse como la decodificación de esta cadena arroja el resultado userRole=user. La pregunta que debemos hacernos es: ¿Qué sucedería si user es sustituido por admin o administrator?
Codificamos por tanto la cadena userRole=administrator en Base64, tomamos el valor resultante, lo asignamos a la cookie correspondiente y reenviamos la petición HTTP con el valor manipulado (Figura 4):
Figura 4. Codificando la cadena userRole=administrator en Base64. Elaboración propia.
La aplicación web responde entonces como si el usuario fuera administrador, mostrando la información restringida (Figura 5):
Figura 5. Rompimiento de la autorización en OWASP Security Shepherd. Elaboración propia.
Los ejemplos mostrados ilustran la necesidad de que la gestión de la autorización se fortalezca en el servidor de aplicaciones. Por muchos mecanismos de verificación que se implementen, si la aplicación web depende de que el usuario envíe datos que describan su rol o privilegios en la aplicación, siempre será vulnerable a que pueda ser manipulada esta información para beneficio de los ciberdelincuentes.
La segmentación de procesos puede ser un aliado importante para evitar estas vulnerabilidades. Por ejemplo, todos los usuarios creados en la aplicación web tienen un rol básico al inicio y por tanto no es necesario enviar este dato en la petición de inserción. Posteriormente un administrador, desde otro formulario puede modificarle el rol o los privilegios correspondientes.
Espero que te haya gustado el post, yo por mi parte me he entretenido bastante escribiéndolo.
S4lud0s y h4st4 el próx1m0 p0st!!!
Behique Digital 
es impresionante esta prueba
Me gustaLe gusta a 1 persona
Gracias Alejandro por tu comentario.
Me gustaLe gusta a 1 persona
Muy Interesante el articulo
Me gustaLe gusta a 1 persona
Gracias Patricia por tu comentario.
Me gustaLe gusta a 1 persona
Esta muy bueno
Me gustaLe gusta a 1 persona
Gracias Alberto por tu comentario.
Me gustaLe gusta a 1 persona
estoy de acuerdo con lo de interesante.
Me gustaLe gusta a 1 persona
Esta muy interesante
Me gustaLe gusta a 1 persona
Es un articulo que deja enseñanza para los estudiantes, muy bueno
Me gustaLe gusta a 1 persona
Un articulo muy instructivo y motivador
Me gustaLe gusta a 1 persona
Muchas gracias Victor por tu comentario.
Me gustaLe gusta a 1 persona
Muchas gracias Claudia por tu comentario.
Me gustaLe gusta a 1 persona
muy buen artículo y la recomendación que comenta en el último parrafo es mas bien una buena práctica de programación que se debe exigir siempre. La segmentación de procesos es muy importante, es algo que siempre le exijo a mis programadores en los proyectos. Actualmente es difícil prescindir completamente de las cookies pero es bueno intentar usarlas lo menos posible.
saludos.
Buen trabajo.
Me gustaLe gusta a 1 persona
Muchas gracias por tu aporte agattorno, es importante conocer la opinión de expertos como usted, nos alienta a continuar trabajando en nuevos artículos. Un placer nuevamente.
Me gustaLe gusta a 1 persona
Pingback: ¿Que es un ataque de tipo “Parameter Tampering” y como puede evitarse? | Behique Digital
Pingback: ¿Qué es lo nuevo en el OWASP Top 10 2017 R1? | Behique Digital
Pingback: Guía de Pruebas de OWASP 4.0 | Behique Digital