A Uma Visão da
(In)Segurança na Web
XSS- Cross-Site Scripting
Attacks
Segurança em Código Móvel
• Tanenbaum / Wetherall – Redes de
Computadores –Edição 5 – 2011, páginas
537, 538.
Segurança em Código Móvel
• No início, quando páginas Web eram apenas
arquivos HTML estáticos, essas não continham
códigos executável.
• Mas, hoje, as páginas frequentemente contém
pequenos programas (Aplets Java, controles
ActiveX, código de JavaScript, ...
Segurança em Código Móvel
• Baixar e executar um código móvel num
navegador, é sem dúvida, um risco de
segurança.
• Existem alguns métodos para minimizar esse
risco de segurança.
ActiveX
• Programas binários X86 que podem ser
incorporados às páginas Web.
• Tem poder como qualquer outro programa do
usuário e tem potencial para causar grandes
danos.
• A segurança se resume na decisão de executar
ou não o controle ActiveX.
ActiveX
• O método que a Microsoft escolheu para tomar a
decisão de executar ou não, chama-se
Authenticode.
• Baseado na ideia de assinatura de código.
• Cada controle é acompanhado por uma
assinatura digital – um hash do código, assinado
pelo seu criador, com o uso de criptografia
assimétrica.
ActiveX
• Quando um controle ActiveX aparece no
navegador, esse verifica a assinatura, para ter
certeza de que não foi adulterado em trânsito.
• Se a assinatura estiver correta, o navegador
consulta suas tabelas internas para ver se o
criador do programa é confiável.
• Se o criador for confiável, o programa é
executado.
ActiveX
• Não é feito nenhum monitoramento do
comportamento de execução do controle
ActiveX, como um código móvel.
• Se veio de origem confiável e não foi
adulterado em trânsito, é executado pelo
navegador.
ActiveX
• Não é verificado se o código é malicioso ou
não.
• Controles ActiveX podem ser desenvolvidos,
distribuídos, mas podem ser desativados no
navegador.
ActiveX
• Como não há como policiar milhares de
empresas de software que poderiam escrever
código móvel, a técnica de assinatura de
código é um risco que pode ocorrer a
qualquer momento.
JavaScript
• Não tem nenhum modelo de segurança formal.
• Cada fornecedor cuida da segurança de modo
diferente.
• O problema é que permitir a execução de código
estranho em seu navegador significa procurar
problemas.
JavaScript
• Um código móvel pode permitir imagens
gráficas atraentes e de interação rápida, e
muito projetistas de sites acham que isso é
muito mais importante que a segurança.
Extensões do Navegador e Plug-ins
• São programas que estendem a funcionalidade
dos navegadores.
• Complementos oferecem novos recursos ao
navegador, como formas de interagir com
páginas, gerenciamento de senhas, ...
• Plug-ins, normalmente oferecem a capacidade de
interpretar ou exibir um certo tipo de conteúdo,
como PDFs e animações Flash.
Extensões do Navegador e Plug-ins
• Instalar é muito fácil.
• São escritos, dependendo do navegador.
• Se tornam parte da computação confiável do
navegador.
• Se o código tiver bugs, o navegador inteiro fica
comprometido.
Extensões do Navegador e Plug-ins
• Problemas:
– Esses programas podem se comportar de forma maliciosa.
– Plug-ins dão ao navegador a capacidade de interpretar novos tipos de
conteúdo. Frequentemente, o conteúdo está escrito numa linguagem
de programação completa.
– O código pode apresentar vulnerabilidades.
• Solução:
– Só devem ser instalados se realmente forem necessários e apenas de
fornecedores confiáveis.
Vírus
• São outra forma de código móvel.
• Mas, chegam sem ser convidados.
• Desenvolvido para se reproduzir
• Em geral, começa infectando programas
executáveis no disco.
Vírus
• Quando um desses programas infectados é
executado, o controle é passado ao vírus.
• Que pode se difundir para outras máquinas.
• Alguns infectam o setor de inicialização no
disco, e quando a máquina é inicializada, o
vírus é executado.
Applets Java
• Códigos Java que podem ser transferidos, da
aplicação-página para serem executados no
navegador, junto com a apresentação da
página.
• Depois que a página é carregada, o código da
applet é interpretado na JVM do navegador.
Applet Java
• Cada instrução é examinada pelo
interpretador antes de ser executada.
• Isso dá ao interpretador a oportunidade de
verificar se o endereço da instrução sendo
interpretada é válido.
• As chamadas de sistema também são
interpretadas.
Applet Java
• Se o applet for não confiável (veio da
Internet), ele é encapsulado em uma
“sandbox”, para limitar seu comportamento e
bloquear quaisquer tentativas de usar
recursos do sistema.
Applet Java
• Se a applet tentar acessar recursos do sistema,
a chamada de sistema é repassada a um
gerenciador de segurança, que examina a
chamada levando-se em consideração a
política de segurança Java local, que permitirá
acesso, ou não a recursos do sistema.
Ataques com Applet Java
• http://www.offensivesecurity.com/metasploitunleashed/SET_Java_Applet_Attack
• https://nealpoole.com/blog/2011/10/javaapplet-same-origin-policy-bypass-via-httpredirect/
Cross-Site Scripting
• Por Armando Gonçalves da Silva Junior
• Trabalho de Graduação
• UFPE-CIn
• Novembro de 2009
Cross-Site Scripting
• Cross-Site Scripting é um ataque encontrada
normalmente em aplicações WEB que permite
ao atacante inserir código malicioso em uma
página visitada por outro usuário.
• Vulnerabilidade encontrada: a Aplicação no
lado do servidor não trata devidamente a
entrada de dados ...
Cross-Site Scripting (XSS)
• Esse código malicioso somente vai afetar o
navegador da vítima.
• O código malicioso não é executado pelo
servidor.
Tipos de XSS
• XSS Não Persistente (Reflected)
• XSS Persistente (Storage)
• XSS Baseado em DOM
• Os não persistentes são os mais comuns,
sendo os principais responsáveis por ataques
de phishing.
• Esse tipo de ataque depende de uma ação do
usuário – normalmente um click num link
malicioso.
• O XSS se beneficia da confiança depositada pelo
usuário no domínio.
• Possivelmente, poucos clicariam em um link para
http://www.evilsite.com/photos
• Mas, caso um “amigo” mandasse a URL
http://www.nasa-news.org/
%7D%3C/style%3E%3Cscript%3Ea=eval;b=alert;a(b(/XSS/
source));%3C/script%3E%27%22%3E%3Cmarquee%3E%
Ch1%3EXSS%3C/h1%3E%3C/marquee%3E
• O XSS persistente é o tipo mais perigoso, pois não
depende da ação do usuário e frequentemente
acontece em sites no qual o atacante pode postar
texto, como, por exemplo, fóruns, Orkut, Twitter,
Facebook.
• Vírus do Orkut, que profiferou e virou um worm.
• Um worm também começou a se proliferar,
recentemente, no Twitter – o Mikeyy
• DOM Based ocorre quando um código
JavaScript usa o parâmetro passado na URL
para escrever na própria página, e esse
parâmetro não é uma entidade HTML.
• O parâmetro abriga um código malicioso.
Fluxo de Ataque, XSS Não
Persistente.
Cross-Site Scripting Atackes
Cross-Site Scripting Não Persistente
(Reflected XSS)
• Ataques XSS do tipo não persistente são as
mais encontradas na Web.
• Uma lista de sites afetados pode ser
encontrada em http://www.xssed.com
Cross-Site Scripting Não Persistente
(Reflected XSS)
• Com referências a vários sites famosos como
Google, Yahoo, Bradesco, HSBC e Banco do
Brasil.
Tela de busca do Banco do Brasil com o
valor malicioso
Resultado de busca
Fluxo de Ataque, XSS não Persistente.
• Um possível fluxo para esse ataque seria o envio,
por parte do atacante, de SPAM com link
malicioso, para caixa de entrada de email de
vários usuários com alguma notícia referente ao
Banco do Brasil, seguido por uma URL como esta:
http://busca.bb.com.br/buscabb/busca/busca?q=
%22%3E%3Cscript%3ECODIGOMALICIOSO%3C%2
Fscript%3E&x=12&y=9
Fluxo de Ataque, XSS não Persistente.
• Como o usuário confia no domínio do banco,
clicaria no link sem maiores ressalvas.
• A resposta do servidor a tal URL seria a
própria página do banco com um código
malicioso embutido.
Fluxo de Ataque, XSS não Persistente.
• Com esse código sendo executado no browser
da vítima, o atacante pode coletar todas as
informações desejadas e enviá-las para um
servidor próprio, sem que o usuário
percebesse qualquer anomalia ou mesmo
imaginasse que estava sendo vítima de um
ataque.
Fluxo de Ataque, XSS não Persistente
Fluxo de Ataque, XSS não Persistente
1. Atacante manda um SPAM para diversas vítimas e uma delas clica
no link passado, lembrando que essa URL é para a vítima de uma
fonte confiável.
2. Ao clicar a Vítima passará será redirecionada para o site, e como
resposta receberá a página da “notícia” mais o código malicioso
embutido.
3. O navegador da vítima irá mandar informações para o host do
atacante, como cookies.
4. O atacante rouba a sessão da vítima.
Fluxo de Ataque, XSS não Persistente
• Como agravante, para esse tipo de ataque
existem algumas aplicações que guardam
cookies persistentes os quais reautenticam o
usuário a cada visita – também conhecido
como a função “remember me”.
• Nesse cenário, o atacante terá acesso
permanente à conta da vítima.
Fluxo de Ataque, XSS não Persistente
• Casos comuns de ocorrências dessa
vulnerabilidade são quando um parâmetro ou
um cookie ecoado (o valor do
parâmetro/cookie é escrito sem filtros) na
página, possibilitando ao atacante inserir
scripts maliciosos.
Fluxo de Ataque, XSS não Persistente
• Um exemplo ocorre quando o programador
cria uma página para buscas. Tome-se como
url da busca:
http://www.infoconsumo.gov.br/busca/busca.
asp
Fluxo de Ataque, XSS não Persistente
Fluxo de Ataque, XSS não Persistente
Fluxo de Ataque, XSS não Persistente
• A busca pela palavra Inmetro ecoa na página.
• Então para inserimos um código malicioso
deverá ser observado o código fonte.
<input type="TEXT" name="SearchString"
size="25" maxlength="100" value="Inmetro"
class="caixaSimples">
Fluxo de Ataque, XSS não Persistente
• Então, para executar um script, iremos passar como
parâmetro
‘ "><script>alert('xss');alert(document.cookie)</script>
• Assim teremos como resposta:
<input type="TEXT" name="SearchString" size="25"
maxlength="100" value="'">
<script>alert('xss');alert(document.cookie)</script>"
class="caixaSimples">
Fluxo de Ataque, XSS não Persistente
• O que acarretará a execução do script no
navegador da vítima.
Fluxo de Ataque, XSS não Persistente
Fluxo de Ataque, XSS não Persistente
• Então, de modo geral, para realizar XSS
Reflected basta listar todos os parâmetros da
página e colocar valores maliciosos para
execução de scripts, tarefa essa feita por
diversas ferramentas de detecção de
vulnerabilidades.
Fluxo de Ataque, XSS não Persistente
• Como, por exemplo, Acunetix
• Acunetix é uma ferramenta para:
TEST and Demonstration site for Acunetix Web
Vulnerability Scanner
Fluxo de Ataque XSS Persistente
Cross-Site Scripting Attack
Fluxo de Ataque, XSS Persistente
• Também chamado de Storage XSS.
• O XSS persistente é semelhante ao Reflected.
• A diferença entre eles está no fato de não ser
necessário o atacante mandar a crafted URL –
URL maliciosa – que é o endereço da página
junto com código malicioso) para a vítima.
Fluxo de Ataque, XSS Persistente
• Uma vez que a página visitada já contém o
código malicioso anteriormente inserido pelo
atacante.
• O código malicioso será executado a cada
visita.
Fluxo de Ataque, XSS Persistente
• Nesse tipo de ataque existem dois tipos de
armazenamento: no Cliente, ou no Servidor.
• Os servidores, que guardam em sua base de
dados informações passadas pelo usuário e as
mostra para outros, são vítimas em potencial
desse tipo de ataque.
Fluxo de Ataque, XSS Persistente
• Um exemplo em que acontece um XSS
Persistente com Armazenamento no Servidor
são comentários postados por usuários em um
Blog ou Fóruns, que normalmente aceitam
tags HTML.
• Ao invés de comentários, o atacante insere um
script malicioso.
Fluxo de Ataque, XSS Persistente
• Então, caso não haja um filtro, para tratar a
informação no lado da aplicação, o atacante
poderá injetar um código malicioso no
comentário e quem visitar a página, para ler o
suposto comentário, desse modo, rodará o
script no seu navegador.
• No exemplo a seguir, há um exemplo de um
fórum que é vulnerável a esse ataque:
Fluxo de Ataque, XSS Persistente
• Exemplo: Fórum Vulnerável a XSS Persistente
com Armazenamento no Servidor
Fluxo de Ataque, XSS Persistente
• Nessa página, usuários podem deixar
mensagens para outros lerem.
• Na figura anterior, o atacante vai deixar um
código malicioso e para cada usuário que
visite a página vai aparecer a mensagem:
Fluxo de Ataque, XSS Persistente
Resposta do Servidor XSS Persistente
com Armazenamento no Servidor
Fluxo de Ataque, XSS Persistente
• No caso do XSS Persistente com
armazenamento no Cliente, o alvo do ataque
são alguns cookies do usuário que não irão ser
excluídos ao fim da sessão.
• Alguns sites usam o cookie do usuário para
relembrar ações dele.
Fluxo de Ataque, XSS Persistente
• Considere-se um site que relembra o nome do
usuário, segue o código em PHP.
$name=$_COOKIE[“user”];
if (“” == $name)
printf (“Welcome guest\n”);
else
printf (“Welcome back %s\n”, $name);
Fluxo de Ataque, XSS Persistente
• A página funcionaria normalmente, mas nada
impediria do atacante setar o campo user para
<script>alert(‘Poisoned Cookie..’)</script>
• Então toda vez que a vítima entrasse no site
ela receberia como mensagem:
Fluxo de Ataque, XSS Persistente
XSS Persistente com Armazenamento no Cliente
Fluxo de Ataque, XSS Persistente
• Quando esse tipo de ataque é descoberto em
redes sociais, como Twitter, Orkut, Facebook,
... , normalmente são utilizados para criação
de Worms.
Fluxo de ataque com XSS persistente
• Um exemplo desse ataque seria o worm
Mikeyy, por Michel Mooney.
• O autor, inseriu um código malicioso na
página, fazendo com que qualquer um ao ler a
mensagem "infectada“, executasse o código
malicioso do "Mikeyy".
Fluxo de ataque com XSS persistente
Fluxo de ataque com XSS persistente
• O fluxo de ataque com XSS persistente, da figura anterior) pode ser
descrito da seguinte maneira:
1. O computador atacante injeta código malicioso, que vai persistir,
em algum site/cookie vulnerável.
2. A vítima acessa o site vulnerável.
3. Como resposta da requisição a vítima recebe a página normal mais
o código malicioso que está embutido no mesmo.
4. O código é executado pelo navegador da vítima. O computador da
vítima manda dados para o atacante.
Fluxo de ataque com XSS persistente
• No caso do worm Mikeyy [3] e do vírus do
Orkut[8], não houve intenção de roubo de
dados, mas apenas da proliferação do código
malicioso.
• Nestes ataques, o passo quatro foi um pouco
diferente, infectando a página do usuário (o
perfil), ao invés de enviar as informações
coletadas para um servidor do atacante.
Fluxo de ataque com XSS persistente
• O computador da vítima pode torna-se, assim,
um computador atacante, continuando o ciclo
até a falha XSS do site seja corrigida.
Fluxo do Ataque XSS Persistente,
Worm
Fluxo do Ataque XSS Persistente,
Worm
• O fluxo do ataque com XSS Persistente, Worm , pode ser descrito como:
1. O computador Atacante injeta código malicioso em vários profiles,
que vão persistir, em algum site vulnerável.
2. A vítima acessa o site vulnerável
3. Como resposta da requisição, a vítima recebe a página normal mais o
código malicioso que está embutido no mesmo. O código é executado
pelo navegador da vítima.
4. O computador da vítima injeta código malicioso no seu próprio profile
e manda para todos os seus amigos o código malicioso, que vai
persistir, agindo agora como computador atacante.
DOM – W3C
• O Document Object Model é uma interface neutra
de plataforma e de linguagem que permite que
programas e scripts dinamicamente acessar e
atualizar o conteúdo, estrutura e estilo de
documentos.
• O documento pode ser processado e os
resultados desse processamento podem ser
incorporados de volta para a página apresentada.
Cross-Site Scripting Dom-Based
• DOM based XSS
• O Document Object Model (DOM) Based XSS é uma
forma diferente dos dois tipos de ataques já vistos.
• Ambos os ataques se beneficiam de dados que possam
ser manipulados e ecoam o resultado no código fonte
tornando a página insegura.
• O ataque XSS baseado em DOM não tem essa
característica.
Cross-Site Scripting Dom-Based
• XSS DOM-Based segue o seguinte fluxo:
1. O usuário entra em uma página utilizando uma
crafted URL.
2. A resposta do Servidor não contém o script
malicioso de nenhuma forma.
3. Quando o navegador recebe a resposta, o script é
executado.
Cross-Site Scripting Dom-Based
• Esse ataque é possível se a página atacada
usa em seu código parâmetros passados na
URL maliciosa, para gerar dinamicamente o
conteúdo.
• Caso a página possuísse o seguinte trecho de
código ela conseguiria gerar mensagens de
erros dinamicamente a partir do parâmetro
mensagem.
Cross-Site Scripting Dom-Based
<script>
var a = document.URL;
a = unescape(a);
document.write(a.substring(a.indexOf
(“mensagem=”)+8,a.length));
</script>
• Então para explorar essa vulnerabilidade bastava
o atacante alterar o valor do parâmetro
mensagem para um valor malicioso.
Fluxo de Ataque com XSS DOM-Based
• XSS DOM se baseia na exploração da geração
de código dinâmico através de parâmetros
passados pelo usuário.
• Desse modo, tanto pode existir:
- XSS Persistente baseado em DOM,
- Não persistente baseado em DOM
Fluxo de Ataque com XSS DOM-Based
Fluxo de Ataque com XSS DOM-Based
• O fluxo de ataque da figura anterior pode ser descrito:
1. Atacante manda SPAMs para diversas vítimas e uma delas clica no link
passado, lembrando que essa URL é para a vítima de uma fonte confiável.
2. Ao clicar a Vítima passará será redirecionada para o site, e como
resposta receberá a página da “notícia” mais o código malicioso que
não estará no código fonte da página, e sim gerado dinamicamente no
navegador.
3. O navegador da vítima irá mandar informações para o host do atacante,
como o cookie.
4. O atacante furta a sessão da vítima.