Curso MIT "Segurança de sistemas de computadores". Aula 9: Segurança de Aplicativos Web, Parte 3

Instituto de Tecnologia de Massachusetts. Curso de Aula nº 6.858. "Segurança de sistemas de computador". Nikolai Zeldovich, James Mickens. 2014 ano

Computer Systems Security é um curso sobre o desenvolvimento e implementação de sistemas de computador seguros. As palestras abrangem modelos de ameaças, ataques que comprometem a segurança e técnicas de segurança baseadas em trabalhos científicos recentes. Os tópicos incluem segurança do sistema operacional (SO), recursos, gerenciamento de fluxo de informações, segurança de idiomas, protocolos de rede, segurança de hardware e segurança de aplicativos da web.

Palestra 1: “Introdução: modelos de ameaças” Parte 1 / Parte 2 / Parte 3
Palestra 2: “Controle de ataques de hackers” Parte 1 / Parte 2 / Parte 3
Aula 3: “Estouros de Buffer: Explorações e Proteção” Parte 1 / Parte 2 / Parte 3
Palestra 4: “Separação de Privilégios” Parte 1 / Parte 2 / Parte 3
Palestra 5: “De onde vêm os sistemas de segurança?” Parte 1 / Parte 2
Palestra 6: “Oportunidades” Parte 1 / Parte 2 / Parte 3
Palestra 7: “Sandbox do Cliente Nativo” Parte 1 / Parte 2 / Parte 3
Aula 8: “Modelo de Segurança de Rede” Parte 1 / Parte 2 / Parte 3
Aula 9: “Segurança de aplicativos da Web” Parte 1 / Parte 2 / Parte 3

Público: então o que impede um invasor de encontrar uma chave? Onde está localizada essa chave secreta?



Professor: Sim, essa é uma boa pergunta. Na maioria dos casos, o cliente da AWS não é um navegador, mas algumas máquinas virtuais em execução na nuvem. Assim, você vê apenas a comunicação entre máquinas virtuais. Você também pode imaginar que os usuários possam, de alguma forma, fornecer esses links ou incorporá-los de alguma forma em HTML. Se você tiver algo parecido com o mostrado no quadro dentro do código-fonte HTML ou JavaScript, terá o código para criar essa solicitação. Portanto, se eu lhe fornecer uma dessas coisas, você poderá fazer uma solicitação em meu nome.

Público: É possível usar o MAC para clientes normais?

Professor: para normal - você quer dizer navegadores?

Público: para usuários comuns.

Professor: o fato é que a questão de onde a chave realmente vive é crucial. Porque se a chave pode ser roubada tão facilmente quanto os cookies, não ganhamos nada. Portanto, em muitos casos, todas essas coisas são armazenadas em algum lugar da nuvem e servem para trocar dados entre máquinas virtuais e são transmitidas de servidor para servidor também na nuvem. Assim, o desenvolvedor do aplicativo inicia a VM, que usa a terceirização de várias coisas armazenadas na AWS.

Público-alvo: existe um problema de atraso na rede aqui, para que o invasor possa enviar a mesma solicitação imediatamente após o usuário e também obter acesso?

Professor: sim, basta dizer que várias pessoas defenderam dissertações sobre o tema segurança de timestamps. Mas você está absolutamente certo, porque consideramos um exemplo bastante grosseiro.



Imagine que aqui, neste exemplo String To Sign, na linha DATE, teremos o valor “segunda-feira, 4 de junho”. Então, se de alguma forma o invasor puder obter acesso a tudo isso, ele poderá repetir a solicitação do usuário. O fato é que a AWS permite que você use a data de validade dessas coisas. Portanto, uma coisa que você pode fazer é adicionar o campo Expira aqui e assumiremos que uma data de validade foi definida.



Então, posso fornecer esse link para várias pessoas diferentes, e o servidor verificará se as solicitações expiraram.

Público: mesmo que a data de validade seja de apenas 200 milissegundos, mas o invasor esteja monitorando a rede, ele poderá enviar apenas algumas cópias da solicitação em vez de uma.

Professor: é absolutamente verdade que, se o atacante atacar a rede e ver como essas coisas são transmitidas por fio, e houver espaço suficiente para manobra na data de vencimento, ele poderá definitivamente fazer esse ataque.

Portanto, essa foi uma visão geral de como os cookies sem estado funcionam. Isso levanta uma questão interessante: o que significa fazer logout com cookies desse tipo? A resposta é que você realmente não está saindo. Quero dizer, você tem essa chave e sempre que quiser enviar uma solicitação, basta enviá-la. Mas o servidor pode revogar sua chave.

Suponha que o servidor revogou a chave. Mas você pode criar uma dessas coisas GET e, quando enviar uma mensagem para o servidor, ele dirá: "Sim, eu já sei seu ID de usuário, a chave foi revogada e não atenderei sua solicitação". No entanto, existem nuances e, se falarmos sobre coisas como SSL, capacitar uma pessoa é muito mais fácil do que lembrá-las.

