¿Es una buena práctica mostrar 403 errores de acceso no autorizados al usuario?

En el entorno de producción, normalmente desea revelar la menor información posible. Para ese propósito, es preferible mostrar códigos de error genéricos:

• Error 400 para errores relacionados con el cliente: solicitud incorrecta, autenticación necesaria, etc.
• Error 500 para errores relacionados con el servidor: Base de datos inactiva, sitio inactivo por mantenimiento, etc.

Idealmente, no debería optar por las páginas de error predeterminadas proporcionadas por su servidor web. Puede crear sus propias páginas de error o editar las páginas de error predeterminadas de manera que oculte cualquier información que pueda haber utilizado por un atacante. Por ejemplo, aquí hay un error de uno de nuestros servidores al acceder a una URL protegida con contraseña:

Másalládeeso,esunproblemadefacilidaddeusoydependeengranmedidadeloscasos.¿Nodeberíasredirigiralosusuariosalapáginadeinicio?¿Estánesasáreasprotegidasconcontraseña?¿Deberíaverunformulariodeiniciodesesión?¿Osimplementedeseamostrarelmensajedeerrorgenéricoconelestilodesusitio?

Aquíhayunejemplodeunapáginadeerrorennuestrositio(Security.StackExchange)

Como dice @Adnan, en cualquier entorno de producción desea limitar la fuga de información. Una redirección también puede ser útil para un atacante.

Llevaría la recomendación un poco más lejos y diría que no solo debe limitar los tipos de errores, sino que también debe entregar páginas de errores personalizadas al usuario final.

Las 400 o 500 páginas predeterminadas a menudo incluyen una gran cantidad de información sobre el error, y esto es muy útil para un atacante: pueden averiguar qué software está ejecutando, qué servidor web, qué sistema operativo, etc.

Por lo tanto, la recomendación general en un contexto de error es entregar una página personalizada al usuario que reconozca un error pero no regale nada, por ejemplo:

Internamente, todos los errores deben registrarse, para que puedan ser resueltos.

Sí, todo lo que significa es que la autenticación fue exitosa pero la cuenta no está autorizada para ver este recurso. Según RFC2616 , se podría utilizar un HTTP 404 en su lugar. Sin embargo, no lo recomendaría ya que devolver un 403 ofrece los siguientes beneficios:

1. Para los sistemas con varias cuentas (es decir, el directorio activo), esto proporciona la información necesaria para el usuario que quizás haya iniciado sesión con la cuenta incorrecta y debería probar con otra.
2. Si el usuario necesita acceso legítimamente, el ticket del servicio de asistencia se puede procesar rápidamente sabiendo que está obteniendo un 403.

En su escenario, los "chicos malos" ya han iniciado sesión correctamente. Es de esperar que el proceso de autorización sea lo suficientemente sólido como para impedir un daño mayor (es decir, no use cadenas de consulta).

Si bien muchos han comentado sobre la desactivación de mensajes de error detallados, estoy de acuerdo en que esta es una buena práctica. Sin embargo, un 403 es muy diferente de un error de servidor como HTTP 500 donde se imprime información interesante en la pantalla. Una vez más, un 403 simplemente significa que no está autorizado para ver un recurso en particular después de iniciar sesión correctamente. Por lo tanto, continúe devolviendo un 403 pero no incluya información detallada de diagnóstico.

Si este es un recurso extremadamente sensible, considere segregarlo y requiere autenticación de doble factor. Esto proporcionará la seguridad adicional de que la persona es realmente quien dice ser cuando accede al recurso protegido.

Para responder a su primera pregunta, no es bueno para mostrar este error al usuario final.

Mostrar una página de error predeterminada que contenga los detalles técnicos exactos es no es una buena práctica . Tiene problemas tanto de seguridad como de experiencia de usuario.

Si el usuario no es una persona técnica, este tipo de mensajes de error pueden molestarlo con todas las cosas técnicas que contiene. No sabrá qué hacer para resolver el error que no entiende.

Por otra parte, si el usuario es una persona técnica (digamos que es mala), existe la posibilidad de que tenga un vistazo o una idea general de su estructura de seguridad de su aplicación. . Existe una posibilidad justa de exponerse si descubre los patrones de seguridad en su aplicación porque los ataques que intenta romper su aplicación serán precisos o al menos un poco más específicos .

Para responder a tu segunda pregunta, la Redirección a otra página no parece ser una buena idea fácil de usar.

Cuando el usuario intenta acceder a algo y lo redirige directamente a la página de inicio o cualquier otra página, echará a perder la facilidad de uso y el interés de los usuarios en su aplicación. Si realmente quiere redirigirlo a algún lugar, muéstrele un mensaje personalizado y luego rediríjalo. Para que al menos sepa lo que está pasando.

