Aplicações Web ‐ Seu site está seguro?

Segurança de aplicações Web

Alex Hübner, CFUG-SPalex@cfugsp.com.br

2

O que são aplicações web?

Softwares (sites) na arquitetura cliente/servidor em protocolo HTTP

Cliente universal: o browser (IE/Netscape)

Servidor: vários sabores e soluções Dividido em 3 camadas:

Apresentação Aplicação Dados e armazenamento

3

O que são aplicações web?

Fonte: The Open Web Applications Security Project – http://www.owasp.org

4

O que são aplicações web?

Exemplos de aplicações web: CNN.com, Internet Banking, Previsão

do Tempo, Google e Yahoo!, Intranets, extranets, invente uma!

Não confunda aplicações web com produtos específicos (ex: Apache, IIS, JSP, PHP, ColdFusion, Windows 2000 Server, SQL Server, MySQL etc).

5

O que são webservices?

Softwares arquitetura aplicação/aplicação em protocolo SOAP (XML sobre HTTP)

Cliente: outras aplicações web

Servidor: vários sabores e soluções

Apenas duas camadas: Aplicação Dados e armazenamento

6

Segurança de aplicações web

Algumas afirmações paradoxais tiradas de listas de discussão na web: “Não existe sistema operacional ou

aplicação insegura, existem administradores inseguros...”

“Os bons admistradores são bons pois precisam lidar com aplicações e sistemas que se parecem com queijos suíços...”

Má notícia: ambas são verdadeiras!

7

Risco, ameaça e vulnerabilidade

Vulnerabilidade → Ameaça → Risco Risco:

“A possibilidade de sofrer dano, perda”

Ameaça:“Um risco eminente, provável, factível”

Vulnerabilidade:“Estar suscetível a uma ameaça”

8

Avaliando os Riscos

Não existe uma métrica quantitativa exata Quanto a Microsoft perderia com o site

invadido? Quanto o “Toninho’s Armazém Online”

perderia com o site invadido?

Conheça o negócio do cliente

Avalie as vulnerabilidades, ameaças e riscos inerentes

9

Avaliando os Riscos

Pergunte-se: As ameaças são internas (funcionários) ou

externas (visitantes)? Cuidado, o mordomo é sempre suspeito!

Quais são as motivações para um ataque ao site/aplicação (pessoais, financeiras, diversão)?

Qual será o impacto financeiro se o site/aplicação estiver fora do ar em conseqüência destes ataques (ex: loja virtual)?

Qual será o impacto na imagem e reputação do negócio como um todo?

Você é odiado por alguém?

10

Avaliando os Riscos

Decida-se e defina: Quanto gastar com a proteção?

Provedor de hospedagem de qualidade comprovada (+ caro), arquitetura utilizada, firewall, IDS, logs detalhados, código meticulosamente preparado e testado (+ tempo de codificação) etc.

Quem são os responsáveis pela proteção?

O desenvolvedor/programador (webmaster)?O provedor de hospedagem?O cliente?

11

Avaliando os Riscos

Avaliar riscos é uma arte, consultores abastados que o digam!

Use o bom senso na sua avaliação Não gaste milhões para proteger

centavos Uma aplicação 100% segura é 100%

impraticável

O segredo é ser paranóico na medida certa, comece com o seu próprio código

12

Onde usar a paranóia?

Onde uma aplicação web é mais vulnerável? Camada de Apresentação

HTML/formulários/input e output de dados de e para o cliente. Servidores web IIS, Apache. Browsers, pluggins, seu código

Camada de AplicaçãoSevidores de aplicação ASP, TomCat, IBM

WebSphere, ColdFusion, seu código

Ambas são responsabilidades do desenvolvedor

13

Aplicações web: riscos e vulnerabilidades

“Optei por um plano de hospedagem Linux com PHP e MySQL porque é bem mais seguro que hospedar num plano Windows com ASP e SQL Server...”

Historinha para boi dormir...

14

Aplicações web: riscos e vulnerabilidades

“Agora posso dormir tranqüilo, meu site está rodando atrás de um firewall muito potente e calibrado. Atrás dele eu ainda tenho um IDS (intrusion detection system) de última geração, que custou 30 mil dolares...”

Cliente satisfeito é outra coisa...

15

Aplicações web: riscos e vulnerabilidades

Para quê firewall e IDS mais moderno e eficiente do mercado? O seu site roda na porta 1589?