Como tal, existem várias outras coisas que você pode usar se quiser evitar os cookies tradicionais para implementar a autenticação. Um deles é o uso de armazenamento DOM, que contém informações sobre autenticação do lado do cliente. Você pode usar o repositório DOM para armazenar alguns estados de sessão que geralmente são colocados dentro de cookies.



Se você se lembra da última aula, o repositório DOM é uma interface-chave dos valores que o navegador fornece a cada fonte, ou seja, o navegador os retira de lá e os insere em uma string.

O bom é que o DOM não possui regras tão estúpidas em relação às mesmas políticas da mesma origem. Portanto, se esses cookies fossem regulares, você poderia fazer todos esses truques de subdomínio e similares. Na verdade, o repositório DOM está estritamente vinculado a uma única fonte, portanto, você não pode estender nenhum subdomínio. Portanto, estruturas como o Meteor usam esse armazenamento.

Mas observe que, se você deseja salvar as informações de autenticação no repositório DOM, precisará escrever o código JavaScript para transferir essas informações para o servidor, criptografá-las e assim por diante. Aqui está o que você precisa fazer neste caso.
Pode-se usar certificados do lado do cliente, por exemplo, o formato x.509, que contém informações sobre o proprietário, uma chave pública, informações sobre uma autoridade de certificação e uma assinatura digital eletrônica. O bom desses certificados é que o JavaScript não tem uma interface explícita para acessar essas coisas. Portanto, diferentemente dos cookies, onde sempre há uma "corrida armamentista" para encontrar erros de política da mesma origem, os certificados não têm uma interface JavaScript explícita para isso. Portanto, isso é muito bom do ponto de vista da segurança.

Um dos problemas que mencionei brevemente e que discutiremos em detalhes em palestras subsequentes é a revogação de certificados. Se um usuário deixar sua organização, como você pode obter um certificado dele? Isto é bastante complicado.



Além disso, essas coisas não são muito convenientes de usar, porque ninguém deseja instalar vários certificados para cada site que você visita. Portanto, os certificados de autenticação não são muito populares, com exceção das empresas ou organizações responsáveis ​​pela segurança com grande responsabilidade. Isso conclui nossa discussão sobre cookies.

Agora vamos falar sobre vulnerabilidades de protocolo na pilha da web. Um dos tipos interessantes de ataques é usar erros nos componentes do navegador, por exemplo, ao analisar URLs. Então, como a análise de URL pode causar problemas para nós?

Suponha que tenhamos um URL do tipo em que caracteres estranhos são incorporados no final por algum motivo:

example.com : 80 @ foo.com.

A questão é: qual é a origem desse URL específico? O Flash pensaria que o nome do host é example.com. Mas quando o navegador analisa o endereço, ele pensa que a origem do host nesse caso é foo.com.



Isso é muito ruim, porque quando temos duas entidades diferentes que estão confusas sobre a origem da origem do mesmo recurso, há muitos problemas desagradáveis.
Por exemplo, um código flash pode ser malicioso e fazer o download de algum material de example.com. Se a exploração foi incorporada à página com foo.com, ela também poderia fazer algumas coisas más por lá. E então ele pega um código do example.com e o executa com os poderes do foo.com. Muitas regras complexas de análise como essas tornam a vida muito difícil. Isso acontece o tempo todo.

Acabamos de examinar a desinfecção do conteúdo, cuja principal idéia é que geralmente é muito melhor quando existem regras de análise mais simples para esse tipo de coisa. No entanto, retrospectivamente, isso é difícil, porque o HTML já está lá.
Agora vamos falar sobre minha vulnerabilidade de segurança favorita - arquivos com a extensão .jar, que são um arquivo ZIP com parte do programa Java. Os arquivos JAR do navegador se tornam o alvo do ataque, principalmente os applets Java. Por volta de 2007, um excelente site chamado lifehacker.com explicou como incorporar arquivos zip em imagens. Não está claro de quem você está tentando se esconder, mas lifehacker.com garante que você possa fazer isso.

Eles usam principalmente o fato de que, se você observar formatos de imagem, como GIFs, o analisador funcionará de cima para baixo. Primeiro, ele encontra as informações no cabeçalho e depois olha os bits restantes localizados na parte inferior.



Como se viu, os programas que geralmente manipulam arquivos ZIP funcionam de baixo para cima, ou seja, o oposto da direção da análise da imagem. Primeiro, eles encontram as informações no rodapé do arquivo e descompactam o que está dentro do arquivo morto. Assim, se você colocar um arquivo de imagem que contenha um arquivo ZIP, ele passará em todas as verificações, até a verificação do Flickr, como qualquer outra imagem, e até aparecerá como uma imagem no seu navegador.

