Cuando los usuarios hacen una llamada a una base de datos, es importante obtener ciertos bits de información. ¿cómo se puede diseñar su servidor y base de datos para hacer esto?
Cuando se habla de los errores de seguridad que generamos en RavenDB 4.0 vale la pena discutir los siguientes aspectos de los datos.- ¿Puede este comportamiento ayudar a algún usuario malévolo que intenta cortar el sistema?
- Al menos que sea un entorno de administración así que por defecto sólo se da un 403 y hay que encender el informe de errores detallada.
- No se esta cuestionando la decisión técnica, sino simplemente el hecho de devolver información al usuario. Sólo ingresar este servidor del lado de error, o la activación de este comportamiento a un entorno de administración específico como Pablo sugiere, parece más "segura" para mí.
- A menudo, cuando se conecte a una cuenta con el usuario o la contraseña incorrecta, un mensaje de error no especifica si la contraseña o nombre de usuario es incorrecto. Sólo un ejemplo.
Por defecto, podemos rechazar el intento de conexión, lo que resultará en el siguiente error: Network error Connection failed
Consideramos que este tipo de error totalmente inaceptable. Así que tenemos que aceptar la conexión, averiguar cuál es el protocolo de nivel superior (HTTP, por lo general, pero a veces puede ser nuestra propia conexión TCP interna) y enviar un error que el usuario pueda entender. En particular, enviamos un error HTTP 403 espalda con un mensaje que indica cuál es el error.
La preocupación es que hay algo de la divulgación de información inherente al mensaje de error. Analicemos lo siguiente:
- Una solicitud sin un certificado, que error y anunciar que no hizo uso de un certificado, y se requiere que uno. No hay información aquí que el usuario no está ya en posesión de. Puede que no sean conscientes de ello, pero están en posesión del hecho de que no está utilizando un certificado.
- Una petición con un certificado caducado, error y que permiten al usuario saber eso. El usuario ya tiene el certificado, y por lo tanto ya se puede averiguar que ha caducado. No revelamos ninguna información nueva aquí, excepto que el usuario puede tratar de usar esto para averiguar cuál es la hora del servidor es. Esto generalmente no es información confidencial y puede ser seguro asumir que está cerca de lo que el resto del mundo cree que es la hora actual, por lo que no se ve nada aquí que nos debe preocupar.
- Una solicitud de un certificado de que el servidor no sabe nada. Este resultado en un error que indica que el servidor no sabe sobre el certificado. Aquí entramos en cuestión real divulgación de información. Dejamos que el usuario sepa que el certificado no se conoce. Pero ¿qué pueden ganar con esto?
En el caso del nombre de usuario / contraseña, siempre se dice que el nombre de usuario o contraseña es incorrecta, no hay que dejar que el usuario saber si un nombre de usuario ya existe y que sólo la contraseña es incorrecta. Esto es debido a que proporciona al usuario una información que no tienen (que el nombre de usuario es correcta). Ahora, en términos prácticos, esto casi nunca es el caso, ya que tiene enlaces de restablecimiento de contraseña y tienden a decir que si el correo electrónico / nombre de usuario que desea utilizar para restablecer la contraseña es válida.
Sin embargo, con un certificado, no hay dos soluciones de información aquí, hay sólo uno, por lo que no proporcionan ninguna información adicional.
Una petición con un certificado para hacer una operación que el certificado no está autorizado para hacerlo.
Hay algunas cosas a tener en cuenta aquí. En primer lugar, no revelamos ninguna información más allá de lo que el usuario ya nos ha proporcionado. El funcionamiento y la base de datos son proporcionados tanto por parte del usuario, y que utilizan el FriendlyName lo que el usuario puede saber cuál era el certificado en cuestión.
Esta comprobación se ejecuta antes, comprobamos si la base de datos existe realmente en el servidor, por lo que no hay ninguna información divulgada sobre la existencia de bases de datos, ya sea.
Dado que el usuario ha intentado realizar una operación que no se les permite, tenemos que rechazar esa operación (comportamiento honeypot es un asunto totalmente separado y probablemente no debería ser parte de cualquier diseño API cuerdo). Teniendo en cuenta que se rechaza la operación, tenemos que proporcionar errores claros y concisos para el usuario, en lugar de la conexión rechazada error. Teniendo en cuenta el tipo de errores que generamos, creo que proporcionan información suficiente para que el usuario averiguar lo que está pasando.
En cuanto a si debemos registrar este / ocultar esta detrás de un ajuste de configuración, que está muy confuso para mí. Ya se están conectando conexiones rechazadas, debido a que el administrador puede estar interesado en la revisión de este. Pero requiere para llamar al administrador y buscar en algún archivo de registro oscura es un mal diseño en términos de facilidad de uso. Lo mismo es cierto para ocultar detrás de una opción de configuración. O bien esta es una solución segura, y podemos informar de estos errores, o tenemos que poner el sistema en un estado conocido sin garantía (en producción) sólo para poder depurar un problema de conexión.
Fecha actualización el 2021-11-18. Fecha publicación el 2017-11-18. Categoría: Seguridad. Autor: Oscar olg Mapa del sitio Fuente: dzone