Curso MIT "Segurança de sistemas de computadores". Aula 8: Modelo de Segurança de Rede, Parte 2

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

Então, o que acontece se o navegador não processar corretamente o objeto e não conseguir identificar seu tipo? Nesse caso, você pode ter problemas de segurança. Um deles é chamado de ataque MIME.

Você provavelmente conhece o MIME - este é um tipo de cabeçalho não criptografado como text / html, image.jpeg e assim por diante. Portanto, versões mais antigas do navegador IE usavam isso porque pensavam que isso ajudaria o usuário. Às vezes, porém, os servidores da Web atribuem a extensão incorreta ao arquivo do objeto.

Um servidor da Web configurado incorretamente pode anexar o sufixo .html ao que realmente possui a extensão .jpeg, ou vice-versa, por exemplo, criar foo.jpg em vez de foo.html.



Então, nos velhos tempos, o IE estava tentando ajudá-lo. Ou seja, ele pegou algum tipo de recurso, enquanto pensava: "OK, esse recurso afirma ser desse tipo, de acordo com a extensão do nome do arquivo". Mas então ele examinará apenas os primeiros 256 bytes disponíveis neste objeto. E se ele encontrasse certos significados mágicos que indicavam que havia um tipo diferente de extensão para esse objeto, ele simplesmente diria: “ei, eu achei algo legal aqui! "Acho que o servidor da web definiu esse objeto por engano, então, vamos tratar esse objeto como o tipo que encontrei nesses primeiros 256 bytes".
E então todos se tornam vencedores, porque um navegador como o ajudou no desenvolvedor do servidor web, já que agora o site será exibido corretamente. E o usuário vai gostar, porque ele poderá desbloquear esse conteúdo, que costumava ser apenas lixo.

Mas esta é uma vulnerabilidade clara! Suponha que a página contenha algum conteúdo passivo, por exemplo, uma imagem de um domínio controlado por um invasor. No entanto, a página da vítima pensa: "mesmo que seja o conteúdo de um site malicioso de hackers, é apenas conteúdo passivo. Ele não pode fazer nada comigo! Em um caso extremo, uma imagem sem êxito será exibida, mas não poderá abrir nenhum código, porque o conteúdo passivo possui zero privilégios.



Mas o fato é que o IE pode primeiro "cheirar" essa imagem, seus primeiros 256 bytes. E um invasor pode intencionalmente colocar código HTML e JavaScript lá. Acontece que o site da vítima trará o que considera uma imagem e o IE executará código malicioso no contexto da página incorporada.

Este é um tipo de exemplo de como os navegadores são complexos e como adicionar uma intenção muito boa pode causar erros de segurança muito sutis. Então, vamos dar uma olhada em como o navegador protege vários recursos.

Vejamos os quadros e objetos da janela (objetos que são uma janela que contém um documento DOM). Os quadros representam esses universos independentes de JavaScript sobre os quais falamos aqui. Quero dizer, JavaScript é uma instância do nó DOM, como mostra a figura da árvore DOM.

Dessa forma, o quadro existirá como um objeto de nó DOM em algum lugar nesta hierarquia que é visível para JavaScript.

No JavaScript, o objeto window é na verdade um alias para o espaço para nome global. Parece uma ideia estúpida. Ou seja, se você encontrasse o nome da variável global x, também seria possível acessá-la através do nome window.x.

Assim, molduras e objetos de janela são referências muito poderosas para fornecer acessibilidade. E eles contêm ponteiros um para o outro. Um quadro pode conter um ponteiro para um objeto de janela vinculado e vice-versa. De fato, essas duas coisas são equivalentes.
Os quadros e os objetos de janela recebem a origem da origem de origem do quadro da URL ou, como estão sempre em uma parte segura da rede, podem obter o sufixo do nome de domínio original, ou seja, sua origem original.

Por exemplo, um quadro pode começar assim: .xyzcom, aqui você pode ignorar o esquema e o protocolo por um segundo.

Nesse caso, podemos assumir que a fonte de origem para (document.domain) é o sufixo yzcom. Da mesma forma, a fonte de origem deste documento é a expressão z.com. Isso é possível porque z.com é um sufixo do yzcom.



A única coisa que não pode servir como fonte é a expressão .ayzcom, porque é o sufixo errado para a origem da origem. Além disso, o sufixo de origem correto da fonte de origem não pode ser considerado simplesmente .com, porque nesse caso o site poderá afetar de alguma forma cookies ou algo parecido em qualquer site como .com, o que pode ter consequências bastante devastadoras.

A motivação para a aceitação desses tipos de coisas é que ela está relacionada a algum tipo de relação de confiança existente. Parece que, com os três principais parâmetros, tudo está em ordem, e o distúrbio está apenas em .com.

