security - utilizado - ¿Está bien devolver un HTTP 401 para un recurso no existente en lugar de 404 para evitar la divulgación de información?

no se permite el verbo http post utilizado para tener acceso a la ruta

Question

Inspirado por un pensamiento al ver la pregunta " Código de estado HTTP correcto cuando el recurso está disponible pero no accesible debido a los permisos ", usaré el mismo escenario para ilustrar mi pregunta hipotética.

Imagina que estoy construyendo un servicio web de uso compartido del automóvil.

Supongamos que el siguiente

GET /api/persons/angela/location

recupera la posición actual del usuario "angela". Solo Angela y un posible conductor que la va a recoger deberían saber su ubicación, de modo que si la solicitud no se autentica a un usuario apropiado, se devuelve una respuesta 401 no autorizada .

Considera también la solicitud

GET /api/persons/john/location

cuando ningún usuario llamado john se ha registrado en el sistema. No hay recursos de John y menos un recurso para la ubicación de John, por lo que obviamente devuelve un 404 Not Found . O lo hace?

¿Qué pasa si no quiero revelar si John está registrado o no en el sistema?

(Tal vez los nombres de usuario provienen de un pequeño grupo de inicios de sesión universitarios, y hay un grupo ciclista muy militante en el campus que tiene una visión muy tenue del uso del automóvil, incluso si están agrupados) Podrían hacer solicitudes a la URL para cada usuario , y si reciben un 401 en lugar de 404, infiere que el usuario es un combinador de automóviles)

¿Tiene sentido devolver un 401 no autorizado para esta solicitud, a pesar de que el recurso no existe y no hay un conjunto posible de credenciales que se podrían suministrar en una solicitud para que el servidor devuelva 200?

Answer 1

Creo que está bien si quieres devolver un 401 no autorizado si la solicitud la realiza un cliente que no es un usuario. Sin embargo, si un usuario hace la solicitud y se autentica, entonces no creo que un 401 sea la mejor solución. Si cree que devolver un 404 podría comprometer la seguridad de algunos usuarios, entonces puede considerar devolver un 403 Forbidden o quizás un 200 OK, pero simplemente no especifique una ubicación. Si busco bob de usuario y obtengo una respuesta y consulta para el usuario sam y obtengo una respuesta de error, ya sea 401, 403, 404, etc., entonces probablemente pueda llegar a la conclusión de que significa que el usuario sam no existe.

200 OK sin ubicación especificada puede ser la solución más disfrazada.

Editar: Solo para ilustrar lo que estoy proponiendo. Devuelva un 401 si el cliente no está autorizado. De lo contrario, siempre devuelva un 200 OK.

<user-location for="bob">
    <location>geo-coordinates here</location>
</user-location>

<user-location for="sam">
    <location/>
</user-location>

Esto realmente no indica si Sam existe o no, o tal vez simplemente no hay datos de ubicación para él actualmente.

Answer 2

Creo que la mejor solución sería devolver 403 (prohibido) para cada página (potencial) en una clase, si el usuario no está autenticado para ver cualquiera de ellos. Si el usuario es, devuelve 404 para cosas que no están allí y 200 para cosas que sí lo son.

Answer 3

En realidad, el W3C recommends (RFC 2616 §10.4.4 403 Prohibido) hacer lo contrario. Si alguien intenta acceder a un recurso, pero no está autenticado correctamente, devuelva 404 entonces, en lugar de 403 (Prohibido). Esto aún resuelve el problema de divulgación de información.

Si el servidor no desea poner esta información a disposición del cliente, se puede usar el código de estado 404 (No encontrado).

Por lo tanto, nunca devolvería 403 (o 401). Sin embargo, creo que su solución también es razonable.

EDIT: Creo que Gabe está en el camino correcto. Debería reconsiderar parte del diseño, pero ¿por qué no?

• No encontrado - 404
• Permiso insuficiente específico del usuario - 404
• Permiso general insuficiente (nadie puede acceder) - 403
• No iniciado sesión - 401

Answer 4

Si los nombres de usuario son información confidencial, no los coloque directamente en el URI. Si usa hipermedia en sus representaciones, puede hacer que sea tan fácil para las aplicaciones de un cliente autorizado navegar su API sin tener que filtrar información en sus URL.

Las URL procesables son geniales para la información a la que desea que todos puedan acceder fácilmente. Sin embargo, para un cliente RESTful, no hay problema con el uso de URI que son completamente opacos.

Una vez que haya eliminado la correlación directa entre el usuario y el URI, se vuelve difícil inferir información de un código de respuesta 401.

Answer 5

Devuelve 401 Unauthorized en cualquier caso en el que el usuario no pueda ver una página en particular, ya sea que exista o no.

De RFC 2616 : "Si la solicitud ya incluía credenciales de autorización, entonces la respuesta 401 indica que la autorización ha sido rechazada por esas credenciales".

Considere los servidores HTTP que usan listas separadas de credenciales para la autenticación a diferentes URL. Obviamente, un servidor no debe verificar cada lista cuando se solicita una URL, por lo que si las credenciales no están en esa lista aplicable, porque las solicitudes HTTP son completamente independientes entre sí, tiene sentido devolver 401 Unauthorized si las credenciales no son válidas. para esa URL en particular.

Además, la descripción de 403 Forbidden incluye: "La autorización no ayudará y la solicitud NO DEBE repetirse". Por el contrario, si el usuario elige iniciar sesión con las credenciales correctas, la Autorización lo ayudará.