Hola amigos, bienvenidos a esta clase, donde vamos a hablar de otra de las vulnerabilidades dentro
del top ten o whoops, que es la pérdida de control de acceso, que se los muestro como siempre a el
archivo que hemos visto en un principio.
Pero les voy a hablar yo de justamente de qué se trata esta vulnerabilidad.
Bien, lo primero que tenemos que entender cuando hablamos de pérdida de control, de acceso, es que
básicamente falla la falla de controles de acceso a recursos de la aplicación que no valida permisos
de los usuarios, o sea, el dueño, por así decirlo, quien tienen privilegios de administrador vendría
a ser como la manipulación a la utilización de las variables de sesión, por así decirlo, de de la
aplicación en cuestión o una mala configuración en este caso.
Pero antes de aventamos vamos a hablar en detalle de esto.
Justamente entonces, qué es lo que acabo de mencionar?
La falla de control de acceso a recursos de la aplicación que no valida los permisos del usuario que
está logueado.
Eso es el que es cuando hablamos de control de acceso.
Ahora, qué tipos existen?
Existen dos la falla lógico de la aplicación y la falla de acceso.
Cuando hablamos de falla lógica estamos hablando de la horizontal y vertical.
Cuando hablamos de horizontal es la falla que permite saltear validaciones de otros usuarios del mismo
nivel de permisos y la vertical es la que justamente falla, que permite saltear las validaciones de
otro usuario con mayor privilegio, permitiendo ejecutar acciones de mayor impacto.
Me voy a explicar a qué me refiero con esto.
Un ejemplo en el horizontal podríamos decir que tenemos permisos de usuario raso normal y dentro de
esa horizontalidad, o sea, adentro a mi par, se encuentra alguien que a nivel de permisos está a
mi misma altura, pero tiene permisos distintos, como por ejemplos digamos un tesorero por decirle
con funciones de tesorería dentro de la empresa.
Entonces la falla horizontal en este caso es que no vamos a seguir desarrollando a lo largo de esta
clase.
Me permitiría pasar de usuario raso a poder ex a utilizar privilegios de alguien que está en tesorería
y vertical?
Obviamente fácil.
Yo soy usuario raso y puedo elevarme privilegios a administrador, por ejemplo.
De todas maneras, esto inclusive vamos a tener práctica de esta teoría, así que no se desespere.
Y cuando hablamos de fallo de acceso, estamos hablando de unas siglas que es LF, I o RF y que es el
hecho de permitir acceder o incluir archivos en el contexto de la aplicación con archivos locales de
servidor o remoto.
También cuando hablamos de acceso estamos hablando de acceso a directorios privados, donde se permite
acceder a directorios que sólo deberían ser accedido rodeándose con un determinado usuario y si no,
el famoso putts trasversal que permite manipular las variables de la aplicación para acceder a archivos
del servidor, disponerlos de la aplicación bastante grave.
Ahora bien, cuando estamos hablando de las vulnerabilidades comunes de control de acceso, estamos
hablando de, por ejemplo, pasar de dar todas las comprobaciones de control de acceso, modificando
la córrele el estado interno de la aplicación o HTML, cosa que ya hemos visto también y vamos viendo
a lo largo de este curso utilizando una herramienta de ataque o una conexión vía API.
Recuerden que Maham próximamente no muy lejos de estas clases, vamos a estar viendo también justamente
el Top Team o Waves de APIs.
Fermí Bueno, también permitir.
Cuando hablamos de vulnerabilidades, estamos hablando de permitir que la clave primaria se cambie a
la de otro usuario, por ejemplo, pudiendo ver o editar las cuentas de red persona elevación de privilegios,
que eso ya lo vimos cuando hablamos de verticalidad, que significa actuar como un usuario sin iniciar
sesión o actuar como un administrador habiendo iniciado sesión con un usuario estándar, así como vencer.
Le expliqué la manipulación de metadatos como reproducir un token de control de acceso, como hacerlo
famoso J o l bt o 6 software token que eso significa j doble de T manipular una cookie o un campo oculto
para elevar privilegios, abusar de invalidación de token j doble de t o forzar la navegación o a páginas
autenticada como un usuario no autenticado o falso juego, palabra o página.
Privilegiadas con un salario estándar o acceder a una API sin control de acceso mediante el uso de los
Poot o Utility en proyectos o inclusive ya lo hemos visto.
Y cómo se soluciona esto?
Qué prevenciones podemos tomar?
Bueno, podemos implementar mecanismos de control de acceso una vez reutilizado toda la aplicación,
las famosas validaciones y el control de acceso solo es efectivo si la aplicación del lado del servidor
o servidores API donde el atacante no puede modificar porque justamente grandes.
Estos problemas son por parte del fragment, o sea del interfaz.
No puedo verificar la verificación de acceso al control o los metadatos.
Claramente las validaciones siempre las debemos hacer de Wacken.
Los controles de acceso al modelo deben imponer la propiedad, o sea, el dueño de los registros a privilegios
son se rueda administrador.
En lugar de aceptar que un usuario pueda crear, le interesar eliminar cualquier registro bueno, deshabilitar
el listado de los directorios en el servicio web y asegurarse que los metadatos fuentes del archivo,
por ejemplo, los sea utilizando términos más modernos hoy en día y copia de seguridad no estén presentes
en las carpetas públicas.
Bueno, registrar errores hallábanse log de control de acceso, ya que alerta a los administradores
cuando corresponde.
Si Kefa ante reiteradas intentos y reiterados fallos, el limite de la tasa de acceso a la API para
minimizar el daño de herramientas de ataques automatizada.
Bueno, los token jÃbilo de T deben ser invalidos luego de que la finalización de la sesión por parte
del usuario.
Bueno, menos espero que les haya gustado esta clase.
Les dejo un abrazo digital.