Público: verifica - se que é possível fazer essas divisões em qualquer ponto ou no ponto final? Por exemplo, seu xyzcom pode ser alterado para seu z.com?

Professor: não, isso só se aplica a todos os pontos.



Público-alvo: existe uma razão para não ter sido feito para que você possa indicar um super ou subdomínio, mas ao mesmo tempo eles devem concordar de alguma forma sobre de onde as informações virão? Digamos que quero aceitar apenas o que tem a mesma origem que a minha, para que qualquer um desses recursos possa me atacar. Além disso, tornaríamos essa interação simétrica, para que eu também pudesse influenciá-la. Afinal, o sufixo de origem .com significa que qualquer coisa que tenha o mesmo sufixo .com pode me afetar.

Professor: Sim, isso é difícil, então existem várias respostas para essa pergunta. Em primeiro lugar, as pessoas estavam muito preocupadas com a possibilidade de um ataque com .com. Portanto, eles queriam facilitar a compreensão da linguagem de manipulação de domínio. Assim, eles não permitiram estragar as configurações.

Em um segundo, falarei sobre uma coisa que permite que você faça o que está falando, mas apenas sobre sufixos de domínio. Por enquanto, quero observar que a interface Post Message permite que os domínios se comuniquem se concordarem com isso. Portanto, na prática, as pessoas usam Post Message para implementar a comunicação entre domínios se não puderem estabelecer a mesma fonte de origem usando os truques descritos acima. Dessa maneira, os navegadores podem restringir domínios de acordo com esses sufixos do domínio de origem. E aqui também há uma pequena nuance interessante - os navegadores entendem quando (document.domain) pode ser escrito e quando não pode.

Há uma razão para isso, que consideraremos em um segundo. Assim, dois quadros podem acessar um ao outro se pelo menos uma das duas condições a seguir for verdadeira:

• os dois conjuntos de quadros definidos (documento.domínio) com o mesmo valor;
• nenhum desses quadros pode mudar (document.domain), apesar do valor desse documento nos dois quadros ser o mesmo.

A idéia principal dessas regras é que elas protegem o domínio de ataques causados ​​por seus próprios erros ou pela nocividade de um dos subdomínios.

Imagine que você tem um domínio xyzcom que está tentando atacar o domínio yzcom porque o primeiro domínio contém um erro ou é malicioso. Ele tentará encurtar o domínio yzcom para uma aparência .com e depois começará a "quimizar" com o estado do JavaScript, cookies ou outras coisas.



Portanto, essas duas regras significam que, se o yzcom não quiser permitir que ninguém interaja com ele, ele nunca alterará o valor (document.domain). Portanto, quando o quadro xyzcom quiser reduzi-lo, o navegador dirá: "Sim, você deseja reduzi-lo, mas não tem o direito de fazê-lo!" Há uma coincidência de valores, mas o domínio yzcom não indicou que deseja participar disso. Isso está claro? Nesse caso, pode-se ver que a maioria dos quadros funciona com a mesma política de origem.

Agora podemos ver como nosso nó DOM é processado. É bem simples. Normalmente, os nós DOM obtêm origem do quadro circundante. No caso de cookies, isso é um pouco mais complicado. Os cookies têm um domínio e têm seu próprio caminho. Por exemplo, você pode imaginar que um cookie possa estar associado às seguintes informações, por exemplo * .mit.edu / 6.858. Nesse caso, o cookie possui um * .mit.edu / domain e o caminho 6.858.



Observe que esse domínio pode ser o sufixo completo das páginas no domínio atual. Assim, você pode executar os mesmos truques com ele que falamos anteriormente. Observe que esse caminho 6.858 também pode ser representado como uma barra, seguida por nada, o que indica que todos os caminhos do domínio devem ter acesso ao cookie localizado aqui.

Mas, neste caso, temos um endereço de caminho específico. Portanto, quem define esses cookies, ele tem a chance de ver como é o domínio e o caminho. E esses valores podem ser definidos no lado do servidor e no cliente. No lado do cliente, você terá um objeto JavaScript chamado document.cookie. Este é o formato usado para indicar todos os caminhos para objetos semelhantes.

Há um sinalizador de segurança de sinalizador seguro que você pode definir em um cookie para indicar que é um arquivo HTTPS. Nesse caso, o conteúdo HTTP não deve ter acesso a este cookie. Essa é a principal idéia dos cookies.

Observe que sempre que um navegador gera uma solicitação para um servidor Web específico, ele inclui todos os cookies relevantes nessa solicitação. Existe um tipo de linha de correspondência e algoritmos que permite descobrir que esses cookies são os corretos que devem ser enviados em resposta a uma solicitação, porque eles podem ter coisas estranhas com sufixos de domínio e assim por diante.

