Neste artigo, examinamos as vulnerabilidades associadas à habilitação do SQL Mail e formas de contornar esses problemas de segurança.
Para usuários SQL, é possível habilitar um banco de dados de e-mail para responder às consultas do banco de dados, pois as consultas são tratadas pelo próprio banco de dados. No entanto, um requisito mínimo para ativar um banco de dados de e-mail no aplicativo é executar SQL Server com uma conta de domínio com acesso a privilégios de administrador local. No entanto, uma das desvantagens de usar bancos de dados SQL ativados por email é que qualquer pessoa pode solicitar dados, sujeitos a restrições impostas, do sistema na forma de uma consulta e obterá as informações. Portanto, limitar a quantidade de dados que podem ser obtidos é importante. Outra coisa importante a ser observada sobre esse recurso é que Consulta não significa apenas uma solicitação somente de leitura, mas qualquer instrução SQL legítima.
Algumas das vulnerabilidades mais comuns enfrentadas em SQL Server
- Uma vez que não considera uma consulta apenas como uma solicitação somente de leitura, mas como uma instrução SQL válida, um usuário pode usá-la não apenas para obter informações, mas também para processar inserir, atualizar, excluir comandos e criar e modificar objetos.
- A abordagem de resposta ao remetente do recurso não faz nenhuma tentativa de verificar o solicitante ou mesmo verificar a autorização necessária. No entanto, você pode impedir que isso aconteça habilitando as verificações de autenticação e autorização para consulta de correio SQL, mas isso ainda não garantirá nenhuma integridade ou confidencialidade.
- A segurança do recurso é mal gerenciada e baseia-se inteiramente na ignorância do invasor. Portanto, um invasor inteligente, com conhecimento básico das contas de e-mail, pode enviar uma consulta para ser executada no banco de dados alvo.
Como você pode manter o SQL Server Vulnerabilidades de e-mail no Bay
Como já mencionado, a segurança do recurso é mal administrada e com base na ignorância do invasor, o usuário pode literalmente esperar que o invasor não esteja ciente das vulnerabilidades do sistema. Não acaba aqui, há muito mais que o usuário pode desejar – o invasor não conhece os bancos de dados implementados e vulneráveis, a conta que pode ser usada para fazer consultas, etc. O recurso de banco de dados de e-mail decorre de como o invasor não está ciente. Uma das dicas sugeridas para proteger o banco de dados de e-mail contra acesso não autorizado seria não ter nomes realmente óbvios para as contas usadas. Os invasores podem simplesmente adivinhar as contas privilegiadas se forem muito óbvias. Outra coisa a ter em mente é que, se você estiver habilitando vários bancos de dados para correio; adicione contas separadas para cada banco de dados. Por último, mas não menos importante, mantenha um SQL Server ferramenta de conserto útil para lidar com incidentes de corrupção de dados.
Uma Palavra de Cuidado
A injeção de SQL é outra técnica comum usada por hackers para obter acesso ao banco de dados, que faz uso de um método de tentativa e erro, usando URLs da Web para introduzir modificações e, em seguida, obter acesso ao banco de dados. O banco de dados do SQL Mail, em comparação com as injeções de SQL, é mais fácil de quebrar e preferido pelos invasores, não é tão intensivo e demorado quanto as injeções de SQL; portanto, sempre verifique se suas contas estão protegidas e se a autenticação e a autorização do usuário estão habilitadas para o recurso.
Introdução do autor:
Victor Simon é presidente e presidente da DataNumen, Inc., líder mundial em tecnologias de recuperação de dados, incluindo reparar a corrupção do accdb e produtos de software de recuperação SQL. Para mais informações visite www.datanumen.com