Si un usuario autenticado intenta acceder a un recurso restringido

Es posible enumerar los recursos a través de distinciones como estas: si devuelve un 403 para las páginas que existen, pero el usuario actual no puede acceder y 404 para las páginas que no existen, un atacante puede distinguir fácilmente entre recursos válidos e inválidos.

Si esto importa, depende de su aplicación: si revela información en esta circunstancia que tiene valor, puede ser algo malo: si /user/73463 me da un 404 pero /user/64500 me da un 403, puedo hacer un Supongo que el 64500 es un usuario válido cuyo perfil no puedo ver. Por otro lado, si /year/2003 a /year/2016 me da un 403 pero /year/2002 y /year/2020 me dan un 404, todo lo que puedo decir es que no ha creado las carpetas del año en un futuro lejano, y Posiblemente no tengas nada de antes del 2003.

Lo ideal es que no desee proporcionar URL a las que el usuario no tenga acceso ( a partir de su pregunta, no estoy seguro de si la URL que se está siguiendo está en su sitio o en otra parte ). Sin embargo, solo puede controlar esto dentro de su sistema: si el usuario B le envía un enlace al usuario A, el usuario A puede descubrir que el recurso existe sin preocuparse por su respuesta. Eso se aplica si también se proporciona un enlace en un sitio web de un tercero; es probable que nadie se vincule a un recurso inexistente (aunque podrían haberse vinculado a un recurso que ya no existe, en cuyo caso un 404 o 410 sería apropiado). Para sus propios sistemas, debe intentar minimizar las posibilidades de que un usuario legítimo pueda seguir un enlace a un recurso al que no tiene permiso de acceso.

En general, si algo se puede enumerar fácilmente (por ejemplo, un identificador numérico) tiene más sentido devolver una respuesta coherente a todas las solicitudes, ya sea que el estado real carezca de autorización o el recurso no exista. Si algo no se puede enumerar (por ejemplo, el identificador de hash largo), podría tener sentido distinguir entre los estados, pero debe tener en cuenta la posibilidad de que alguien tropiece con recursos que no debería poder detectar y tomar medidas. para evitar esto (p. ej., controlar las altas tasas de solicitud y limitar los intentos aparentes de enumerar los recursos).

No arruines la vida de tus usuarios. Si cometieron un error genuino, o si se les dio un enlace de otro usuario que está autorizado para acceder a la página, es información útil para ellos saber que no tienen permisos suficientes. Habrá casos en los que tengan un reclamo legítimo para acceder a la información y luego podrán pedir ayuda a otro usuario autorizado o recurrir a los procesos de autorización que existen en su sistema. Si les dices que no existe un recurso, en lugar de eso, solo estás agregando más a su carga cognitiva y haciéndoles más difícil resolver la situación en cuestión y hacer su trabajo.

Conclusión desde una perspectiva de usabilidad: siempre se explica claramente por qué se niega el acceso.

Ahora, en el caso de un sitio web público con espacios y roles autenticados, algunos argumentarán que informar a las personas sobre recursos no autorizados les permite a los usuarios malintencionados enumerar recursos. En primer lugar, si están protegidos adecuadamente, esto no siempre es un problema (depende del contexto de su aplicación, obviamente). En segundo lugar, puede registrar accesos denegados a recursos protegidos y detectar / prohibir a los usuarios que están enumerando (especialmente si la configuración de la cuenta tiene un costo sustancial). En tercer lugar, si está realmente preocupado, incluso puede pasar por el proceso inverso de mostrar los mensajes de error correctos a los usuarios en los que confía y dejar solo a los no confiables en la oscuridad (útil si tiene ambos recursos sensibles URL que no necesitan ser enumeradas + registro gratuito en su sistema).

En cualquier caso, no hay un beneficio de seguridad sustancial o incluso una razón válida para complicar la vida de sus usuarios con mensajes de error crípticos.

PS: hay uno o dos artículos de investigación que proponen la idea de que los sistemas de seguridad nunca deben proporcionar retroalimentación; sin ninguna evidencia de que los beneficios superen el costo. Si alguien está de humor para discutir, estoy feliz de tomar uno de esos y desmentirlo por ti. La capacitación básica en diseño de interacción o investigación de usabilidad será suficiente para explicar por qué debe proporcionar mensajes de error valiosos a los usuarios: el costo de usabilidad de no proporcionar comentarios es muy real y nadie en el campo de la investigación de usabilidad lo discutirá.