Os ataques atuais baseados na Web geralmente são de injeção. O motivo da injeção geralmente é a filtragem incompleta de variáveis, o que permite que invasores executem programas ilegalmente ou consultem e modifiquem dados arbitrários. À medida que os ataques de injeção se tornam cada vez mais intensos, surgiram alguns códigos de filtragem especializados. Porém, imperfeições em alguns códigos de filtragem podem levar a novos ataques. A seguir, utiliza-se o código de filtragem mais utilizado - programa anti-injeção universal SQL - para explicar as causas, métodos de utilização e medidas preventivas da vulnerabilidade.
O programa anti-injeção universal SQL foi escrito por Feng Zhiqiu do Firefox. É um código anti-injeção bastante completo. Ele pode implementar filtragem de envio para os caracteres de filtro definidos e pode registrar as informações de dados enviadas pelo IP do invasor. Ao usá-lo, você só precisa adicionar o código <--#Include File="WrSky_Sql.Asp"--> ao cabeçalho do arquivo para evitar a injeção para obter a filtragem de variáveis. Se você adicionar o código do programa após o arquivo de conexão do banco de dados (como conn.asp), poderá obter filtragem variável de todo o site, obtendo assim o efeito anti-injeção.
Ok, vamos dar uma olhada primeiro no código da parte de filtragem de variáveis:
'--------Parte de definição-------
Dim Fy_Post,Fy_Get,Fy_In,Fy_Inf,Fy_Xh,Fy_db,Fy_dbstr
'Personalize as strings que precisam ser filtradas, separadas por "maple"
Fy_In = "' maple; maple e maple exec maple insert maple select maple delete maple update maple count maple * maple% maple chr maple mid maple master maple truncate maple char maple declare"
'---------------------------------
%>
<
Fy_Inf = split(Fy_In,"Maple")
'-------Parte do POST------------------
Se Request.Form＜＞Então
Para cada Fy_Post em Request.Form
For Fy_Xh=0 To Ubound(Fy_Inf)
Se Instr(LCase(Request.Form(Fy_Post)),Fy_Inf(Fy_Xh))＜＞Então
'-------OBTER parte------------------
Se Request.QueryString＜＞Então
Para cada Fy_Get In Request.QueryString
For Fy_Xh=0 To Ubound(Fy_Inf)
If Instr(LCase(Request.QueryString(Fy_Get)),Fy_Inf(Fy_Xh))＜＞Então
este código define a filtragem de variáveis comumente injetadas, como "'", "e", etc. suficiente ou demais, você pode fazer isso sozinho. Adicione ou subtraia caracteres. Obviamente, desde que os dados enviados ao servidor por meio de get ou post contenham caracteres filtrados, serão proibidos pelo programa. Isto leva a um problema. Se você adicionar código de programa após o arquivo de conexão do banco de dados do fórum, desde que o conteúdo da postagem contenha caracteres filtrados, ele será banido. De acordo com a filtragem de conteúdo padrão, parece quase impossível postar se o conteúdo estiver em inglês. Além disso, alguns caracteres especiais (como o sinal de porcentagem "%") são algumas vezes usados ao definir o estilo do fórum. Se esses caracteres especiais forem filtrados, todo o fórum não funcionará corretamente. Em relação ao problema mencionado acima, usei dvbbs para testá-lo e o resultado foi exatamente o que eu esperava.
A maneira de resolver o problema acima é evitar a injeção de instruções de conexão apenas nos arquivos que precisam ser filtrados. Mas essa carga de trabalho é relativamente grande e geralmente os webmasters não sabem quais arquivos precisam ser filtrados. Portanto, minha sugestão é adicionar o código de filtragem ao conn.asp, depois criar um connl.asp que não contenha o código de filtragem e conectar os arquivos que definitivamente não precisam de filtragem e o código de filtragem tem impacto no funcionamento do esse arquivo para conn1.asp, mas você precisa observar que o conteúdo básico dos dois arquivos de conexão de dados deve ser consistente. Além disso, é melhor não usar caracteres filtrados nas configurações de estilo. Se você realmente precisar usá-los, poderá excluir a filtragem desses caracteres no programa anti-injeção.
O texto acima é sobre o impacto do programa antiinjeção no funcionamento do site e não pode causar nenhum dano. Na verdade, o verdadeiro dano vem da parte de gravação de dados. Vamos dar uma olhada nesta parte do código:
''--------Escrever no banco de dados-------Cabeçalho----. ----
Fy_dbstr="DBQ="+server.mappath("SqlIn.mdb")+";DefaultDir=;DRIVER={Driver Microsoft Access (*.mdb)};"
Definir Fy_db=Server.CreateObject("ADODB.CONNECTION")
Fy_db.open Fy_dbstr
Fy_db.Execute("inserir em SqlIn(Sqlin_IP,SqlIn_Web,SqlIn_FS,SqlIn_CS,SqlIn_SJ) valores('"&Request.ServerVariables("REMOTE_ADDR")&"','"&Request.ServerVariables("URL")&"',' GET','"&Fy_Get&"','"&replace(Request.QueryString(Fy_Get),"'","''")&"')")
Fy_db.fechar
Definir Fy_db = Nada
'--------Escrever no banco de dados-------Tail--------
Response.Write "＜Script Language=JavaScript＞alert('Prompt do sistema anti-injeção universal Fengwang SQL↓ nnPor favor, não tente injetar caracteres ilegais nos parâmetros nnHTTP://WwW.WrSkY.CoM Versão do sistema: V2.0 (ASP) versão perfeita');＜Script＞
Response.Write "Operação ilegal! O sistema fez os seguintes registros↓＜br＞"
Response.Write "IP de operação:"&Request.ServerVariables("REMOTE_ADDR")&"<br>"
Resposta.Escreva "Tempo de operação:"&Agora&"<br>
resposta.Write "Página de operação:"&Request.ServerVariables("URL")&"<br>"
Response.Write "Método de envio: GET＜br＞"
Response.Write "Enviar parâmetros:"&Fy_Get&"<br>"
Response.Write "Enviar dados:"&Request.QueryString (Fy_Get)
Resposta.Fim
Terminar se
Próximo
Próximo
Terminar se
'---------------------------------
A função deste código é registrar as informações e ações do invasor. que possamos tomar as contramedidas necessárias. Pode-se ver no código que o programa registra o IP do invasor, o endereço de envio, o conteúdo do envio, etc., mas obviamente existem várias lacunas aqui:
1. Ataques frequentes não são processados. Em outras palavras, não importa como enviamos os dados legais, eles serão registrados pelo programa, o que provavelmente levará a ataques maliciosos do DOS. Eu fiz uma experiência sobre isso. Eu envio a seguinte instrução após o URL de um arquivo protegido: and (select top l asc(mid (username,l,l)) from admin)>0, use o assistente de chave para registrar o processo de envio e, em seguida, repita automaticamente o submissão. Depois de um tempo, o tamanho do banco de dados mudou significativamente (conforme mostrado nas Figuras 1 e 2). Como você pode imaginar, se você usar ferramentas como o Shuoxue para permitir o envio multithread, o DOS definitivamente não será um problema.
Figura 1
Figura 2
2. O comprimento dos dados do registro não está truncado. Isto é o que descobri durante meus testes de programas anti-injeção que afetam as operações do fórum. Conforme mostrado na Figura 3, se o conteúdo da postagem contiver caracteres filtrados, o conteúdo da postagem será totalmente registrado no banco de dados. Fóruns gerais ou sistemas de artigos têm limites na extensão dos artigos publicados, mas o programa anti-injeção universal SQL não impõe nenhuma restrição a isso. Se um invasor enviar um conteúdo muito longo após o URL do arquivo protegido, é provável que o programa trave. Como o dano é relativamente alto, não testei, mas o conteúdo que enviei até 100K foi gravado normalmente.
Figura 3
3. Problema de conversão de conteúdo de dados e explosão de banco de dados. A julgar pelo código, o programa registra os dados enviados ilegalmente diretamente no banco de dados, sem conversão. Em outras palavras, não importa o que você enviar, desde que contenha conteúdo filtrado, o programa registrará todo o conteúdo que você enviar. Este problema não é sério originalmente, mas por uma questão de "segurança", alguns webmasters gostam de alterar todos os arquivos mdb para o sufixo asp. Além disso, há apenas uma tabela no banco de dados do programa anti-injeção, portanto, podemos obter o webshell gravando diretamente a URL do arquivo protegido no banco de dados. Durante o processo de teste, alteramos sqlin.mdb para sqlin.asp. e depois adicionado Depois que o URL do arquivo protegido foi inserido, um backdoor micro ASP Binglangzi foi inserido. Após conectar-se ao cliente Ice Fox, o wedsll foi obtido com sucesso.
Como esse método de obtenção do webshell exige a garantia de que o banco de dados da outra parte esteja sendo executado no formato ASP e conheça o caminho dos dados, devemos encontrar uma maneira de obter o caminho desse banco de dados. Em circunstâncias normais, podemos adivinhar diretamente o caminho do banco de dados, mas na verdade esse caminho pode ser exposto. Olhando todo o programa anti-injeção, não encontramos nenhuma instrução de biblioteca à prova de explosão, então só precisamos acessar ou usar diretamente. o método %5C O banco de dados é exposto Se o código do programa for colocado diretamente após o arquivo de conexão de dados, uma vez que o arquivo de conexão de dados geralmente contém instruções à prova de explosão, não podemos expor o endereço do banco de dados.
Todos os problemas mencionados acima são no processo de registro de dados. Webmasters competentes podem corrigir sozinhos as lacunas relevantes, como bloquear automaticamente IPs para grandes quantidades de envios repetidos de dados. Na verdade, podemos remover completamente a parte de gravação de dados do código, o que não afetará a filtragem de variáveis, e mesmo que as informações do invasor sejam registradas, não será muito útil. Então sugiro que o melhor é remover esse código, para que todas as vulnerabilidades não existam mais.
Ok, este artigo é tudo. Por fim, gostaria de lembrar que ao usar programas de proteção de segurança, você também deve prestar atenção às questões de segurança do próprio programa.
Lembrete especial: o programa anti-injeção 3.0 também tem brechas. as lacunas são mais graves.