El manejo de errores es la solución para su problema. Siempre piense en la perspectiva del usuario cuando prepare los mensajes de error. Mostrar personaliza los mensajes de error que el usuario puede entender fácilmente y no expone ninguna estructura de seguridad de su aplicación.

Línea inferior : cualquier tipo de error debe ser manejado y personalizado antes de informar al usuario.

¿Es una buena práctica? Depende. Estoy de acuerdo en que probablemente no desee enviar la página predeterminada al usuario. Eso arruina la facilidad de uso y puede proporcionar demasiada información para un atacante si hay detalles técnicos.

Sin embargo, ¿qué hay de enviar 403 errores de manera más general? Aquí estoy menos convencido de que es una mala idea en general, y la pregunta más grande es ¿qué ocurre o por qué ocurre el error 403?

Si veo un error 403 con una página de error predeterminada, o particularmente cuando ni siquiera estoy conectado, este grita "administrador incompetente" y, por lo tanto, podría invitar a un ataque no tanto a través de lo que revela sobre su sitio como lo que revela sobre tus administradores.

Pero supongamos que estoy conectado. He sido autenticado. ¿Hay alguna razón cuando intento acceder a un recurso para el que no estoy autorizado a ver que debería devolver algo más que un mensaje de error 403 Acceso denegado? Devolver el código de error permite que esto se maneje programáticamente en el lado del cliente, lo que es una consideración importante con cosas como los servicios web.

Obviamente, esto nunca debería suceder cuando intentas hacer algo expuesto en la interfaz de usuario. Pero como una capa adicional de defensa y oportunidad para el manejo de errores, no veo nada malo en devolver el código de error en este caso, porque puede haber causas (de nuevo, los servicios web vienen a la mente) donde pasar el código de error es El mejor camino a seguir.

Así que con esto en mente, veo algunas cosas que deben considerarse sin prejuicios:

¿Qué información se filtra que puede ayudar a un atacante? ¿Qué información se debe proporcionar con el mensaje de error?

En general, con LedgerSMB registramos extensivamente, pero cualquier cosa que tenga acceso denegado es un mensaje muy corto en el lado del cliente. Esto permite que el administrador vea lo que está pasando pero no el usuario.

¿Qué necesita saber el cliente de manera mínima para manejar el error?

En general, IMO, solo se denegó el acceso a pesar de haber iniciado sesión. El 403 puede ser útil aquí, pero no desea enviar mucho más que esto.

¿Qué otras preocupaciones tienes?

Muchas cosas dependen del modelo de amenaza. El modelo de amenaza de una aplicación web orientada al cliente es muy diferente de una aplicación web de línea de negocios, y estos son diferentes de un servicio web de suscripción. Debe saber qué está protegiendo y de qué se trata antes de continuar.

Mirando el contexto de su pregunta, parece ser una página de administración que requiere inicio de sesión para acceder. Le preocupa que al mostrar un error 403 a usuarios no autorizados, permita que cualquiera que adivine la URL sepa que la página está allí, pero no se pudo acceder.

Obviamente, la página de error, si existe, no debe revelar información como la arquitectura y la versión de su servidor. No voy a repetir esas cosas muy básicas otra vez. Hay algunas opciones aquí. Veamos las distintas opciones:

Una redirección a la página de inicio de sesión del administrador:

Esto es útil desde el punto de vista del administrador. Puede haberse producido un tiempo de espera de sesión. El administrador que hizo clic en el enlace a esta página sería redirigido directamente a la página de inicio de sesión para continuar con el acceso privilegiado. En cuanto a otros, también serían redirigidos a la página de inicio de sesión. Si se trata de un inicio de sesión oculto, sería equivalente a mostrarle la puerta a un pirata informático. En este caso, recomendaría encarecidamente que no se redireccione.

Error de visualización 403:

Este error es inequívoco. Tanto el administrador como el usuario podrían entender que su acceso está denegado porque no están autorizados. Para el administrador, podría deberse a un tiempo de espera de sesión, o cuando acceden a la página desde una dirección IP no reconocida. Ahora, un pirata informático determinado puede, por la posibilidad de prueba y error, también en esta página. La pregunta es, ¿debería estar preocupado por eso? Si la página en sí no acepta ninguna entrada del usuario y está seguro de que el código está limpio y bien escrito, entonces no debería.

Mostrar error 404:

Al mostrar un error 404, de hecho estás haciendo seguridad a través de la oscuridad . No hay duda de que la seguridad aumenta, pero no debe confiar únicamente en ella. Un usuario normalmente seguiría adelante al ver un error de archivo 404 no encontrado. Hay una compensación aquí ya que su administrador puede confundirse cuando se muestra un código de error diferente al que se espera. Si su administrador lo sabe, entonces, no debería ser un gran problema.

Estás haciendo esta pregunta porque estás preocupado. Para tener tranquilidad, me gustaría la tercera opción. Pero en última instancia, depende de usted decidir en función de los requisitos de seguridad de su aplicación web.