---
# System prepended metadata

title: Access Control

---



# Access Control


- **¿Que es el Access Control?**


El Access Control es la aplicacion que hace restricciones sobre quien realizar acciones o tener acceso a los recursos que han solicitado. En el contexto de las aplicaciones web, el Access Control, es dependiente de la autenticacion y la gestion de la sesion. 

__________________

* **Autenticacion**: Identifica al usuario y confirma que el usuario es el que dice ser
* **Gestion De La Sesion**: Identifica cuales peticiones HTTP subsecuentes son hechas por ese mismo user
* **Control De Acceso**: Determina donde el usuario es permitido a hacer la accion que esta intentando hacer 

__________________

**El Broken Access Control** es una vulnerabilidad muy comun y normalmente considerada critica. El diseño y gestion de los Access Controls, es algo muy complejo.

![](https://i.imgur.com/1dGhpXd.png)

------------------


##  Diferentes tipos de Access Controls:


#### 1 - **Vertical Access Control**:

El Vertical Access Control, es un mecanismo el cual restringe el acceso a funcionalidades sensibles, no aptas para todo tipos de usuarios. Con estos Vertical Access Control, los diferentes tipos de usuarios tienen acceso a las diferentes funciones de la aplicacion. Por ejemplo, un administrador puede ser capaz de modificar o borrar cualquier cuenta de usuario.


#### 2 - **Horizontal Access Control**:


El Horizontal Access Control es un mecanismo que restringe la accesibilidad a funcionalidades o informacion de otros usuarios/roles. Por ejemplo, una aplicacion de banca permitiria a un usuario a ver sus propias transacciones, pero no la de otros usuarios.


#### 3 - **Context-Dependent Access Control**:


El Context-Dependent Access Control, controla el acceso restringido a una funcionalidad y a los recursos, basandose en el estado de la aplicacion, y de la interaccion del usuario con la pagina.

El Context-Dependent Access Control previene que un usuario haga acciones en un mal orden. Por ejemplo, en una pagina de compra, como Amazon, puede prevenir que los usuarios modifiquen el contenido de su carrito despues de que hayan hecho su pago. 



### - Que es una IDOR y Ejemplos?


Una IDOR es un tipo de vulnerabilidad en el Access Control, que aparece cuando en una aplicacion, el usuario puede acceder a sus objetos directamente. 




* Vulnerabilidad IDOR con Direct Reference a objetos de una DB

```
 https://insecure-website.com/customer_account?customer_number=132355 
```
 
 Si modificamos el parametro:
 
 ```
 customer_number
 ```
 
El atacante podria ser capaz de hacer un privesc horizontal, alterando el customer_number, ya que se podria poner como admin.


* Vulnerabilidad IDOR con Direct Reference a un archivo estatico.


En este caso tendriamos la siguiente URL, con su respectiva URI:

```
https://insecure-website.com/static/12144.txt
```

Si fuzzeamos por el /static/ buscando .txt podriamos sacar otros .txt con credenciales de otros usuarios.



### Diferencias entre BAC y IDOR


Bien, como ya hemos visto antes, una IDOR es un tipo de vulnerabilidad en donde el usuario puede acceder a sus objetos directamente solo cambiando un valor en el parametro de la URL, mientras que en el BAC el usuario puede entrar en algun recurso, o hacer alguna accion la cual no deberia de ser capaz de hacerla.


# Ejemplo Práctico

Acontinuación mostraremos como un simple cambio en un parametro de la URL (clave-valor) puede dar acceso no autorizado a un usuario a cierto recurso en el sistema.

Iniciamos sesión en el subdominio de http://bankofindian.com

```
http://bandikala.bankofindian.com/account?user=12
```

Ahora supongamos que queremos escalar privilegios de manera horizontal e ingresariamos un nuevo id a la web vulnerable.


```
http://bandikala.bankofindian.com/account?user=15
```

Hariamos un GET para traer datos genericos de la cuenta de otro usuario.

```
 GET http://bandikala.bandofindian.com/account?user=15
 Host: 10.20.1.58:8000
 User-Agents: Mozilla/5.0 
 Gecko/2012
 ......
 ```
 
Nuestra respuesta seria:
```
HTTP/1.1 200 OK
Connection: close
Accept-Ranges:Bytes
X-XSS-Protection: 1 ; mode=block
X-Content-Type-Options:nosniff
Xframe-Option:Deny
.....
```

Con esto comprobamos que no solo tenemos acceso a dicha cuenta consultado, si no a todos los usuarios de la pagina que esten en el mismo nivel por culpa de un parametro sin depurar. (esto no pasa en los bancos).

### APIRest y su papel en los IDOR


Los metodos que nos provee este arquitectura pueden ser una arma de doble fila si se diseñan mal junto a la URL. tenemos los mas usados para un CRUD sencillo en una pagina web, GET ,PUT,POST,DELATE.

* GET : se usa para obtener información de algun recurso.
* PUT : actualiza un recurso.
* POST : crea un recurso.
* DELETE: Elimina un recurso.

#### Y a que llamamos recursos?

Bien, desde el control de usuario podria ser tan sencillo como obtener la lista de un carrito de compras en un Ecommerce (GET), cambiar su password (PUT), crear un articulo o agregar información a tu perfil, y DELATE eliminar alguna caracteristicas, manipular objetos o sus caracteristicas.

vamos a ver un caso de una url mal diseñada que junto a un metodo no sanitizado el cual puede crear un idor.

- Ejemplo:
 
www.myEcommerce.com/user/get?ide=01

Se le esta dando a entender el posible nombre real del metodo al que accedera el usuario

si en un tal caso
```go
func Get_User(w http.ResponseWriter, r *http.Reques){
       url :=  r.URL.Query()
       db_id(url[id][0])
    ......
} 
```
En tal caso que no llegaramos a tratar ese parametro id y lo pasaramos como argumento crudo a la db, podriamos comprometer los usuarios dandole acceso a la mayoria de cuentas que maneja ese metodo.como sucede con GET, PUT,POST, y DELETE. pueden causar un daño severo a la integridad de los datos.

### Recomendaciones para Evitar IDOR:

Para evitar el IDOR requerimos que los desarrolladores definan manualmente medidas de control de acceso de cada endpoint, aunque esto de cierto modo es dificil si tratamos con programas grandes, es importante tener en cuenta las siguientes recomendaciones

* Pruebas de integración que cubran los casos de uso de IDOR.
* Usar JWT para validar el usuario actual y evitar que este puede obtener datos de otros usarios.
* Utilizar GUID como un mecanismo que dificulte la identificaión de los ID.