En este artículo, analizamos las vulnerabilidades asociadas con la habilitación de SQL Mail y buscamos formas de solucionar estos problemas de seguridad.
Para los usuarios de SQL, es posible habilitar una base de datos de correo electrónico para responder a las consultas de la base de datos, ya que las consultas son manejadas por la propia base de datos. Sin embargo, un requisito mínimo para activar una base de datos de correo electrónico en la aplicación es ejecutar SQL Server con una cuenta de dominio que tenga acceso a privilegios de administrador local. Sin embargo, uno de los inconvenientes de usar bases de datos SQL activadas por correo es que cualquiera puede solicitar datos, sujeto a las restricciones establecidas, del sistema en forma de consulta, y obtendrá la información. Por lo tanto, es importante limitar la cantidad de datos que se pueden obtener. Otra cosa importante a tener en cuenta acerca de esta función es que Consulta no significa solo una solicitud de solo lectura, sino cualquier declaración SQL legítima.
Algunas de las vulnerabilidades más comunes a las que se enfrentan en SQL Server
- Dado que no solo considera una consulta como una solicitud de solo lectura, sino como una declaración SQL válida, un usuario no solo puede usarla para obtener información, sino también para procesar inserciones, actualizar, eliminar comandos y crear y modificar objetos.
- El enfoque de respuesta al remitente de la función no intenta verificar al solicitante ni siquiera verificar la autorización necesaria. Sin embargo, puede evitar que esto suceda habilitando las comprobaciones de autenticación y autorización para consultas de correo SQL, pero esto aún no garantizará ninguna integridad o confidencialidad.
- La seguridad de esta función es deficiente y se basa completamente en el desconocimiento del intruso. Por lo tanto, un intruso inteligente, con conocimientos básicos sobre cuentas de correo electrónico, puede enviar una consulta para que se ejecute en la base de datos objetivo.
¿Cómo puedes mantener el SQL Server Vulnerabilidades de correo electrónico en la bahía
Como ya se mencionó, la seguridad de la función se maneja mal y, en base a la ignorancia del atacante, el usuario puede literalmente esperar que el atacante no esté al tanto de las vulnerabilidades del sistema. No solo termina aquí, hay mucho más que el usuario solo puede desear: el atacante no conoce las bases de datos implementadas y vulnerables, la cuenta que se puede usar para realizar consultas, etc. La característica de la base de datos de correo se debe a lo inconsciente que es el atacante. Uno de los consejos sugeridos para proteger la base de datos de correo del acceso no autorizado sería no tener nombres realmente obvios para las cuentas utilizadas. Los atacantes pueden simplemente adivinar las cuentas privilegiadas si son demasiado obvias. Otra cosa a tener en cuenta es, si está habilitando el correo de varias bases de datos; agregue cuentas separadas para cada base de datos. Por último, pero no menos importante, mantén un SQL Server herramienta de reparación útil para hacer frente a incidentes de corrupción de datos.
Una advertencia
La inyección SQL es otra técnica común utilizada por los piratas informáticos para obtener acceso a la base de datos, utiliza un método de prueba y error, mediante el uso de URL web para introducir modificaciones y luego obtener acceso a la base de datos. La base de datos de SQL Mail en comparación con las inyecciones de SQL es más fácil de descifrar, y los atacantes la prefieren más, no es tan intensiva y requiere tanto tiempo como las inyecciones de SQL, por lo tanto, asegúrese siempre de que sus cuentas estén protegidas y de que la autenticación y autorización del usuario estén habilitadas para la función.
Introducción del autor:
Victor Simon es presidente y presidente de DataNumen, Inc., que es el líder mundial en tecnologías de recuperación de datos, incluyendo reparar accdb corrupción y productos de software de recuperación de sql. Para más información visite www.datanumen.com