Mas somente você conhecerá a verdade oculta. Somente você estará ciente de que, se você pegar esse arquivo, poderá descompactá-lo e usar as informações contidas nele. Parece um truque barato, mas os hackers nunca dormem, eles constantemente querem arruinar nossas vidas. Então, como eles implementam essa ideia?

Eles entendem que os arquivos JAR são derivados do formato .zip. Isso significa que você pode criar uma animação GIF ou uma imagem estática que teria um arquivo JAR, ou seja, código executável JavaScript, na parte inferior.

Mais tarde, as pessoas chamaram esse método de ataque de GIFAR, meio GIF, meio JAR e as duas metades são más. Foi demais. Quando as pessoas descobriram essa oportunidade pela primeira vez, acharam incrível, mas não entenderam como usá-la. Mas, como se viu, com base nas seguintes ações podem ser feitas.



Então, como você pode fazer isso? Você acabou de usar o CAD. Tome .gif, pegue .jar, use o arquivo de extração automática - boom e o GIFAR o atacou!

Então, depois de ter isso, o que você pode fazer? Existem alguns sites confidenciais que permitem aos usuários fornecer dados, mas não tipos de dados arbitrários. Portanto, o Flickr ou algo parecido pode não permitir o envio de ActiveX arbitrário ou qualquer outro HTML arbitrário. Mas você poderá enviar imagens. Assim, você pode criar uma dessas coisas e enviá-la para um desses sites confidenciais que permite enviar imagens. O que você precisa fazer para realizar um ataque bem-sucedido neste caso?



Em primeiro lugar, envie esta imagem "recheada" para um desses sites. Em segundo lugar, use o método de ataque de script entre sites XSS, usando as vulnerabilidades existentes. Para fazer isso, você precisa inserir o applet, escrevendo em JavaScript essa expressão:

Esse código explora a vulnerabilidade de script entre sites e, portanto, será iniciado no conteúdo do site. O GIFAR passará na verificação de origem, porque vem de um site com uma fonte de origem comum, apesar do fato de esse código ter sido inserido por um invasor.

Portanto, agora o invasor tem a oportunidade de executar esse applet Java no contexto do site da vítima com todas as permissões de origem. E uma dessas coisas será realmente identificada corretamente como uma imagem GIF. Mas há um código oculto aqui. Deixe-me lembrá-lo de que, inicialmente, o navegador descompacta os arquivos arquivados; portanto, antes de tudo, ele inicia a parte JAR, ignora a parte superior do GIF. Então isso é realmente incrível.

Existem algumas maneiras bastante simples de corrigir isso. Por exemplo, você pode usar o carregador de applet, que entende que não deve haver nenhum lixo aleatório. Em muitos casos, são usadas informações de metadados que mostram o tamanho desse recurso. Nesse caso, o carregador iniciará, como esperado, a partir do topo, analisará seu comprimento, verificará que o applet termina na parte superior e parará. Ele não se importa com a parte inferior, é possível que seja igual a 0. No nosso caso, esse carregador não ajudará, pois ele começará a processar a solicitação da parte inferior arquivada e parará na frente da parte superior, ignorando-a.

O que eu gosto sobre isso é que ele realmente mostra a largura da pilha de software da Internet. Tomando apenas esses dois formatos, GIF e JAR, você pode criar um ataque realmente desagradável.

Você pode fazer o mesmo com arquivos PDF. Você pode colocar um PDF em vez de um GIF e chamar esse ataque de algo dos perigos do PDFAR. Mas, no final, as pessoas descobriram esse problema e agora são eliminadas vulnerabilidades desse tipo.

Público: O que você pode fazer com esse tipo de ataque, que não pode ser feito com um ataque regular de script entre sites do XSS?

Professor: Essa é uma boa pergunta. Portanto, o que é bom nisso é que o Java geralmente pode ser uma ferramenta mais poderosa do que o JavaScript comum, porque usa regras ligeiramente diferentes, a mesma política de origem e coisas do gênero. Mas você está certo de que, se você pode executar scripts entre sites, a execução do próprio JavaScript pode ser bastante prejudicial. Mas a principal vantagem desse método é que essa tecnologia de ataque funciona dentro do miniaplicativo e pode fazer o que não é possível com o código de script malicioso comum.

Então, como eu disse, esse é o meu ataque favorito de todos os tempos, principalmente porque fez com que pessoas respeitáveis ​​em segurança de computadores pensassem em uma palavra como GIFAR.

Outra coisa interessante é o uso de ataques baseados no tempo. Geralmente, as pessoas não pensam no tempo como um recurso, que pode ser um vetor para ataques. Mas, como observei alguns minutos atrás, esse tempo pode realmente ser um meio de introduzir uma exploração no sistema.

