Prof. Roberto Franciscatto 4º Semestre - TSI - CAFW. Free Powerpoint Templates Page 1

Transcrição

1 Segurança na Web Capítulo 9: Segurança em Aplicações Web Prof. Roberto Franciscatto 4º Semestre - TSI - CAFW Page 1

2 Introdução Quando se fala em segurança na WEB é preciso pensar inicialmente em duas frentes: Aplicações Web (Sites, portais,...) Desenvolvimento seguro Servidor da aplicação Administrador de serviços de hospedagem Servidor web seguro Page 2

3 Introdução Existem diversas vulnerabilidades conhecidas, a sua grande maioria é de domínio público, facilmente encontradas na Internet. Muitos sites possuem material que ensinam como explorar estas falhas. O próprio google é uma fonte rica de informações que vão além de uma simples busca... Page 3

4 Vulnerabilidades Cross Site Scripting (XSS) Permite ao atacante executar scripts no navegador da vítima (roubar sessões, executar arquivos,...) Falhas de Injeção (SQL Injection) Manipulação/inserção de código sql, com inuitio de enganar o interpretador Execução maliciosa de arquivos Códigos vulneráveis a inclusão remota de arquivos (RFI) Page 4

5 Vulnerabilidades Referência insegura direta a objetos Expor a referência a um objeto implementado internamente (arquivos, diretórios, chaves,...) Cross Site Request Forgery (CSRF) execução de ações maliciosas em prol do atacante (comprometimento aplicação e servidor) Vazamento de informações e tratamento de erros inapropriado tratamento de erros de forma inapropriada Page 5

6 Vulnerabilidades Autenticação falha e Gerenciamento de Sessão Assumir a identidade de outros usuários Armazenamento criptográfico inseguro roubo na utilização inapropriada de métodos criptográficos Comunicações inseguras redes sem criptografia no comunicação cliente/servidor Falha de Restrição de acesso à URL Acesso direto a URLs e manipulação das mesmas Page 6

7 Vulnerabilidades (TOP 10) Page 7

8 Page 8

9 Cross-site Scripting; SQL Injection; Inclusão de valores em variáveis internas; Exposição de informações do servidor (mensagens de erro); Exposição de arquivos do sistema e outros do servidor; Execução de programas no servidor. Page 9

10 Existem diversas outras regras e funções que devem ser desabilitadas em servidores para uma maior segurança. Page 10

11 Cross Site Scripting PHP pode aceitar URLs via URL Wrapper. Deve ser desabilitada por padrão Uma das piores brechas de segurança que um código PHP pode possuir. Page 11

12 Cross Site Scripting Possibilita que qualquer um, remotamente, possa ler quaisquer arquivos do sistema que o processo do servidor web tenha permissão. além de poder executar qualquer script PHP no servidor onde o código esta hospedado. Page 12

13 Exemplo: Cross Site Scripting <?php // Inclui o cabeçalho da página: include ( cabecalho.php ); // Inclui a página requisitada: include ( $pagina); // Inclui o rodapé da página: include ( rodape.php );?> //codigo1.php Page 13

14 Exemplo: Cross Site Scripting Externamente, pode-se explorar este código de diversas formas. Uma delas, com a opção de URL Wrapper habilitada no servidor, é possível que seja executado código externo ao servidor como se fosse local. Page 14

15 Exemplo: Cross Site Scripting Para isto, basta acessar o código da seguinte forma: nseguro.com.br/cod_externo.txt Page 15

16 Exemplo: Cross Site Scripting Outra vulnerabilidade associada a utilização deste comando como descrito acima (mesmo com o URL Wrapper desabilitado) é a leitura de qualquer arquivo que o servidor tenha permissão de leitura. Page 16

17 Exemplo: Cross Site Scripting Por exemplo, o arquivo de senhas de um servidor Unix pode ser lido da seguinte forma: Page 17

18 Exemplo: Cross Site Scripting Esta vulnerabilidade pode ser facilmente corrigida utilizando o comando basename() na variável, reescrevendo o código para: <?php // Inclui o cabeçalho da página: include ( cabecalho.php ); // Inclui a página requisitada: include ( basename ( $pagina)); // Inclui o rodapé da página: include ( rodape.php );?> //codigo2.php Page 18

