1. Visão geral
Nos últimos dois anos, os especialistas em segurança deveriam prestar mais atenção aos ataques na camada de aplicativos de rede. Porque não importa quão fortes sejam suas regras de firewall ou quão diligente você seja em corrigi-las, se os desenvolvedores de seus aplicativos da web não seguirem o código seguro, os invasores entrarão em seu sistema pela porta 80. As duas principais técnicas de ataque amplamente utilizadas são os ataques de injeção SQL [ref1] e CSS [ref2]. A injeção de SQL refere-se à técnica de inserção de metacaracteres SQL (caracteres especiais que representam alguns dados) e instruções através da área de entrada da Internet para manipular a execução de consultas SQL de back-end. Esses ataques têm como alvo principalmente servidores WEB de outras organizações. Os ataques CSS garantem que o código Javascript malicioso seja executado na máquina da vítima, inserindo tags de script em URLs e convencendo os usuários que confiam neles a clicar neles. Esses ataques aproveitam a relação de confiança entre o usuário e o servidor. Na verdade, o servidor não detecta a entrada e a saída e, portanto, não rejeita o código JavaScript.
Este artigo discute técnicas de detecção para vulnerabilidades de injeção SQL e ataques CSS. Tem havido muita discussão na Internet sobre estes dois tipos de ataques baseados na WEB, tais como a forma de implementar os ataques, o seu impacto e como preparar e conceber melhor programas para prevenir estes ataques. No entanto, não há discussão suficiente sobre como detectar esses ataques. Usamos o popular IDS Snort de código aberto [ref 3] para formular expressões regulares com base em regras para detectar esses ataques. Aliás, as configurações de regras padrão do Snort incluem métodos para detectar CSS, mas estes podem ser facilmente evitados. Por exemplo, a maioria deles usa codificação hexadecimal, como %3C%73%63%72%69%70% 74%3E em vez de <script> para evitar a detecção.
Dependendo das capacidades da organização ao nível da paranóia, escrevemos múltiplas regras para detectar o mesmo ataque. Se você deseja detectar todos os possíveis ataques de injeção de SQL, basta prestar atenção a quaisquer metacaracteres SQL existentes, como aspas simples, ponto-e-vírgula e travessões duplos. Outra maneira extrema de detectar ataques CSS é simplesmente ficar atento aos colchetes angulares nas tags HTML. Mas isso detectará muitos erros. Para evitar isso, as regras precisam ser modificadas para tornar sua detecção mais precisa, sem evitar erros.
Use a palavra-chave pcre (Expressões regulares compatíveis com Perl) [ref4] nas regras do Snort, e cada regra pode ser executada com ou sem outras ações de regra. Essas regras também podem ser usadas por software público como o grep (uma ferramenta de pesquisa de documentos) para revisar os logs do servidor de rede. No entanto, você precisa ter cuidado, pois o servidor WEB registrará a entrada do usuário no diário somente quando a solicitação for enviada como GET. Se a solicitação for enviada como POST, ela não será registrada no diário.
2. Expressões regulares para injeção de SQL
Ao escolher uma expressão regular para um ataque de injeção de SQL, é importante lembrar que um invasor pode realizar injeção de SQL enviando um formulário ou através do campo Cookie. Sua lógica de detecção de entrada deve considerar vários tipos de entrada organizados pelo usuário (como formulário ou informações de cookie). E se você encontrar muitos avisos vindos de uma regra, fique atento às aspas simples ou ponto e vírgula, pois esses caracteres podem ser entradas válidas em cookies criados pela sua aplicação web. Portanto, você precisa avaliar cada regra em relação ao seu aplicativo da web específico.
Conforme mencionado anteriormente, uma expressão regular detalhada para detectar ataques de injeção de SQL deve prestar atenção aos metacaracteres especiais do SQL, como aspas simples (') e sinais de expansão duplos (--), para descobrir esses caracteres e seus número de equivalentes hexadecimais, as seguintes expressões regulares se aplicam:
2.1 Expressões regulares para detectar metacaracteres SQL
/(%27)|(')|(--)|(%23)|(#)/ix
explicação:
Primeiro verificamos o hexadecimal da aspa simples equivalente, a própria aspa simples ou a dupla sinal de expansão. Estes são caracteres do MS SQL Server ou Oracle, indicando que os seguintes são comentários e todos os subsequentes serão ignorados. Além disso, se você usa MySQL, você precisa prestar atenção à ocorrência de '#' e seu equivalente hexadecimal. Observe que não precisamos verificar o hexadecimal para o equivalente de traço duplo, pois este não é um metacaractere HTML e não será codificado pelo navegador. Além disso, se um invasor conseguir modificar manualmente o traço duplo para seu valor hexadecimal de% 2D (usando um proxy como Aquiles [ref 5]), a injeção de SQL falhará.
A nova regra do Snort adicionada à expressão regular acima é a seguinte:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL Injection - Paranoid"; flow:to_server,established;uricontent:".pl";pcre:
"/ (%27)|(')|(--)|(%23)|
(#)/i";
Este artigo Na discussão, o valor da palavra-chave uricontent é ".pl" porque em nosso ambiente de teste, o programa CGI é escrito em Perl. O valor da palavra-chave uricontent depende do seu aplicativo específico. Este valor pode ser ".php" ou ".asp" ou ".jsp" etc. Deste ponto de vista, não mostraremos as regras correspondentes do Snort, mas daremos as expressões regulares que criam essas regras. Você pode facilmente criar muitas regras do Snort por meio dessas expressões regulares. Nas expressões regulares anteriores, detectamos travessões duplos porque pode haver pontos de injeção de SQL mesmo se não houver aspas simples [ref 6]. Por exemplo, uma entrada de consulta SQL contém apenas valores numéricos, como segue:
selecione valor1, valor2, num_valor3 do banco de dados
onde num_value3=some_user_supplied_number
Neste caso, o invasor pode executar consultas SQL adicionais. A demonstração envia a seguinte entrada:
3; insira valores em some_other_table
Finalmente, os modificadores pcre 'i' e 'x' são usados para combinar case e. ignore respectivamente o espaço em branco. As regras acima também podem ser estendidas para verificar a presença de ponto e vírgula. No entanto, o ponto e vírgula pode muito bem fazer parte de uma resposta HTTP normal. Para reduzir este erro e evitar qualquer ocorrência normal de aspas simples e sinais de expansão dupla, as regras acima devem ser modificadas para detectar primeiro a presença dos sinais =. A entrada do usuário responderá a uma solicitação GET ou POST Geralmente, a entrada é enviada da seguinte forma:
username=some_user_supplied_value&password=some_user_supplied_value
Portanto, as tentativas de injeção de SQL farão com que a entrada do usuário apareça após o sinal a = ou seu valor hexadecimal equivalente.
2.2 Corrija a expressão regular para detectar metacaracteres SQL
/((%3D)|(=))[^n]*((%27)|(')|(--)|( %3B)|(:))/i
Explicação:
Esta regra primeiro presta atenção ao sinal = ou seu valor hexadecimal (%3D), depois considera zero ou mais caracteres, exceto novas linhas, e finalmente detecta aspas simples e traços duplos ou. ponto e vírgula.
Uma injeção SQL típica tentará manipular a consulta original usando aspas simples para obter um valor útil. Este ataque é geralmente discutido usando a string 1'or'1'='1 No entanto, a detecção desta string pode ser facilmente evitada, como usar 1'or2>1 --. o caractere inicial, siga uma aspa simples e adicione 'ou'. A lógica booleana a seguir pode variar em vários estilos, do comum ao muito complexo. Esses ataques podem ser detectados com bastante precisão usando a seguinte expressão regular. O Capítulo 2.3 explica.
2.3 Expressão regular típica de ataque de injeção SQL
/w*((%27)|('))((%6F)|o|(%4F))((%72)|r| (% 52))/ix
explicação:
w* - Zero ou mais caracteres ou sublinhados.
(%27)|' - uma aspa simples ou seu equivalente hexadecimal.
(%6 F)|o|(%4 F))((%72)|r|-(%52) - O caso de 'ou' e seu equivalente hexadecimal.
consulta union'SQL na injeção SQL ataques também são muito comuns em vários bancos de dados. Se a expressão regular anterior detectar apenas aspas simples ou outros metacaracteres SQL, isso pode causar muitos erros. também pode ser expandido com outras palavras-chave SQL, como 'select', 'insert', 'update', 'delete', etc.
2.4 Detectando injeção SQL, palavra-chave de consulta UNION expressão regular
/ ((%27)|(') )union/ix
(%27)|(') - aspas simples e seu equivalente hexadecimal
union - A palavra-chave union
também pode ser usada para personalizar expressões para outras consultas SQL, como >select, insert, update, delete, drop, etc.
Se, neste estágio, o invasor descobrir que o aplicativo da web possui uma injeção de SQL vulnerabilidade, ele tentará tirar vantagem disso. Se ele perceber que o servidor back-end é um servidor MS SQL, ele geralmente tentará executar algum armazenamento perigoso e procedimentos armazenados estendidos. Estes procedimentos geralmente começam com as letras 'sp' ou 'xp'. Normalmente, ele pode tentar executar o procedimento armazenado estendido 'xp_cmdshell' (que executa comandos do Windows por meio do SQL Server). A autoridade SA do servidor SQL tem autoridade para executar esses comandos. Da mesma forma, eles podem modificar o registro através de xp_regread, xp_regwrite e outros procedimentos armazenados.
2.5 Explicação da expressão regular
/exec(s|+)+(s|x)pw+/ix
para detectar ataques de injeção de SQL no MS SQL Server:
exec - palavra-chave que solicita a execução de um procedimento armazenado ou estendido
(s|+)+ - um ou mais espaços em branco ou seus equivalentes http
(s|x) letras p- 'sp' ou 'xp' são usadas para identificar armazenamento ou procedimentos de armazenamento estendido
w+ - um ou mais caracteres ou sublinhados para corresponder ao nome de um procedimento
3. Expressão regular para cross-site scripting (CSS)
Ao lançar um ataque CSS ou detectar uma vulnerabilidade de site, um invasor pode primeiro criar uma tag HTML simples, como < b> (negrito), <i> (itálico) ou <u> (sublinhado), ou ele pode tentar uma tag de script simples como <script>alert("OK")</script>. usado como exemplo para detectar se um site possui vulnerabilidades CSS propagadas pela Internet. Essas tentativas podem ser facilmente detectadas. No entanto, um invasor inteligente poderia substituir a string inteira por seu valor hexadecimal. Desta forma, a tag <script> aparecerá como %3C%73%63%72%69%70%74%3E. Por outro lado, um invasor pode usar um servidor proxy da web como o Achilles para converter automaticamente alguns caracteres especiais, como < para %3C, > para %3E. Quando tal ataque ocorre, os colchetes angulares são geralmente substituídos por valores hexadecimais. na URL.
A expressão regular a seguir detectará qualquer texto contendo <, > em HTML. Ele detectará tentativas de usar <b>, <u> ou <script>. Este regex deve ignorar maiúsculas e minúsculas. Precisamos detectar o colchete angular e seu equivalente hexadecimal (% 3C|<). Para detectar toda a string convertida para hexadecimal, devemos detectar os números e sinais de % digitados pelo usuário, ou seja, utilizar [a-z0-9%]. Isso pode causar o aparecimento de alguns bugs, mas nem todos detectarão ataques reais.
3.1 Expressão regular para ataques CSS gerais
/((%3C)|<)((%2F)|/)*[a-z0-9%]+((%3E)|>)/ix
explicar :
((%3C)|<) - verifica < e seu equivalente hexadecimal
((%2F)|/)* - tag de fechamento/ ou seu equivalente hexadecimal
[a-z0-9%]+ - Verifique a letra na tag ou seu equivalente hexadecimal
((%3E)|>) - Verifique se há > ou sua
regra Snort equivalente em hexadecimal:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"NII Tentativa de script entre sites"; flow:to_server,established; pcre:"/((%3C)|<)((%2F)| /)*[a-z0-9%]+((%3E)|>)/i"; classtype:Web-application-attack; sid:9000; rev:5;)
Cross-site scripting também pode ser usado< img src=>Tecnologia. As atuais regras padrão do snort podem ser facilmente contornadas.
A Seção 3.2 fornece métodos para prevenir esta técnica.
3.2 Expressão regular de ataque CSS "<img src"
/((%3C)|<)((%69)|i|(%49))((%6D)|m|(%4D) ) ((%67)|g|(%47))[^n]+((%3E)|>)/I
explicação:
(%3 C)|<) -<ou seu equivalente hexadecimal
(%69)|i|(%49))((%6D)|m|(%4D))((%67)|g|(%47) -'img' letra ou isso Combinações de variações de equivalentes hexadecimais maiúsculos e minúsculos
[^n]+ - qualquer caractere após <img exceto nova linha
(%3E)|>) -> ou seu equivalente hexadecimal
3.3 CSS Attack Extreme Regular Expression
/((%3C)|<)[^n]+((%3E)|>) /I
Explicação:
Isto A regra simplesmente procura <+qualquer caractere, exceto um caractere de nova linha+>. Dependendo da arquitetura do seu servidor web e da aplicação web, esta regra pode produzir alguns erros. Mas é garantido que ele capturará qualquer ataque do tipo CCS ou CSS.
Resumo:
Neste artigo, propusemos diferentes tipos de regras de expressão regular para detectar injeção de SQL e ataques de script entre sites. Algumas regras são simples e extremas, e um ataque potencial irá soar o seu alarme. Mas estas regras extremas podem levar a alguns erros proativos. Com isso em mente, modificamos essas regras simples para usar estilos adicionais para que possam ser verificadas com mais precisão. Ao detectar ataques a esses aplicativos de rede, recomendamos usá-los como ponto de partida para depurar seu IDS ou métodos de análise de log. Depois de mais algumas revisões, você estará pronto para detectar esses ataques depois de avaliar as respostas não maliciosas à parte normal da transação de rede.
Referência
1. Injeção de SQL
http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
2. Perguntas frequentes sobre scripts entre sites http://www.cgisecurity.com/articles/xss -
faq.shtml
3. O Snort IDS http://www.snort.org
4. Expressões regulares compatíveis com Perl (pcre) http://www.pcre.org
5. Proxy de aplicativo da Web, Aquiles http://achilles.mavensecurity.com
3. Injeção SQL avançada
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
7. COMO FAZER Programação Segura, David Wheeler www.dwheeler.com
8. Ameaças e contramedidas, MSDN, Microsoft