Programação Segura

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