Teste de script entre sites
Cross-site Scripting (XSS) ocorre sempre que um aplicativo pega dados não confiáveis e os envia ao cliente (navegador) sem validação. Isso permite que os invasores executem scripts mal-intencionados no navegador da vítima, o que pode resultar no sequestro de sessões do usuário, desfigurando sites ou redirecionando o usuário para sites mal-intencionados.
Vamos entender os Agentes de Ameaça, Vetores de Ataque, Fraqueza de Segurança, Impacto Técnico e Impactos de Negócios dessa falha com a ajuda de um diagrama simples.
Tipos de XSS
Stored XSS - O XSS armazenado, também conhecido como XSS persistente, ocorre quando a entrada do usuário é armazenada no servidor de destino, como banco de dados / fórum de mensagem / campo de comentário, etc. Então, a vítima é capaz de recuperar os dados armazenados do aplicativo da web.
Reflected XSS - O XSS refletido, também conhecido como XSS não persistente, ocorre quando a entrada do usuário é imediatamente retornada por um aplicativo da web em uma mensagem de erro / resultado da pesquisa ou a entrada fornecida pelo usuário como parte da solicitação e sem armazenar permanentemente os dados fornecidos pelo usuário.
DOM Based XSS - O XSS baseado em DOM é uma forma de XSS quando a origem dos dados está no DOM, o coletor também está no DOM e o fluxo de dados nunca sai do navegador.
Exemplo
O aplicativo usa dados não confiáveis na construção sem validação. Os caracteres especiais devem ser escapados.
http://www.webpage.org/task/Rule1?query=tryO invasor modifica o parâmetro de consulta em seu navegador para -
http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS"</h3>Mãos em
Step 1- Faça login no Webgoat e navegue até a seção de cross-site scripting (XSS). Vamos executar um ataque Stored Cross-site Scripting (XSS). Abaixo está o instantâneo do cenário.
Step 2- Conforme o cenário, vamos fazer o login como Tom com a senha 'tom' conforme mencionado no próprio cenário. Clique em 'ver perfil' e entre no modo de edição. Como tom é o invasor, vamos injetar script Java nessas caixas de edição.
<script>
alert("HACKED")
</script>
Step 3 - Assim que a atualização terminar, tom recebe uma caixa de alerta com a mensagem "hackeado", o que significa que o aplicativo está vulnerável.
Step 4 - Agora, de acordo com o cenário, precisamos fazer o login como jerry (HR) e verificar se jerry foi afetado pelo script injetado.
Step 5 - Depois de fazer login como Jerry, selecione 'Tom' e clique em 'ver perfil' conforme mostrado abaixo.
Enquanto visualiza o perfil de tom da conta de Jerry, ele consegue obter a mesma caixa de mensagem.
Step 6 - Esta caixa de mensagem é apenas um exemplo, mas o invasor real pode realizar muito mais do que apenas exibir uma caixa de mensagem.
Mecanismos Preventivos
Os desenvolvedores devem garantir o escape de todos os dados não confiáveis com base no contexto HTML, como corpo, atributo, JavaScript, CSS ou URL em que os dados são colocados.
Para os aplicativos que precisam de caracteres especiais como entrada, deve haver mecanismos de validação robustos antes de aceitá-los como entradas válidas.