Como devo configurar a proteção do banco de dados em relação à injeção de sql quando todos os scripts php são falhos?

Question

Eu herdei um aplicativo web php que é muito inseguro, com um histórico de injeção de sql. Eu não posso consertar os scripts imediatamente, eu prefiro que eles estejam correndo para ter o site em execução, e há muitos scripts php para lidar com o primeiro php. No entanto, tenho controle total sobre o servidor e o software no servidor, incluindo controle total sobre o banco de dados mysql e sobre seus usuários.

Vamos estimar em algo como 300 scripts gerais, 40 scripts semi-privados e 20 scripts privados / seguros.

Então, minha pergunta é como melhor proteger os dados, com a suposição implícita de que a injeção de sql do lado do php (por exemplo, em algum lugar dessa lista de 300 scripts) é inevitável?

Meu plano de primeiro rascunho é criar vários níveis de diferentes usuários autorizados no banco de dados mysql. Dessa forma, posso proteger os dados & scripts na maioria das necessidades de segurança primeiro (categoria "privada / segura"), então a segunda camada de tabelas de banco de dados & scripts ("semi-private"), e finalmente lidar com a segurança do resto do aplicativo php em geral (com o resultado de finalmente proteger as tabelas de banco de dados que tratam essencialmente de informações "públicas", por exemplo, coisas que requer).

Portanto, 3 usuários de banco de dados (público, semiparticular e seguro), com um usuário diferente se conectando a cada um dos três grupos diferentes de scripts (os scripts seguros, os scripts semi-particulares e os scripts públicos). Dessa forma, eu posso impedir todo o acesso a "seguro" de "público" ou de "semi-privado" e a "semi-privado" de "público". Existem outras alternativas que eu deveria procurar? Se um sistema de acesso em camadas é o caminho a percorrer, quais são as melhores abordagens?

    

Answer 1

A resposta simples é "Você não pode realmente proteger contra injeção de SQL no nível do banco de dados". Uma vez que eles estejam conectados ao banco de dados com uma consulta em mãos, seu banco de dados irá executá-lo - se alguém tiver injetado maldade nesse SQL, o melhor que você pode esperar é mitigar o dano que eles podem causar.

Em termos de atenuação de danos, o que você já descreveu é uma ótima abordagem: restringir cada script a uma conta de usuário do banco de dados limitada ao acesso mínimo exigido pelo script (Selecionar, Inserir, Atualizar, Excluir e somente ao específico subconjunto de tabelas que o script deve tocar).
Isso não protege seu banco de dados de injeção de SQL - limita apenas a quantidade de dados que alguém pode roubar (ou destruir) com base no script que eles comprometeram. Um atacante determinado provavelmente atacará primeiro os scripts "interessantes", que têm os dados mais procurados que desejam em primeiro lugar.

Em termos de problemas imprevistos, a separação em funções do usuário pode fornecer apenas um ganho mínimo de segurança (se você tiver muitas consultas complexas e scripts de tabela cruzada que executam várias ações) com o risco de quebra severa ( especialmente se você tiver muitas consultas cruzadas complexas de scripts que fazem várias coisas).

É interessante notar que a auditoria do seu banco de dados neste nível provavelmente levará tanto tempo (se não mais) do que a substituição de todas as suas chamadas atuais com consultas parametrizadas apropriadas que tornam os ataques de injeção SQL difíceis ou impossíveis.

    

Answer 2

Recomendamos que você consulte o link do PHP-IDS. Não vai ser um substituto para garantir os scripts, e isso não impedirá todos os ataques, mas é um bandaid realmente fantástico se você deve aplicar um bandaid de segurança. Isso frustrará os hackers de conveniência e fará com que eles passem para o próximo alvo. Não vai impedir ninguém de determinado.

Isso fará o melhor esforço para adivinhar:

• XSS
• Injeções SQL
• Explorações PHP conhecidas
• Ocultar dados em diferentes formatos

Combinado com mod_security, ajudará imensamente.

Sua estratégia de particionamento é 100% correta. Pense além das Injeções SQL, porque, se elas existirem, provavelmente haverá outras classes de ataques. Elevações de privilégios por exemplo ou seqüestro de sessão? Você pode achar que o particionamento é mais difícil do que se imaginava, dependendo da natureza de como o site é projetado.

Por fim, morder a bala e recodificar é o que precisa acontecer.

    

Answer 3

mod_security para o apache ou um módulo de firewall de hardware IDS / IPS fará a análise de solicitações, bloqueando possíveis injeções de SQL. Mas tenho certeza que outros comentaristas explicarão os riscos em detalhes.

    

Answer 4

Você precisa do GreenSQL . Eu nunca usei isso sozinho - em um ambiente de produção, de qualquer forma, mas ele age como uma consulta para o MySQL e filtra consultas perigosas que indicam injeção de SQL.

    

Answer 5

Você pode (se tiver talento, tempo ou recursos) escrever um proxy de banco de dados que fica entre o banco de dados e scripts PHP e filtra consultas SQL questionáveis. Se todos ou a maioria dos scripts PHP estiverem chamando as mesmas bibliotecas de API de banco de dados, recomendo implementar os filtros lá. Certifique-se de criar arquivos de correção (usando diff), portanto, se sua API do PHP DB for atualizada, você poderá reaplicar suas alterações.

    

Answer 6

Você pode usar o Proxy Mysql para verificar / modificar todas as solicitações em tempo real. Pode ser difícil impedir a mineração de dados do D, mas pelo menos você pode remover todos os DROP, por exemplo.