Programação SeguraPontifícia Universidade Católica de Campinas

Tópicos em Engenharia Computação B Prof. Edmar Roberto Santana de Rezende

Daniel MomeRafael G. O. SantosRonaldo R. NascimentoSílvia R. L. Colella

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

Motivação

•Por quê?

Motivação

• Ataques exploram falhas de segurança

• Pequenos bugs podem derrubar sistemas inteiros

• Empresas dependem dos sistemas de informação

Motivação

• Aumento da qualidade– Relacionada com a ocorrência de erros

Principais Bugs de Segurança

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.

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.

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.

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.

Data Tampering

• Principais tipos

• Buffer Overflow

• Script Injection

• SQL Injection

• Cross-Site Scripting

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

Buffer Overflow - Consequências

• Travar um sistema

• Corromper dados

• Executar outros programas

Buffer Overflow - Exemplo

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.

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.

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

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.

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.

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.

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.

SQL Injection

• Exemplo código vulnerável

SQL Injection• Solução

SQL Injection

• Principais strings de ataque:

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.

SQL Injection

• Nunca culpe o usuário

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.

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!

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.

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.

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.

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.

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.

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.

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.

Fim