Esqueça aquela “distro” Linux ultra segura e complicada que você comprou na banca de jornal. Não sabendo usá-la, ela será mais perigosa que o Windows 95 como servidor de hospedagem

“Ignore” os patches do Windows 2000 Server. Sua aplicação vai ser mais segura só por que a Microsoft corrigiu a rebinboca da parafuseta do sistema de autenticação XYZ do protocolo IPXext?

16

Aplicações web: riscos e vulnerabilidades

Preocupe-se primeiro com o código de sua aplicação. Ele é, em última instância, o que você expõe ao público geral e também às figurinhas do mundo underground da internet (script kiddies)

Enquanto você perde seu tempo olhando os fundos da casa, o ladrão está entrando pela porta da frente (vamos chamá-la de porta 80), que ficou aberta e desprotegida

Um número absurdo de aplicações e sites na web possuem algum tipo de vulnerabilidade relacionadas à má codificação ou arquitetura ruim, não seja o criador de um deles

17

Aplicações web: riscos e vulnerabilidades

Como vão os formulários, parâmetros URL, queries SQL e cookies do seu site?

Você sabia que sua base de dados pode ser totalmente deletada ou alterada (o que é pior), através de um simples campo de “preencha seu nome”?

Sabia que usuários malandros podem se passar por usuários legítimos apenas colocando um cookie editado no browser deles?

18

Aplicações web: riscos e vulnerabilidades

70%* das invasões de sites e aplicações web começam ou se dão totalmente

através da má codificação das mesmas

* The Open Web Applications Security Project – http://www.owasp.org

19

Aplicações web: riscos e vulnerabilidades

“Este site é 100% seguro, usamos criptografia de 128 bits, você pode perceber isso clicando no “cadeado fechado” na barra de status do seu browser...”

Onze entre dez sites de comércio eletrônico...

20

Alguns exemplos

Parâmetros inválidos | teoria Informações enviadas pelo usuário

não são devidamente validadas e checadas quando recebidas e tratadas pela aplicação/site Manipulação de campos de FORM Manipulação de cookies Manipulação de parâmetros URL Manipulação de headers HTTP

21

Alguns exemplos

Parâmetros inválidos | exemplo http://www.site.com.br/cesta/fecha_pedido.php?

IDproduto=12&valor=7763 (o produto custa isso mesmo?)

<form action=“fecha_pedido.php” method=“post”><input type=“hidden” name=“IDproduto” value=“12”><input type=“hidden” name=“valor” value=“7763”></form>

Cookie: lang=pt-br; ADMIN=no; y=1 ; time=10:30GMTCookie: lang=pt-br; ADMIN=yes; y=1 ; time=12:30GMT(o usuário é mesmo um administrador?)

22

Alguns exemplos

Controle de acesso falho | teoria Controle de acesso a uma

aplicação/site ruim e falho e pode ser burlado Profusão de sistemas e métodos de

autenticação facilitam muito Inconsistent and Past Control Checks:

pastas internas não protegidas como deveriam

Inconsistência de credenciais/IDs inseguros Path traversal Permissão de arquivos Cache de browser não limpo

23

Alguns exemplos

Controle de acesso falho | exemplo http://www.site.com.br/admin/ (ok)

http://www.site.com.br/admin/modulox (?)http://www.site.com.br/admin/moduloy/action.asp (?)

http://www.site.com.br/adm/pegar_arquivo.cfm?arquivo=../../../winnt/system32/certmgr.reg

http://www.site.com.br/adm/upload_arquivo.cfm?arquivo=iislog_safado.dll&destino=../../../winnt/system32/inetserv/isslog.dll

24

Alguns exemplos

Quebra de autenticação | teoria O usuário é capaz de burlar o sistema

de autenticação do site/aplicação Esqueceu a senha? Redefinição de senha Sequestro de sessão (tokens e cookies) Relações de confiança entre o front-end e o

back-end (banco de dados, LDAP, email etc) muito alta comprometendo todas as outras aplicações do servidor

25

Alguns exemplos

Quebra de autenticação | exemplo

SELECT username, senha

FROM tb_usuarios

WHERE usuario=‘$INPUT[usr]’

AND senha=‘$INPUT[pwd]’

26

Alguns exemplos

Cross-site Scripting | teoria Ataque que usa uma aplicação web