O ataque específico que vou falar com você é o ataque secreto do canal. A idéia desse ataque é que um invasor encontre uma maneira de trocar informações entre dois aplicativos, e essa operação de troca não está autorizada. Um invasor está de alguma forma usando alguma parte do sistema para transferir bits de informações entre dois recursos diferentes.

Um bom exemplo disso é um ataque de sniffing CSS. O que é esse ataque?

Suponha que um invasor tenha um site que um usuário possa visitar. Fazer um usuário visitar um site é realmente bastante simples. Você cria um anúncio ou envia um email de phishing.

Assim, o invasor possui um site que o usuário visita. E o objetivo do invasor é descobrir quais outros sites o usuário visitou. Um invasor pode querer saber disso por vários motivos. Talvez ele esteja interessado nas consultas de pesquisa do usuário, ou ele esteja tentando descobrir onde essa pessoa trabalha, ou talvez ele queira saber se essa pessoa está visitando alguns sites "vergonhosos" e assim por diante.



Como um invasor fará isso se a única coisa que ele controla é um site que ele deseja convencer um usuário a visitar? Uma maneira possível é usar as cores dos links. Como você sabe, se você seguiu um link uma vez, na próxima vez em que ele aparecerá no seu navegador em uma cor diferente, indicando que você já fez a transição para esse link. Esta é realmente uma vulnerabilidade de segurança.

Como isso significa que em seu site, um invasor pode gerar uma lista enorme de possíveis URLs que você pode visitar e, em seguida, usar JavaScript para ver qual a cor que esses URLs adquiriram. E se a cor do link do URL estiver roxa, significa que você visitou este site. Portanto, este é um truque bastante sutil.

O interessante é que, em muitos casos, você nem precisa exibir URLs. Você pode organizar os links na forma de cabeçalhos na tela de acordo com o tipo de dominó, e esses cabeçalhos mudarão de cor se o usuário usar esse link. Talvez você ache muito entediante rastrear todos esses URLs de sites visitados pelo usuário? Mas esse processo pode ser otimizado usando várias passagens filtradas na lista de endereços. Por exemplo, você pode ver primeiro se o usuário visitou o URL de nível superior - cnn.com, Facebook.com e assim por diante. Se a resposta for sim, você pode selecionar as páginas de nível superior mais visitadas. Dessa forma, você pode realmente limitar sua pesquisa.

Portanto, a função inofensiva que os navegadores suportam para ajudar o usuário, dizendo: “ei, amigo, foi para onde você foi!” Pode ser usada por um invasor como evidência comprometedora para você.



Como posso impedir um ataque ao canal secreto? Na prática, isso é feito para que o navegador simplesmente engane o JavaScript sobre a cor correta dos links.Quando o JavaScript tenta examinar um link e seu estilo, o navegador sempre diz que o link nunca foi visitado. E embora isso não pareça ser uma solução muito boa, evita um ataque desse tipo. Penso que podemos conciliar que o JavaScript não será capaz de ler as cores dos links, este não é o fim do mundo. Mas isso corrige o problema de um invasor que deseja descobrir quais sites você visitou? Claro que não.

Portanto, o próximo ataque que um invasor pode organizar é um ataque baseado em cache. O objetivo dela é o mesmo: um hacker deseja saber quais sites você visita.

, , . , , .



, — , , , , , . , , , , . ?

, . . , .

, Google Map Tiles. , «» Google Map, , , , . .

? , . , , , . , .

, , , JavaScript . , , DNS.
: , , DNS , . , , -, , -. , , DNS . , , DNS , .



: JavaScript .

: , !

: , , , , ?

: , . , — - , , , - URL. , API– , .

: - , , ?
: . , API — . , ? , DNS , .

, , IP — ? ! , JavaScript . . , , ! .

A idéia principal aqui é processar o URL que você visitou anteriormente mais rapidamente.

       <iframe>,    , ,   , , , ,    ,        <iframe>.     <iframe> ,   ,   <iframe>      .       ,    origin,        . 

Assim, o invasor não pode mais tocar em nada e conclui que ele foi capaz de determinar o site que você visitou anteriormente.

Vejo você na próxima palestra!


A versão completa do curso está disponível aqui .

Obrigado por ficar conosco. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando a seus amigos, um desconto de 30% para os usuários da Habr em um análogo exclusivo de servidores básicos que inventamos para você: Toda a verdade sobre o VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps de US $ 20 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD de 1Gbps até dezembro de graça quando pagar por um período de seis meses, você pode fazer o pedido aqui .

Dell R730xd 2 vezes mais barato? Somente nós temos 2 TVs Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 a partir de US $ 249 na Holanda e nos EUA! Leia sobre Como criar um prédio de infraestrutura. classe usando servidores Dell R730xd E5-2650 v4 custando 9.000 euros por um centavo?