Público-alvo: os quadros podem acessar os cookies um do outro se cumprirem essas regras?

Professor: sim, os quadros podem fazer isso. Mas isso depende de como o document.domain está definido, o domínio e o caminho do cookie. Assim, os quadros podem acessar os cookies um do outro, daí a questão: pode haver um problema se permitirmos que quadros arbitrários escrevam cookies arbitrários para as pessoas? Basta dizer que será ruim. A razão pela qual isso é ruim é porque esses cookies permitem que o lado do cliente do aplicativo armazene dados do usuário.

Então, você pode imaginar que, se um invasor puder controlar ou substituir os cookies do usuário, ele poderá, por exemplo, alterar o cookie do Gmail para que o usuário efetue login na conta do Gmail pertencente a esse invasor. Nesse caso, qualquer carta de usuário pode ser lida por um invasor. Você pode imaginar que alguém poderá se apossar de cookies da Amazon.com para colocar todos os tipos de compras ridículas e coisas semelhantes em sua cesta.

Assim, os cookies são um recurso muito importante para proteção. E muitos ataques de segurança de rede são projetados para roubá-los e usá-los para causar danos.
Há outra questão interessante relacionada aos cookies. Suponha que você tenha um site foo.co.uk. E se um site com esse nome de host puder definir cookies para co.uk?



Há uma sutileza aqui relacionada às regras que discutimos anteriormente, porque o primeiro site deve ser capaz de reduzir seu domínio e definir cookies para o segundo, tudo parece legal aqui. Mas, do ponto de vista humano, olhamos para ele com suspeita, porque entendemos que co.uk é um único domínio atômico. No entanto, isso é equivalente a .com. Podemos dizer que os britânicos estragaram tudo que eles deveriam ter aqui. Mas isso não é culpa deles. Do ponto de vista moral, esse é um único domínio que não pode ser quebrado. Portanto, precisamos ter alguma infraestrutura especial para que os cookies funcionem corretamente.

A Mozilla tem um site chamado publicsuffix.org que contém listas de regras sobre como os cookies, origem e domínios devem ser encurtados, levando em consideração que pode haver pontos em algumas coisas, enquanto na verdade eles devem ser considerados um único atômico o todo.

Portanto, quando seu navegador descobrir como deve manipular cookies diferentes, precisará verificar esse lado do problema. Ou, de alguma forma, verifique se foo.co.uk não pode reduzir o domínio para co.uk. Portanto, há um problema muito sensível aqui.

Existem muitos outros problemas interessantes de segurança da Web que descobrimos no processo, porque grande parte da infraestrutura original foi desenvolvida especificamente para o idioma inglês. Por exemplo, texto ASCII ou algo assim. Não foi originalmente projetado para uso pela comunidade internacional.

Mas, à medida que a Internet se tornou mais popular, as pessoas começaram a dizer: "ei, no início, criamos um design bastante amplo de soluções e agora precisamos torná-lo adequado para pessoas que são forçadas a usar nosso entendimento restrito do que significa linguagem". Portanto, agora enfrentamos todos esses problemas loucos.

Considere como as respostas HTTP XML são tratadas pela mesma política de origem. Por padrão, o JavaScript pode gerar apenas um deles se for construído em seu servidor de origem. No entanto, há uma nova interface chamada Solicitação de origem cruzada, ou CORS.

Portanto, essa é a mesma origem, a menos que o servidor tenha ativado esse dispositivo CORS. Basicamente, é adicionado um novo cabeçalho de resposta HTTP chamado Access-Control-Allow-Origin.



Digamos que o JavaScript de foo.com queira fazer uma solicitação HTTP XML para bar.com. Conforme descrito nas regras, a origem cruzada ocorre aqui. E se o servidor bar.com quiser permitir isso, ele retornará sua resposta HTTP com o título: "Sim, deixei o foo.com me enviar essas solicitações XML XML de origem cruzada".

Na verdade, o servidor bar.com pode responder "não", ou seja, pode recusar a solicitação. Nesse caso, o navegador não pode concluir a solicitação XML XML. Portanto, esse é um tipo de coisa nova, que apareceu principalmente devido a aplicativos mistos. É necessário para aplicativos de diferentes desenvolvedores e domínios diferentes, para que eles tenham a oportunidade de trocar dados entre si.



Portanto, em vez de foo.com, pode haver asteriscos aqui se alguém quiser obter dados de origem cruzada, e assim por diante. Eu acho que isso é bem simples. Existem muitos outros recursos que poderíamos ver, como imagens. Graças ao Access-Control-Allow-Origin, um quadro pode carregar imagens de qualquer fonte que desejar. Mas ele não pode verificar os bits desta imagem, porque acredita-se que, com diferentes políticas de fontes de origem, não é bom verificar o conteúdo dos arquivos um do outro.