19 Exemplo: Cross Site Scripting Outra conseqüência deste comando é a de que mesmo restringindo-se para que não seja passado nenhum parâmetro com diretório, ainda permite a visualização/execução de scripts e arquivos textos do diretório atual. Page 19

20 Exemplo: Cross Site Scripting A forma mais correta e segura de se utilizar um include de arquivos para uma determinada variável é utilizando o comando switch(). Page 20

21 Exemplo: Cross Site Scripting <?php // Inclui o cabeçalho da página: include ( cabecalho.php ); // Inclui a página requisitada: switch ( $pagina) { case inicial : include inicial.php ; break; case contato : include contato.php ; break; case clientes : include clientes.php ; break; default: echo A página requisitada não pode ser encontrada. ; break; } // Inclui o rodapé da pagina: include ( rodape.php );?> //codigo3.php Page 21

22 Exemplo: Cross Site Scripting A desativação da funcionalidade de URL Wrapper no PHP atinge diversos comandos, ou todos que aceitem um nome de arquivo como parâmetro para processá-los. Entre estes, estão: include(), include_once(), require(), require_once(), fopen(), readfile(), file(), file_get_contents(), Page 22

23 SQL Injection Afeta praticamente todas as linguagens de programação que acessam banco de dados Esta vulnerabilidade, permite que um usuário que acesse um código que contenha uma requisição a um banco de dados SQL, insira quaisquer comando nesta requisição. Page 23

24 Exemplo: SQL Injection // Verifica autenticação do usuário: if (! $result ( SELECT * FROM usuarios WHERE USER = '$usuario' AND PASS = '$senha', $ID)) { die ( Erro: Não foi possível realizar a pesquisa no banco de dados. ); } //codigo5.php Page 24

25 Exemplo: SQL Injection Através do código acima, podemos explorar o mesmo de diversas maneiras. Como por exemplo: Page 25

26 Exemplo: SQL Injection Isto fará com que a string de requisição ao banco de dados seja alterada para: SELECT * FROM usuarios WHERE USER = 'admin';' AND PASS = Pode-se realizar outras requisições, inclusive destrutivas na base de dados, como por exemplo: TABLE usuarios; Page 26

27 Exemplo: SQL Injection Solução??? Utilizar a função addslashes() Alguns servidores PHP já possuem métodos que se aplicam a tradução de caracteres vulneráveis a SQL Injection ou criar uma função em PHP, para verificar isso... Page 27

28 Exemplo: SQL Injection <?php // Adicionamos uma função para verificar se o servidor // executou addslashes() de forma // transparente, senão executamos: function checkslashes ( $valor) { if (! get_magic_quotes_gpc ()) { return addslashes ( $valor); } else { return $valor; } }?> //função para verificar addslashes - codigo6.php Page 28

29 Exemplo: SQL Injection // Verifica autenticação do usuário: if (! $result ( SELECT * FROM usuarios WHERE USER = '. checkslashes ( $usuario). ' AND PASS = '. checkslashes ( $senha). ', $ID)) { die ( Erro: Não foi possível realizar a pesquisa no banco de dados. ); } //código sem vulnerabilidade de SQL Injection - codigo7.php Page 29

30 Inclusão de valores em variáveis internas Uma vulnerabilidade pouco explorada, porém com um grande potencial Esta vulnerabilidade consiste: na inclusão de uma variável com um valor determinado pelo cliente, fazendo com que o sistema quando utilize esta variável assuma o valor informado pelo mesmo. Page 30

31 <?php if ( $usuario == teste && $senha == senhateste ) { $autenticado = true; } if ( $autenticado) { switch ( $acao) { case exclui : exclui_usuario (); break; case adiciona : adiciona_usuario (); break; default: echo Erro: Comando desconhecido. ; break; } }?> //codigo vulnerável a valores externos - codigo8.php Page 31

32 Inclusão de valores em variáveis internas Podemos burlar a autenticação acima utilizando: Page 32

33 Inclusão de valores em variáveis internas A melhor solução para este caso é se desabilitar a funcionalidade de register_globals do servidor, e acessar as informações de variáveis enviadas por clientes de uma forma segura. Podemos verificar esta opção com o comando ini_get ( register_globals ), como segue o exemplo: Page 33

