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 3Palestra 2: “Controle de ataques de hackers”
Parte 1 /
Parte 2 /
Parte 3Aula 3: “Estouros de Buffer: Explorações e Proteção”
Parte 1 /
Parte 2 /
Parte 3Palestra 4: “Separação de Privilégios”
Parte 1 /
Parte 2 /
Parte 3Palestra 5: “De onde vêm os sistemas de segurança?”
Parte 1 /
Parte 2Palestra 6: “Oportunidades”
Parte 1 /
Parte 2 /
Parte 3Palestra 7: “Sandbox do Cliente Nativo”
Parte 1 /
Parte 2 /
Parte 3Aula 8: “Modelo de Segurança de Rede”
Parte 1 /
Parte 2 /
Parte 3Aula 9: “Segurança de aplicativos da Web”
Parte 1 /
Parte 2 /
Parte 3 Por exemplo, o Django pega esses colchetes angulares, os traduz para o formato HTML e refaz o restante dos caracteres. Ou seja, se o valor do nome personalizado contiver colchetes angulares, aspas duplas e semelhantes, todos esses caracteres serão excluídos. Isso fará com que o conteúdo não seja interpretado como código HTML no lado do navegador do cliente.
Portanto, agora sabemos que essa não é uma defesa muito confiável contra alguns ataques de script entre sites. O motivo, como mostramos no exemplo, é que essas gramáticas para HTML, CSS e JavaScript são tão complexas que podem facilmente confundir o analisador de navegador.
Por exemplo, temos uma coisa muito comum feita dentro da estrutura do Django. Então, você tem alguma função div e queremos definir uma classe dinâmica para ela. Damos à classe o valor de var, e assim por diante. A idéia é que, quando o Django processa isso, ele precisa descobrir qual é o estilo atual e colá-lo aqui.
Nesse caso, um invasor pode criar uma string definindo essa classe, por exemplo, grava "classe 1". Tudo vai bem até este ponto, porque parece uma expressão CSS válida.
Mas o invasor coloca aqui o operador onclick, que é igual ao código JavaScript que faz a chamada do sistema.
Como isso está errado, o navegador deve parar por aqui. Mas o problema é que, se você já viu o HTML de uma página da Web real, tudo está quebrado e confuso, mesmo para sites legítimos e "amigáveis". Portanto, se o navegador parar antes de cada expressão HTML incorreta, nenhum site que você goste simplesmente nunca funcionará. Se você quiser se decepcionar com o mundo e eu não o ajudar, basta abrir o console do JavaScript no navegador ao visualizar o site para ver quantos erros ele causará.
Você pode, por exemplo, acessar a CNN e ver quantos erros você recebe. Sim, basicamente a CNN funciona, mas de maneira muito desigual. Por exemplo, para abrir o Acrobat Reader, você precisa constantemente lançar exceções de ponteiro nulo e, ao mesmo tempo, se sentirá um pouco enganado pela vida. Mas, na Internet, aprendemos a aceitar isso sem muita indignação.
Portanto, como os navegadores devem ser muito tolerantes com essas coisas, eles tentarão transformar código malicioso em algo que lhes pareça razoável. E essa é a vulnerabilidade de segurança.
É assim que a desinfecção do conteúdo funciona, e ainda é melhor que nada. Ela pode pegar muitas coisas prejudiciais, mas não pode se defender de tudo.
Há mais uma coisa em que pensar - o uso de uma linguagem de marcação menos expressiva. Vamos ver o que se entende.
Público-alvo: o que devo fazer se a limpeza de conteúdo não funcionar?
Professor: sim, isso é possível, por exemplo, neste caso, o Django não poderá determinar estaticamente que é ruim. Por exemplo, neste caso em particular. Mas no caso em que insiro uma tag de imagem maliciosa ...
Público: neste caso em particular, eu esperaria que a tarefa da classe estivesse entre aspas e, nesse caso, não deveria ter nenhum efeito ...
Professor: bem, veja bem, existem pequenos truques. Supondo que a gramática de HTML e CSS seja cuidadosamente definida, você pode imaginar um mundo em que os analisadores ideais possam, de alguma forma, capturar esses problemas ou transformá-los em coisas normais. Mas, de fato, a gramática HTML e CSS sofrem de imprecisões. Além disso, os navegadores não implementam especificações. Portanto, se você usar gramática menos expressiva, será muito mais fácil higienizar o conteúdo.
Aqui o termo Markdown é usado - "marcação fácil de ler" em vez do termo Markup - marcação comum. A idéia principal do Markdown é que ele foi projetado como uma linguagem que, por exemplo, permite que os usuários publiquem comentários, mas não contém a capacidade de usar uma tag vazia, suporte a applet e similares. Portanto, no Markdown, na verdade, é muito mais fácil identificar exclusivamente a gramática e aplicá-la.
A desinfecção é muito mais fácil em uma linguagem simples do que em HTML, CSS e JavaScript completos. E de certa forma, isso é como a diferença entre entender o código C e o código Python. Realmente há uma grande diferença na compreensão de uma linguagem mais expressiva. Portanto, limitando a expressividade, você geralmente melhora a segurança.
Para se proteger contra ataques de script entre sites, também é usado o CSP, Content Security Policy. A idéia do CSP é que ele permita que o servidor web ...
Público: estou curioso para saber mais sobre essa linguagem do Markdown. Todos os navegadores são capazes de executar a análise de idiomas?
Professor: não, não, não. Você pode simplesmente converter vários tipos de idiomas em HTML, mas os navegadores não os entendem em sua forma original. Em outras palavras, você tem um sistema de comentários e ele usa Markdown. Ou seja, os comentários, antes de serem exibidos na página, vão para o compilador Markdown, que os converte para o formato HTML.
Público: então por que nem sempre usar o Markdown?
Professor: O Markdown permite que você use HTML incorporado e, até onde eu sei, existe uma maneira de desativá-lo no compilador. Mas eu posso estar errado sobre isso. O fato é que nem sempre é possível usar um idioma limitado, e nem todo mundo quer fazer isso.
Então, vamos continuar a discussão sobre como aumentar a segurança com a ajuda da Política de Segurança de Conteúdo. Essa política permite que o servidor informe ao navegador da web que tipos de conteúdo podem ser carregados na página que ele envia de volta, e de onde esse conteúdo deve vir.
Por exemplo, na resposta HTTP, o servidor pode usar algo como isto: inclui o cabeçalho Conteúdo - Segurança - Política, a fonte padrão é auto e receberá dados de * .mydomain.com.
Com a própria operadora, o servidor indica que o conteúdo deste site deve vir apenas do domínio de uma página específica ou de qualquer subdomínio de mydomain.com. Isso significa que, se tivéssemos uma ligação automática ao foo.com, o servidor enviaria essa página de volta ao navegador.
Suponha que um ataque de script entre sites tente criar um link para bar.com. Nesse caso, o navegador verá que bar.com não é auto e não é um domínio de meudomínio.com e não ignorará mais essa solicitação. Este é um mecanismo bastante poderoso, onde você pode especificar controles mais detalhados. Você define parâmetros indicando que suas imagens devem provir de tal e qual fonte, scripts de tal e tal e assim por diante. É realmente conveniente.
Além disso, essa política evita o JavaScript incorporado, portanto, você não pode abrir a tag, escrever algum tipo de script e fechar a tag, porque tudo o que pode ser direcionado ao navegador deve vir apenas de uma fonte condicional. O CSP evita coisas perigosas, como usar o argumento para a função eval (), que permite que uma página da Web execute o código JavaScript gerado dinamicamente. Portanto, se o cabeçalho CSP estiver definido, o navegador não executará eval ().
Público: É disso que todo o CSP protege?
Professor: não. Existe uma lista completa de recursos que ele realmente protege, e você pode configurar a proteção contra muitas coisas indesejadas, por exemplo, especificar onde é permitido aceitar CSS de saída e várias outras coisas.
Público: Mas, além de eval (), existem outras coisas que ameaçam a segurança?
Professor: sim, eles existem. Portanto, sempre surge a questão da integridade da proteção. Portanto, por exemplo, eval não só pode gerar dinamicamente o código JavaScript. Há também um construtor de funções, existem certas maneiras de chamar um determinado tempo limite, você acessa a linha e pode analisar o código dessa maneira. O CSP pode desativar todos esses vetores de ataque perigosos. Mas isso não é uma panacéia para o isolamento completo de explorações maliciosas.
Público: É verdade que o CSP pode ser configurado para impedir que todos os scripts internos sejam verificados na página?
Professor: sim, ajuda a impedir a execução de código gerado dinamicamente, enquanto o código incorporado deve ser ignorado. O navegador sempre deve obter o código do atributo de origem. Na verdade, não sei se todos os navegadores fazem isso. A experiência pessoal mostra que os navegadores exibem comportamentos diferentes.
Em geral, a segurança da Internet é semelhante às ciências naturais, então as pessoas apenas apresentam teorias sobre como os navegadores funcionam. E então você vê como isso realmente acontece. E a imagem real pode decepcionar, porque somos ensinados que existem algoritmos, evidências e coisas do gênero. Mas esses navegadores se comportam tão mal que os resultados de seu trabalho são imprevisíveis.
Os desenvolvedores de navegadores tentam estar um passo à frente dos invasores e, mais adiante, na palestra, você verá exemplos disso. De fato, o CSP é uma coisa bem legal.
Outra coisa útil é que o servidor pode definir um cabeçalho HTTP chamado X-Content-Type-Options, cujo valor é nosniff.
Esse cabeçalho impede que o MIME descarte a resposta do tipo de conteúdo anunciado, pois o cabeçalho diz ao navegador para não substituir o tipo de conteúdo da resposta. Com a opção nosniff, se o servidor disser que o conteúdo é text / html, o navegador exibirá como texto / html.
Simplificando, esse cabeçalho evita que o navegador “cheire” a resposta do tipo de conteúdo declarado, para que a situação não aconteça quando o navegador diz: “sim, cheirei uma incompatibilidade entre a extensão do arquivo e o conteúdo real, então vou transformá-lo em outro entendimento. me uma coisa. " Acontece que você de repente deu aos bárbaros as chaves do reino.
Portanto, ao definir esse cabeçalho, você está dizendo ao navegador para não fazer nada assim. Isso pode atenuar bastante os efeitos de certos tipos de ataques. Aqui está uma breve visão geral de algumas vulnerabilidades para ataques de script entre sites.
Agora, vejamos outro vetor de ataque popular - SQL. Você provavelmente já ouviu falar de ataques chamados "injeção de SQL" ou ataque de injeção de SQL. A essência desses ataques é usar o banco de dados do site. Para criar dinamicamente a página mostrada ao usuário, são emitidas consultas ao banco de dados emitidas para esse servidor interno. Imagine que você tenha uma solicitação para selecionar todos os valores de uma tabela específica, em que o campo ID do usuário seja igual ao determinado na Internet a partir de uma fonte potencialmente não confiável.
Todos sabemos como essa história terminará - terminará muito mal, não haverá sobreviventes. Porque o que vem de uma fonte não verificada pode causar muitos problemas. Como alternativa, você pode atribuir à cadeia de caracteres do ID do usuário o seguinte valor: user id = “0; EXCLUIR A TABELA “.
Então o que vai acontecer aqui? Basicamente, o banco de dados do servidor dirá: “OK, definirei o ID do usuário como zero e executarei o comando“ excluir tabela ”.” E é isso, você está pronto!
Eles dizem que há alguns anos uma certa imagem viral apareceu. Algumas pessoas na Alemanha instalaram placas nos carros, nas quais 0 foi escrito; EXCLUIR TABELA. A idéia era que as câmeras viárias usassem o OCR para reconhecer seu número e depois colocassem esse número no banco de dados. Em geral, o pessoal da Volkswagen decidiu explorar essa vulnerabilidade colocando códigos maliciosos em seus números.
Não sei se funcionou porque parece engraçado. Mas eu gostaria de acreditar que isso é verdade. Então, repito: a idéia de desinfecção é impedir a execução de conteúdo de fontes não confiáveis no seu site.
Portanto, preste atenção ao fato de que pode haver algumas coisas simples que não funcionam como deveriam. Então, você pode pensar: “bem, por que não posso simplesmente colocar outra citação no início da linha e mais uma no final para excluir a execução de código malicioso do atacante entre aspas triplas”?
ID do usuário = '"+ ID do usuário +'"
Mas isso não funcionará, porque um invasor sempre pode simplesmente colocar aspas dentro da cadeia de ataque. Portanto, na maioria dos casos, esse "meio hacking" não oferece a segurança que você espera.
A solução aqui é que você precisa criptografar cuidadosamente seus dados. E mais uma vez repito que, quando você receber informações de uma fonte não confiável, não as insira no sistema da forma em que estão. Certifique-se de que ele não pode sair da caixa de areia se você a colocar lá para executar uma exploração maliciosa.
Por exemplo, você deseja inserir uma função de escape para impedir o uso do operador de vírgula bruta. Para fazer isso, muitas das estruturas da web, como o Django, possuem bibliotecas internas que permitem evitar consultas SQL para impedir que essas coisas aconteçam. Essas estruturas incentivam os desenvolvedores a nunca interagirem diretamente com o banco de dados. Por exemplo, o próprio Django fornece uma interface de alto nível que o desinfeta.
Mas as pessoas sempre se preocupam com o desempenho e, às vezes, pensam que essas estruturas da web são muito lentas. Portanto, como você verá em breve, as pessoas ainda farão consultas SQL brutas, o que pode levar a problemas.
Podem ocorrer problemas se o servidor da web aceitar nomes de caminhos de imagens não confiáveis. Imagine que em algum lugar do seu servidor você esteja fazendo algo semelhante: abra com “www / images /” + filename, em que filename é representado por algo como ... / ... / ... / ... / etc / senha.
Ou seja, você dá o comando para abrir a imagem neste endereço a partir de um arquivo de usuário não confiável, o que, na realidade, pode prejudicá-lo seriamente. Portanto, se você quiser usar um servidor ou estrutura da web, poderá detectar esses caracteres perigosos e evitá-los para impedir a execução desses comandos não manipulados.
Vamos parar de discutir a desinfecção de conteúdo e falar um pouco sobre cookies. Os cookies são uma maneira muito popular de gerenciar sessões para vincular um usuário a um determinado conjunto de recursos que existem no lado do servidor. Muitas estruturas, como Django ou Zoobar, que você encontrará mais tarde, na verdade colocam um identificador de sessão aleatória dentro dos cookies. A ideia é que esse ID de sessão seja um índice em algum tipo de tabela do lado do servidor:
tabela [ID da sessão] = informações do usuário.
Ou seja, o identificador da sessão é igual a algumas informações do usuário. Como resultado, esse ID de sessão e cookies são peças muito sensíveis em sua extensão. Muitos ataques incluem roubo de cookies para obter esse ID de sessão. Como discutimos em nossa última palestra, a mesma política da mesma fonte de origem pode ajudá-lo, em certa medida, contra alguns desses ataques de roubo de cookies. Porque existem regras baseadas na mesma política de origem que impedem a modificação arbitrária de cookies.
A sutileza é que você não deve compartilhar um domínio ou subdomínio com alguém em quem não confia. Porque, como dissemos na última palestra, existem regras que permitem que dois domínios ou subdomínios da mesma origem acessem os cookies um do outro. E, portanto, se você confia em um domínio no qual não deve confiar, talvez seja possível definir diretamente o identificador da sessão nesses cookies, aos quais você tem acesso. Isso permitirá que o invasor force o usuário a usar o identificador de sessão de sua escolha.
Suponha que um invasor defina um cookie de usuário do Gmail. Um usuário faz login no Gmail e digita algumas letras. Um invasor pode usar esse cookie, em particular, usar esse identificador de sessão, baixar o Gmail e acessar o Gmail como se fosse um usuário vítima. Portanto, existem muitas sutilezas que você pode fazer com esses cookies para gerenciar suas sessões. Discutiremos alguns deles hoje e em palestras subsequentes.
Talvez você pense que pode se livrar de cookies? Afinal, eles trazem mais problemas do que benefícios. Por que eles não podem ser abandonados?
stateless cookie, « », - , , , .
, , , . , . , , . , , , , .
— MA — Message Authentication Codes, . , . HCK - m. , , K. , , . , , .
, . , stateless cookie, Amazon, , x3. - Amazon, AWS, . – K, – AWS, .
, AWS HTTP, .
, , , :
GET /photos/ cat; .jpg HTTP/1.1, - AWS:
HOST: — - — - — , , :
DATE: Mon, June 4, , , . , ID , , , .
? , 3- .
, String To Sign :
— HTTP, GET;
— MDS;
— , html jpg;
— ;
— , , .
, , HCK MAC. , . , . , . ?
, , , - . Amazon , stateless cookie, MD5 .
, , , cookie, . – , , .
, . , , “HCK, m”.
. GET /photos/ cat; .jpg HTTP/1.1 , , . , , . , ? : «, , , ».
56:15
Curso MIT "Segurança de sistemas de computadores". 9: « Web-», 3A 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?