O Owl for IIS identifica os SQLs antes de serem executados em tempo de execução. Isto é, implementando o módulo de Auto-Proteção do Aplicativo Runtime (RASP).
Sua aplicação web está recebendo entrada por meio de parâmetros de consulta e post. A entrada pode produzir cross-site scripting, injeção SQL e outras violações de segurança. Até agora sabemos WAF tem limitações, pois não é executado no processo, mas na rede: 1. Alguns podem ser dependentes de chaves SSL quando o tráfego é criptografado. Aqueles não podem lidar com o DH caso 2. Ele não pode ter certeza que o usuário é responsável por quais instruções SQL como o processo pode usar um usuário diferente para executar o SQLs 3. Sofisticado URL adulteração pode enganar o WAF 4. Desenvolvedor definir um backdoor no aplicativo (Ativado pelo parâmetro de consulta extra para finalmente executar código malicioso dedicado). Como WAF pode descobrir isso?
Tome o exemplo a seguir: o navegador do usuário está enviando esta solicitação HTTP para obter uma lista de usuários no departamento http: //applicationHost/getData.aspx? Code = derpatment. Mas o usuário também pode alterar manualmente em um valor de código diferente como http: //applicationHost/getData.aspx? Code = company. Além disso, podemos dizer que os SQLs estão sendo executados por um pool de threads que é autenticado usando algum usuário genérico. 1. Ferramenta de banco de dados não pode dizer que originou a solicitação. A única opção que você tem para correlacionar detalhes do usuário (nome e IP) com instrução SQL exata que o aplicativo está executando é por ser No ponto em que o aplicativo está enviando a instrução SQL fora do processo. Esse é o SQL real após a aplicação concluir o processamento de entrada. Nenhuma heurística, nenhum falso positivo. Owl for IIS tem como objetivo expor todas as instruções SQL.
O que é novo nesta versão:
Versão 1.3:
Comentários não encontrado