Imagina o seguinte cenário: você tem um servidor windows com um banco de dados publico na internet porque depende disso para alguma aplicação. Ai um atacante consegue encontrar uma brecha no SQL através de SQL Injection e penetra no SQL. Ele vai chamar uma função para dar comandos no servidor e com isso tomar posse da máquina, pulando do SQL para o CMD. Sim isso é possível. E tem um comando para desativar a capacidade de se executar comandos através do SQL.

Esse recurso se chama xp_cmdshell.

Ele é uma stored procedure (um procedimento armazenado) do Microsoft SQL Server que permite executar comandos do prompt do Windows (o cmd.exe) diretamente de dentro do banco de dados. Se um invasor conseguir explorar uma falha de SQL Injection com privilégios administrativos (como o usuário sa), ele pode usar o xp_cmdshell para pular do banco de dados para o sistema operacional e assumir o controle total do servidor.

Como desativar o xp_cmdshell

Para fechar essa porta e garantir que o recurso fique inativo, você deve executar o seguinte script no seu banco de dados (geralmente pelo SQL Server Management Studio):

-- 1. Habilita a visualização das opções avançadas do servidor
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
GO

-- 2. Desativa o xp_cmdshell
EXEC sp_configure 'xp_cmdshell', 0;
RECONFIGURE;
GO

-- 3. (Opcional, mas recomendado) Oculta as opções avançadas novamente por segurança
EXEC sp_configure 'show advanced options', 0;
RECONFIGURE;
GO

Boas práticas de segurança para acompanhar esse bloqueio:

• Padrão do SQL Server: Nas instalações mais recentes do SQL Server, o xp_cmdshell já costuma vir desativado por padrão por questões de segurança. De qualquer forma, é sempre recomendado rodar o script acima para garantir que ninguém o tenha ativado no passado durante alguma manutenção.

• Ataque na raiz (Código): Desativar o xp_cmdshell é excelente para conter danos, mas a linha de frente real contra o SQL Injection deve ser sempre no seu código PHP ou na aplicação web. O ideal é blindar as consultas usando Prepared Statements (como o PDO com parâmetros tipados), de forma que o banco de dados nunca interprete o texto digitado pelo usuário como um comando executável.

• Princípio do Menor Privilégio: Nunca faça a sua aplicação web conectar ao banco de dados usando o usuário sa (System Administrator). Crie um usuário no SQL Server que tenha apenas permissão de leitura, gravação e atualização nas tabelas específicas que o site precisa. Se o usuário da aplicação não tiver privilégios de administrador de sistema, mesmo que ocorra uma injeção de SQL, o invasor não terá a permissão necessária para tentar reativar o xp_cmdshell à força.