para atingir um outro visitante/usuário Stored Reflected

É uma das vulnerabilidades mais exploradas em aplicações web

27

Alguns exemplos

Cross-site Scripting | exemplo

Campo de comentário (stored)

Campo “envie esta notícia por e-mail” (reflected)

28

Alguns exemplos

Buffer Overflows | teoria Depentendes do servidor de

aplicação Difíceis de explorar, porém muito

divulgados Podem ser evitados ou minimizados

com o auxílio de filtragem de dados inseridos pelo usuário

29

Alguns exemplos

Buffer Overflows | exemplo

30

Alguns exemplos

Command/SQL Injection | teoria Informações (parâmetros dinâmicos)

enviadas para construção de queries e interações com o banco de dados não são devidamente validadas e checadas quando recebidas e tratadas pela aplicação/site ou pelo banco de dados Bastante comum Muitos programadores a ignoram

completamente Grande risco

31

Alguns exemplos

Command/SQL Injection | exemplo http://www.site.com/noticia.cfm?

id=122 <cfquery name=“qNoticias”

datasource=“bancoDeNoticias”>SELECT * FROM noticiasWHERE id=#url.id#</cfquery>

http://www.site.com.br/noticias.cfm?id=122;DROP TABLE noticias(tem certeza de que quer deletar a tabela de notícias?)

32

Alguns exemplos

Tratamento de erros | teoria Informações ou operações que gerem

erros no site/aplicação não são devidamente tratados e informados ao usuário de forma crua e sem cuidado

Muitos servidores de aplicação (ASP, PHP, ColdFusion) possuem mensagens de erro em formato debug, “informando” muita coisa útil para quem tem más intenções

Desabilite-as, trate os erros (try/catch)!

33

Alguns exemplos

Tratamento de erros | exemplo

O usuário precisa saber de tudo isso?

34

Alguns exemplos

Erro no uso de criptografia | teoria Ocorre quando o

webmaster/programador não entende onde e como deve fazer uso de criptografia (SSL, por exemplo) em suas aplicações Envio de senha e informações sensíveis

para só depois criptografar a página/resultado

Forwards estúpidos Acreditar que usando 128bits está

“protegido”, lembre-se de todos os outros exemplos!

35

Alguns exemplos

Erro no uso de criptografia | exemplo

HTTP HTTP HTTPS(login) (autenticação) (aplicação)

“Este site é 100% seguro, usamos criptografia de 128 bits, você pode perceber isso clicando no “cadeado fechado” na barra de status do seu browser...”

36

Alguns exemplos

Administração remota | teoria Quanto menor o número de

“ferramentas” disponíveis para uma invasão, melhor Não deixe o IISAdmin, ColdFusion

Administrator, MyPHPAdmin etc disponíveis nas suas posições padrões. Proteja-os!

Remova qualquer aplicação de exemplos ou documentação sobre o que você têm instalado

Limite ao máximo quem e como as interfaces de administração remota são acessíveis (IPs autorizados, por exemplo)

37

Alguns exemplos

Administração remota | exemplo

Um prato cheio... Com 5 horas de

brute-force foi possível invadir uma interface de administração remota como esta

Estamos apenas a um mísero “password field” de distância de obter controle total do servidor e aplicações contidas nele

Esconda tudo que puder!

38

Alguns exemplos

Má configuração do servidor | teoria Quando um servidor ou software necessário

para rodar uma aplicação é mal administrado ou mal configurado IIS sem patches de correção Apache 1.3 em Windows (inseguro) Sistema Operacional “caixa preta” Etc! Responsabilidade do administrador de sistemas

e do programador em conhecer o ambiente em que trabalha e certificar-se de que ele está devidamente configurado para uma maior segurança

39

Moral da história

Conheça, planeje e controle os riscos de manter sua aplicação pública (disponível na web)

Cuide primeiro da porta de entrada, depois dos fundos

Ao revisar seu código, use o boné do vândalo, e tente quebrar sua aplicação pela porta da frente

Sempre valide toda e qualquer entrada e saída de dados da sua aplicação (forms, url, etc)

Use e abuse de soluções/scripts prontos Use a cabeça e seja malvado na hora de

escrever códigos Estude e participe de listas de discussão sobre

o assunto

40

Perguntas e respostas

?

41

Referência básica sobre o assunto

The Open Web Application Security Project http://www.owasp.org