34 Inclusão de valores em variáveis internas <?php // Verifica se a funcionabilidade register_globals está //desabilitada (mais seguro): if ( ini_get ( register_globals ) == true) { die ( Erro: Este script não pode ser executado de forma insegura. Desative a funcionalidade 'register_globals' no servidor. ); } //código segura a valores externos codigo9.php Page 34

35 Exposição de informações do servidor - (mensagens de erro) Diversas informações sobre os scripts e sobre a estrutura na qual foi configurado o servidor podem ser visualizadas através de simples mensagens de erro, fornecendo informações importantes para um indivíduo que está tentando explorar alguma vulnerabilidade. Além das mensagens de erro estarem em inglês, elas podem deixar o site com uma aparência amadora, por não tratar os seus erros. Page 35

36 Exposição de informações do servidor - (mensagens de erro) Você pode utilizar o (arroba) antes dos comandos, para evitar que caso o mesmo retorne um erro, este seja apresentado ao cliente. Segue um exemplo de código mostrando erro: <?php $id = mysql_connect ( localhost, usuarioinvalido, senha );?> //codigo sem tratamento de erros codigo10.php Page 36

37 Exposição de informações do servidor - (mensagens de erro) O código acima, contendo um usuário inválido, retornaria a seguinte mensagem de erro: Warning: mysql_connect(): Can't connect to local MySQL server through socket '/var/run/mysql.sock' (2) in /srv/http/ on line 2 Este erro, além de ser ilegível para um usuário leigo, disponibiliza informações sobre a área onde o script está sendo hospedado no servidor, assim como estrutura interna do mesmo. Page 37

38 Exposição de informações do servidor - (mensagens de erro) Podemos utilizar de forma simples, rápida e limpa o mesmo código: <?php if (! $id ( localhost, usuarioinvalido, senha )) { } die ( Desculpe-nos, ocorreu um erro interno no sistema. Tente novamente mais tarde. Se o problema persistir, entre em contato com o administrador do sistema. );?> //código com tratamento de erro código 11 Page 38

39 Exposição de arquivos do sistema e outros do servidor Outra vulnerabilidade que comumente é esquecida pelos administradores dos servidores de hospedagem é o fato de que o PHP pode visualizar todos os arquivos do sistema incluindo arquivos de configuração, senhas, scripts de outros clientes, etc... Page 39

40 Exposição de arquivos do sistema e outros do servidor Esta vulnerabilidade pode e deve ser bloqueada para cada domínio hospedado no servidor pelos administradores. Os domínios devem ter acesso somente aos seus arquivos. Esta configuração evita que, mesmo quando houver a possibilidade de haver um script contendo vulnerabilidade de Cross-site scripting ou existir uma pessoa mal intencionada com acesso FTP a área de hospedagem, sejam expostos os arquivos do sistema. Page 40

41 Execução de programas no servidor Deve-se também desabilitar nos servidores PHP diversas funções. As funções que devem ser desabilitadas sao: exec(), passthru(), popen(), pclose(), proc_close(), proc_get_status(), proc_nice(), proc_open(), proc_terminate(), shell_exec(), system() e phpinfo(). Deve-se também desabilitar as seguintes classes de comandos: sysvshm, sysvsem, sockets, shmop, qtdom, posix, dio, crack. Page 41

42 Maior Portabilidade Utilizando as variáveis padrões, obtemos uma maior portabilidade do sistema desenvolvido: Algumas variáveis importantes são: $_SERVER[ PHP_SELF ]: Url do script que foi executado. $_SERVER[ DOCUMENT_ROOT ]: Retorna o diretório raiz da sua área de hospedagem; $_SERVER[ REMOTE_ADDR ]: IP do cliente que requisitou a página; $_SERVER[ REMOTE_HOST ]: Endereço do cliente que requisitou a Free página; Powerpoint Templates Page 42

43 Maior Portabilidade Sempre desenvolva utilizando $_REQUEST, $_GET, $_POST, $_COOKIE, pois estas são padrão em qualquer sistema. E quando você portar seu código para um servidor seguro, o mesmo não irá necessitar de grandes alterações. Page 43

44 Exercício No ambiente Linux: Instalar o IDS PHP Configurar o mesmo Testar suas funcionalidades, simulando três ataques diferentes vistos em sala da aula Page 44