En otras ocasiones hemos hablado de referencias inseguras a objetos directos (insecure direct object references).
Ahora conocemos otra que pudo dar la opción de borrar cualquier imagen de Facebook al cazador de bugs Pouya Darabi. Afortunadamente, Darabi informó del problema a Facebook quien rápidamente lo solucionó y le pagó 10.000$ de recompensa.
Las referencias inseguras a objetos directos en webs son cuando encuentras un camino que te permite acceder a un ítem que no te pertenece, como un vídeo, artículo o imagen y entonces deliberadamente modificar los datos de tu petición de manera que puedas realizar acciones con el ítem sin la autorización pertinente.
Por ejemplo, imagina que hay una imagen a la que no puedes acceder, en un servidor que quieres hackear, que está publicada vía URL de la siguiente manera:
https://example.net/photos/7746594545.jpg
--- HTTP request generated: ---
GET /photos/7746594545.jpg HTTP/1.1
Host: example.net
Ahora imagina que después de autentificarte, puedes editar tus propias imágenes a través de una URL especial combinada con un cookie de sesión como esto:
https://example.net/api/edit/?image=4857394574.jpg
--- HTTP request generated: ---
GET /api/edit/?image=4857394574.jpg
Host: example.net
Cookie: authtoken=HRCALAGJEOWRGTMW
En este ejemplo, la authtoken es una cookie de sesión que le dice al servidor que eres tú y que ya te has autentificado.
Imagina que el servidor solo valida la authtoken y no comprueba que la imagen 4857394574con tu cuenta para asegurarse que puedes editarla.
Por lo tanto, puedes repetir esta petición con la primera imagen que no te pertenecía de la siguiente manera:
https://example.net/api/edit/?image=7746594545.jpg
--- HTTP request generated: ---
GET /api/edit/?image=7746594545.jpg
Host: example.net
Cookie: authtoken=HRCALAGJEOWRGTMW
En otras palabras, en este hipotético ejemplo puedes editar todas las imágenes aunque solo tengas derecho a editar algunas de ellas.
Es como si llegas a un hotel y compruebas que tu llave te permite abrir todas las habitaciones del hotel por un problema al codificarla, aunque en teoría solo deberías tener acceso a tu habitación.
Normalmente este tipo de fallos ocurren cuando se testea software para asegurarse que hace lo que se supone que tiene hacer, pero no se testea lo que ocurre cuando se le pide cosas que no debe hacer.
El fallo en Facebook
Darabi detectó que cuando creaba una encuesta en Facebook con una imagen adjunta, podía modificar la petición HTTP para utilizar imágenes de otros:
Este tipo de substituciones no presenta ningún problema ya que la imagen en teoría es de libre acceso. Pero el problema surge al eliminar la encuesta, lo que es lícito porque la ha creado él, Facebook también eliminaba las imágenes adjuntas asumiendo que eran del mismo propietario. Es decir una referencia insegura a un objeto directo.
¿Qué hacer?
Si eres un usuario de Facebook no tienes que hacer nada. Gracias al informe de Durabi, ya se ha parcheado esta vulnerabilidad, así que no puedes eliminar imágenes que no te pertenecen de esta manera.
Si eres un programador recuerda testear todo, especialmente las cosas que no deben ocurrir, asumiendo que no solo pueden ocurrir ya que seguramente ocurrirán.
Para manteneros al día de las últimas amenazas haceros fans de nuestra página de Facebook o síguenos en Twitter para intercambiar experiencias en torno al mundo de la seguridad. Si deseas recibir nuestro boletín de seguridad en tu correo electrónico, suscríbete en la siguiente aplicación:
Dejar un comentario