Pontifícia Universidade Católica de Campinas

Apresentação em tema: "Pontifícia Universidade Católica de Campinas"— Transcrição da apresentação:

1 Pontifícia Universidade Católica de Campinas
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 Dicas
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=" 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