Embora o quadro não possa verificar os bits, ele ainda pode inferir o tamanho das imagens, pois vê como elas são colocadas na página. Portanto, esse é outro desses casos estranhos, quando a mesma política de fonte de origem tenta impedir todo o vazamento de informações. Mas, de fato, ele não é capaz de impedir tudo isso, porque a incorporação de herança mostra alguns tipos de informações.

O CSS é semelhante às imagens, portanto, um quadro pode incorporar o CSS de qualquer fonte. No entanto, ele não pode verificar diretamente o texto dentro do arquivo CSS se for de outra fonte. Mas ele pode reconhecer o que esse CSS faz porque simplesmente cria vários nós e observa como o estilo deles muda. E parece um pouco estranho.

JavaScript é o meu exemplo favorito de como essa mesma política de origem tenta oferecer suporte a qualquer tipo de sequência inteligente. A idéia aqui é que, se você buscar o JavaScript de forma cruzada, isso será permitido. Você pode ativar a execução de JavaScript externo no contexto de sua própria página, mas não pode olhar o código-fonte.



Portanto, se você tiver uma fonte de tag de script igual a algo fora do seu domínio, quando essa fonte for executada, você poderá iniciar funções nele. Mas você não poderá visualizar o código-fonte JavaScript nele.

Tudo isso parece muito bom, mas tem um monte de "buracos". Por exemplo, o JavaScript é uma linguagem de script dinâmico. E funções são objetos de primeira classe. Assim, para qualquer função f, você pode simplesmente usar a função f.tostring (), e isso fornecerá o código fonte da função f. E as pessoas fazem isso o tempo todo, reescrevem dinamicamente e coisas assim.



Portanto, embora as políticas de origem não permitam visualizar diretamente o conteúdo da tag de script, você pode simplesmente executar a operação especificada e obter o código-fonte.

Da mesma forma, você pode obter seu servidor doméstico a partir do seu domínio, apenas para obter o código-fonte e enviá-lo de volta para você. Na verdade, você acabou de solicitar ao seu servidor doméstico que execute o programa Wget para obter o código-fonte dessa maneira. Portanto, também parece um pouco tolo, ou seja, a política de origem aqui é um pouco estranha.

Público-alvo: suponha que o motivo para fazer isso seja impedir o usuário de receber JavaScript, pois os cookies também podem ser enviados. Ou seja, o usuário poderá adaptar o JavaScript resultante às suas necessidades.

Professor: sim, é.

Público-alvo: portanto, se você solicitar que seu servidor faça isso, ele não poderá fornecer cookies personalizados.

Professor: isso é verdade, embora, na prática, o código-fonte "bruto" não tenha a intenção de ser reformulado pelo usuário. Mas você está certo de que isso impedirá alguns ataques.

, , JavaScript, . , - , -, , . , , , . , , .

, . - - , - HTML JavaScript. , , . .

, JavaScript, , . Java, .



, HTML5 , , , , Java. , .

, HTTP, cookie. , URL, ?



, URL- bank.com. , - . , URL, , , $500 . , .

— , origin, bank.com - , , cookie . : «, , , $500 attacker! , ».
. , , , , . . , , , , - . , , CSRF.

, URL. , c .

, - . – , , :

<form action = “/transfer.cdi”…> 

E dentro deste formulário, teremos os dados de entrada, que geralmente são usados ​​para inserir texto, pressionamentos de teclas, cliques no mouse e similares. De fato, podemos deixar essa entrada oculta para que ela não apareça na página do usuário: tipo de entrada = "oculto", atribua o nome do atributo = "csrf" e o valor do valor aleatório = "a72f ...". Este formulário será gerado no servidor.



Portanto, quando o usuário acessa esta página, no lado do servidor, ele gera esse valor aleatório = "a72f ..." e o incorpora no HTML que o usuário recebe. Portanto, quando o usuário preencher esse formulário, esse URL do formulário:

bank.com/xfer?amount=500&to=attacker

É complementado com um token aleatório:

 http://bank.com/xfer?amount=500&to=attacker/&csrf=a72f... 

Isso significa que agora o invasor poderá adivinhar o token específico que o servidor gera para o usuário toda vez que ele for para a página do banco. Portanto, se tivermos um valor suficientemente aleatório, o hacker não poderá falsificar nada, porque se ele indicar o token errado, as regras do servidor rejeitarão sua solicitação.

58:00 min

Continuação:

Curso MIT "Segurança de sistemas de computadores". Aula 8: Modelo de Segurança de Rede, Parte 3


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 da 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?