1 / 36

Programação Segura

Programação Segura. Pontifícia Universidade Católica de Campinas Tópicos em Engenharia Computação B Prof. Edmar Roberto Santana de Rezende Daniel Mome Rafael G. O. Santos Ronaldo R. Nascimento Sílvia R. L. Colella. Sumário. Introdução Motivação Principais Bugs de Segurança

lei
Download Presentation

Programação Segura

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Programação Segura Pontifícia Universidade Católica de Campinas Tópicos em Engenharia Computação B Prof. Edmar Roberto Santana de Rezende Daniel Mome Rafael G. O. Santos Ronaldo R. Nascimento Sílvia R. L. Colella

  2. Sumário • Introdução • Motivação • Principais Bugs de Segurança • Validação dos dados no servidor • Data Tampering • Buffer Overflow • SQL Injection • Script Injection • Cross-Site Scripting • Dicas

  3. Motivação • Por quê?

  4. Motivação • Ataques exploram falhas de segurança • Pequenos bugs podem derrubar sistemas inteiros • Empresas dependem dos sistemas de informação

  5. Motivação • Aumento da qualidade • Relacionada com a ocorrência de erros

  6. Principais Bugs de Segurança

  7. Validação de entrada no cliente e no servidor • Praticamente todo ataque é resultado de alguma entrada enviada pelo atacante. • Programação segura é sobre não permitir que entradas de pessoas com mas intensões causem problemas. • Entradas que levam um comportamento inapropriado do sistema. • Entradas que permitem acesso a informações restritas do seu sistema.

  8. Todo Input é suspeito • Em um ambiente distribuido, não há apenas uma fronteira, mas varias. • Programadores tendende a ver a relação cliente servidor como fazendo parte do sistema e não como algo aberto a ataques • Cliente é realmente o cliente? • O servidor é realmente o servidor? • Até onde se pode confiar? • O que uma ma entrada entrada pode causar? • Espere o Inesperado.

  9. Falha de seguraça no Gmail descoberta em 2006 • Cross-Site Request Forgery • Acesso indevido a lista de contatos • Bastava acessar página maliciosa enquanto logado no Gmail • Na pagina maliciosa : <script src="http://mail.google.com/mail/?_url_scrubbed_"> • Recebia como resposta a lista de contatos.

  10. Data Tampering • Consiste no envio de dados cuidadosamente preparados para serem aceitos pela aplicação mas gerar um efeito colateral não previsto pelo desenvolvedor. • Exemplos típicos envolvem montar comandos na linguagem de script, comandos SQL, comandos JavaScript ou tags HTML que serão executados pela aplicação. • Ou então enviar chaves de registros, comandos da aplicação, identificadores de sessão e outros parâmetros utilizados internamente pela aplicação.

  11. Data Tampering • Principais tipos • Buffer Overflow • Script Injection • SQL Injection • Cross-Site Scripting

  12. Buffer Overflow - Overview • Ocorre quando o tamanho de um buffer ultrapassa sua capacidade de armazenamento • Excesso de dados pode ser armazenado em áreas de memória próximas

  13. Buffer Overflow - Consequências • Travar um sistema • Corromper dados • Executar outros programas

  14. Buffer Overflow - Exemplo

  15. Script Injection • O que é? • Script Injection é a forma de inserir código de script (Javascript por exemplo) ou tags HTML em requisições que vão para o servidor ou em respostas do servidor para o cliente.

  16. Script Injection • Onde fica o perigo? • Se alguma informação fornecida pelo usuário é posteriormente exibido em uma página HTML, o cracker pode inserir dados contendo código malicioso que posteriormente será executado pelo servidor ou pelo próprio browser do cliente.

  17. Script Injection • Desta forma pode-se: • Iludir o usuário, fazendo o pensar que está em outra página • Criar links que fazem o usuário executar uma ação quando pensa estar fazendo outra coisa

  18. Script Injection • Tomar cuidado • Com código Javascript pode-se realizar ações sem depender da iniciativa do usuário. • Várias tags HTML provocam ações imediatas, ex: <img>, <iframe>. • Além de atributos como onLoad, onMouseOver • Se a linguagem de script do servidor suportar avaliação de expressões em texto (a maioria suporta) é possível inserir código a ser executado no próprio servidor que hospeda a aplicação, e não no navegador do usuário.

  19. Script Injection • Como se defender • Elimine do texto digitado pelo usuário tudo o que se parecer com tags HTML e comandos de Script. • Antes de exibir em uma página qualquer informação obtida de uma fonte externa, valide a informação para eliminar o significado especial de símbolos como < & $ ;` . • Considere como fontes externas não apenas os campos digitados pelo usuário, mas também cookies, variáveis de ambiente, arquivos anexados, campos de banco de dados e etc.

  20. SQL Injection • SQL Injection é uma das formas mais conhecidas de se fazer ataques em sistemas. Principalmente em sistemas WEB. • É a forma de inserir comandos SQL ou de alterá-los, em ataques, através de campos de formulários, para realizar operações em banco de dados.

  21. SQL Injection • Onde fica o perigo? • Muitos programadores constroem comandos SQL (no desenvolvimento de sistemas) utilizando concatenação de strings. • A maioria dos bancos de dados é capaz de receber um lote de comandos em uma única mensagem e executar a todos. • Desta forma, o cracker pode modificar os comandos SQL da aplicação e fazer praticamente qualquer coisa.

  22. SQL Injection • Exemplo código vulnerável

  23. SQL Injection • Solução

  24. SQL Injection • Principais strings de ataque:

  25. SQL Injection • Dicas • Sempre faça a validação das entradas do usuário, restringindo determinados caracteres. • As conexões que o usuário estabelece através da aplicação devem possuir restrições, deve permitir somente operações que realmente podem ser realizadas por este usuário.

  26. SQL Injection • Nunca culpe o usuário

  27. Cross-Site Scripting (XSS) • Ocorre quando um invasor usa uma aplicação Web para enviar código malicioso, geralmente na forma de um script, para um outro usuário final. • Acontece sempre que uma aplicação Web utiliza a entrada do usuário sem validá-la. • O navegador não tem como saber se vem de uma fonte confiável ou não => ele assume e confia no usuário fonte, permitindo que o script seja executado.

  28. Cross-Site Scripting (XSS) • O script malicioso pode ter acesso a qualquer cookie, tokens de sessão ou outra informação sensível retida no navegador web e usada naquele site. • Estes scripts podem até mesmo rescrever o conteúdo da página HTML. • Uma única aplicação na Intranet que contenha o bug pode ser utilizada como meio de inserir esse código malicioso!

  29. Ataques XSS • Ataques XSS podem geralmente ser classificados em duas categorias: Armazenamento e Reflexão. • Ataques de armazenamento: o código injetado fica permanentemente armazenado nos servidores alvo (um banco de dados, em mensagem de fórum, log de visitantes, campos de comentário, etc.) • A vítima então recupera o script malicioso do servidor quando requisita a informação armazenada.

  30. Ataques XSS • Ataques de reflexão: o código injetado é refletido pelo servidor web, por meio de uma mensagem de erro, resultado de procura ou qualquer outra resposta que inclua alguma ou toda entrada enviada para o servidor como parte da requisição. • Ataques de reflexão são enviados para as vítimas através de outra rota, com por meio de mensagem de correio eletrônico ou algum outro servidor Web. • Quando um usuário é ludibriado a clicar em um link malicioso ou submeter um formulário especialmente manipulado, o código injetado viaja para o servidor Web vulnerável, que reflete o ataque de volta para o usuário do navegador. O navegador então executa o código pois ele vem de um servidor confiável.

  31. XSS – Consequências dos Ataques • XSS pode causar uma variedade de problemas para o usuário final com uma extensão de severidades desde de aborrecimento até o comprometimento completo da conta. • A maioria dos ataques severos de XSS envolve a exposição do cookie de seção do usuário, permitindo ao invasor sequestrar a sessão do usuário e se apoderar da conta. • Outros ataques danosos incluem a exposição de arquivos do usuário, um invasor modificar um press release ou uma notícia que pode afetar as ações de uma companhia ou diminuir a confiança do consumidor.

  32. XSS – Como se proteger • Garantir que a aplicação realize validação de todos os cabeçalhos, cookies, strings de consulta, campos de formulário e campos escondidos (i.e., todos os parametros) contra uma rigorosa especificação do que pode ser permitido. • Codificar a saída fornecida pelo usuário pode ajudar a derrotar as vulnerabilidades XSS previnindo scripts inseridos de serem transmitidos para usuários em formato executável. • Política de Segurança ‘Positiva‘: especifica o que é permitido. • 'Negativa' ou política de segurança baseada em assinaturas são difíceis de manter e possivelmente incompletas.

  33. Dicas de Programação Segura • Projete o programa com cuidado antes de começar. Esteja certo de que está entendendo o que você está programando. Considere o ambiente no qual ele será executado: • o comportamento de entradas e de saídas, • os arquivos usados, • os argumentos reconhecidos, • os erros encontrados nas validações –> Importante! Tente listar todos os erros que podem ocorrer e como irá lidar com eles.

  34. Dicas de Programação Segura • Documente o programa antes de começar a codificá-lo. Escreva no papel a teoria das operações do código, descrevendo o que fazer e como ele vai fazer. Destaque os módulos mais complexos. • Importante! Revise o documento enquanto codifica. • Se não puder / fizer, considere escrever um manual completo – será então possível preservar o foco no código e no que ele deve fazer. • Faça com que a parte crítica do seu problema fique com o menor tamanho possível.

  35. Dicas de Programação Segura • Pense antes de adicionar novas funcionalidades simplesmente porque pode. Adicione somente quando tem necessidade. Quanto menor o tamanho do seu código, menor a possibilidade de introduzir bugs e mais você entende como o código realmente funciona. • Tente nao reescrever funções de biblioteca padrão. Embora tenham sido encontrados bugs em funções de biblioteca padrão, é mais provável que você introduza bugs novos e ainda mais perigosos. • Cuidado com condições de corrida. Elas podem se transformar em deadlock ou em uma falha quando duas chamadas são executadas uma perto da outra.

  36. Fim

More Related