Sobre esta vulnerabilidad hay poco que decir, es bastante fácil de intentar explotar, y los conocimientos que hacen falta para ello, son casi nulos. ¿Quién no ha probado alguna vez poner en el navegador una URL de una página a la que no tiene acceso por permisos a ver si podía acceder directamente? Por ejemplo, imaginémonos que estamos navegando por el sitio www.example.es/user_private.php, pero sabemos que para el administrador es www.example.es/admin_private.php, seguro que alguno ha probado poner la dirección del administrador a ver si se puede acceder.

Pues más o menos, la vulnerabilidad que nos abarca hoy consiste en eso, en acceder a URL’s que en teoría nos deberían estar vetadas.

Realmente este fallo, más que de programación, aunque en ocasiones también lo es,  es un fallo de administración de la autorización y la autenticación. Me explico, todos sabemos que para una página o portal web existen dos ámbitos principalmente, el público y el privado, pero en muchas ocasiones, dentro del ámbito privado, existen diferentes niveles de acceso según el usuario que esta navegando en ese momento. Existen zonas a las que solo tendría que tener acceso un administrador del portal, zonas a las que solo tendría que tener acceso determinado grupo de trabajadores pero no otro, etc… Lamentablemente, en muchas ocasiones, estos controles de acceso están mal gestionados, y aunque un usuario básico no tenga ningún enlace a una zona restringida o lo tenga deshabilitado, si escribe directamente la dirección en la barra del navegador podrá acceder sin problemas.

El peligro de este tipo de ataque es que datos que deberían solo mostrarse a determinados usuarios quedan expuestos a personas que no deberían tener acceso a ellos, de aquí que la importancia del efecto del ataque vaya de desde baja, en caso de no tener ningún dato confidencial o de suma importancia, hasta muy alta, en caso de tener datos de carácter personal, privado o de suma importancia para un negocio.

Como ya se ha comentado antes, este fallo deriva de una incorrecta gestión de la autorización y la autenticación. Esto es, el acceso a todas las páginas, debería estar restringido por defecto y habilitarlo solo para aquellos usuarios que de verdad lo requieran. Esta tarea se hace mucho más fácil si, por ejemplo, creamos roles con los distintos usuarios: gestores, administradores, usuarios, contabilidad, …

También he comentado, que este no era de programación, y aunque es cierto, es también cierto que algunas veces si lo es. Para que todo el proceso de gestión de usuarios y roles funcione, todas las páginas de un portal o aplicación web deben llevar el control adecuado para realizar esta gestión, y en ocasiones, debido al gran número de páginas manejadas, a las prisas, o a un simple despiste, estos controles no se insertan en la página, haciendo que, a pesar de una buena gestión, nuestro sitio sea vulnerable.

Así que de todo los dicho, yo me quedaría con tres cosas básicas a modo de resumen:

La primera, es que es necesaria una buena gestión del acceso, si está basada en roles, mejor que mejor.

La segunda, es que nadie debe tener acceso más que a lo estrictamente necesario para realizar sus funciones. Así que, cerrarlo todo y solo abrid lo necesario, aunque trabajosa, puede ser una buena política.

Y la tercera, es que a pesar de las prisas y del exceso de trabajo, más vale hacer y revisar bien las cosas, porque por un pequeño despiste, se puede ir al traste cualquier excelente trabajo. Esta última, es aplicable a casi cualquier cosa que os enfrentéis.

Por último, me alegro de volver con vosotros y de escribir en el blog después de estos meses, y como siempre, espero comentarios y dudas. Nos vemos.