Requisito 4: Sem erros para o usuário

Falaremos aqui de outro ponto importantíssimo na questão de segurança que é freqüentemente ignorado pelos desenvolvedores: as mensagens de erro.

As mensagens de erro foram feitas para que o desenvolvedor possa trabalhar de forma mais prática e descobrir o que ele está fazendo de errado. Observem, entretando, que, quando uma aplicação atinge maturidade suficiente para “entrar em produção”, torna-se imperativo que o usuário não visualize mensagens de erro.

A razão disso é muito simples: as mensagens de erro freqüentemente trazem informações sensíveis. Observe como exemplo uma típica mensagem de falha de conexão com a base de dados:

Warning: mysql_connect() [function.mysql-connect]:
Access denied for user 'foo'@'localhost' (using password: YES)
in /usr/local/apache/htdocs/script.php on line 2

Note, através das partes destacadas, que esta mensagem me informa:

1. O tipo de RDBMS: mysql
2. O usuário de conexão com a base: foo
3. Que este usuário está tentando uma conexão de dentro do servidor: localhost
4. O caminho absoluto da raiz web: /usr/local/apache/htdocs
5. O nome do script: script.php

É por isso que, quando colocamos uma aplicação em produção, ocultamos as mensagens de erro e as gravamos diretamente em um arquivo de log. Isto é muito simples de implementar:

Exemplo:

display_errors = Off
log_errors = On
error_log = /log/php_errors.log

Requisito #5: Esconda do servidor web o que ele não precisa acessar

Quantos de nós não usamos em nossas aplicações um arquivo, tipicamente chamado de config.php ou setup.php, onde guardamos, por exemplo, usuário e senha da base de dados?

Não há nada de errado nisso, mas cuidado: se este arquivo não gera saída de informação em HTML, por que deixá-lo acessível via web?

Para esclarecermos o problema, vamos definir 3 coisas:

1. minha raiz web é: /usr/local/apache/htdocs
2. meu arquivo de configuração fica localizado em /usr/local/htdocs/config/config.php
3. este é um código típico que usa este arquivo:

require_once("/urs/local/htdocs/config/config.php");
/* bla bla bla */

Observe que o erro neste caso é confundir interpretador PHP e servidor web. O Apache (ou IIS, Xitami etc) não precisa saber onde está este arquivo. Isto é responsabilidade do interpretador.

Outro problema é que se arquivo fica desnecessariamente exposto, afinal de contas basta eu abrir um navegador e digitar:

http://www.meusite.com.br/config/config.php

Não faz sentido. Por mais que você possa argumentar que não há forma de ler o código-fonte deste arquivo, ainda assim, isto não muda o fato de que ele está desnecessariamente exposto.

A solução é simples: movemos o arquivo para fora da raiz web:

/usr/local/config/config.php

E depois apenas acertamos as permissões e corrigimos nosso código:

require_once("/urs/local/config/config.php");
/* bla bla bla */

A partir de agora nosso arquivo de configuração só pode ser lido por quem precisa dele: o interpretador PHP.

Requisito #6: Use criptografia

Dados sigilosos são chamados assim por um motivo. Quando tratamos especificamente de senhas é impressionante a quantidade de aplicações web que gravam senhas em texto puro na base de dados.

Ora, se a senha possui a importância que tem e quem a escolhe é o usuário, por que alguém mais precisa ler essa senha?

Se a senha possui este peso em nossa aplicação, não podemos nos dar o luxo de fazer com que ela trafegue pela aplicação totalmente exposta.

PHP implementa criptografia de várias formas, mas eu sugiro – para quem puder usar, pois exige instalação e configuração extra – a utilização da função mcrypt.

Os hashes MD5 e SHA-1 são opções válidas, mas o problema é a sua fragilidade: para o MD5 existe até dicionário de dados, enquanto o SHA-1 foi recentemente “quebrado” por um pesquisador chinês.

Conclusão

A implementação de regras básicas de segurança depende apena da boa vontade do desenvolvedor. Você deve ter percebido como a maior parte das soluções aqui apresentadas significam simples mudanças de hábito.

É mais do que tempo de nós, desenvolvedores PHP, deixarmos de lado nossos antigos vícios e começarmos a implementar boas práticas de programação.

Ganha o profissional, ganha a sua aplicação, ganha o seu cliente, ganha o mercado. Só quem perde nessa situação é quem tenta se aproveitar de nossa aplicação.

Referências e links sugeridos

[PHP Security Consortium] – http://phpsec.org/
[PHP RS] – http://www.phprs.com.br/

Er Galvão Abbott trabalha há mais de dez anos com programação de websites e sistemas corporativos com interface web. Autodidata, teve seu primeiro contato com a linguagem HTML em 1995, quando a internet estreava no Brasil. Atualmente, além de lecionar em diversos cursos, tem se dedicado ao desenvolvimento de sistemas baseados na web, tendo nas linguagens PHP, Perl e JavaScript suas principais paixões.

Parte I

O PHPMailer é um componente de envio de e-mail para servidores que exigem autenticação ou para um desenvolvedor que deseje configurações mais avançadas para a rotina de e-mail pelo php que o a função mail() não possua. É importante percebermos que um servidor que exige autenticação o faz por razões de segurança, para que o mesmo não caia nas listas negras caracterizado como um servidor de Spams.

A seguir, um exemplo de código para envio de e-mail pelo PHPMailer (para páginas de Contato ou Fale Conosco, por exemplo).

Obs: O ideal é que você baixe o PHPMailer e coloque no seu próprio servidor, deixando com que o seu domínio sempre tenha independência e rapidez no envio de mensagens através das suas páginas.

Relacionados:

• Página de contato usando o AspEmail
• Página de contato usando o ASP.Net

pdftk – the pdf toolkit

Bem vindo | HDFree Brasil

Hospedagem de páginas gratuitas

Dividindo dados em colunas – Mauro Pichiliani – SQL Server

yfrog – Share your images/videos on Twitter!

Media Converter – the fastest free online audio and video converter

Top 100 Open Source Security Tools

O mundo de lunga: Conexão 3G – Solução para problema com DNS

Para resolver o problema de DNSs para conexões com modems Huawei, que sobrescreve o /etc/resolv.conf

50+ Gorgeous Navigation Menus | Vandelay Design Blog

50 exemplos de menu de navegação

Edições Cristãs Editora Ltda.

Chartle.net – interactive charts online!

Ferramenta para montagem de gráfico para colocar em sites

Piwigo.org | Photo Gallery Software for the Web

Mais um exemplo de uma boa galeria de fotos

Resize your image online – It’s easy, it’s free!

Redimensionamento de imagens pela web

Filmow

“O Filmow foi criado para pessoas viciadas e apaixonadas por filmes. A principal ideia do Filmow é que você mostre aos seus amigos os filmes que já assistiu, comente sobre eles e dê sua opinião, na página do filme. Mas, para os que apenas gostam de filmes, o Filmow também é uma rede social onde é possível encontrar pessoas e amigos.

No Filmow você fica sabendo quais filmes são lançados, os que estão no cinema e aqueles que já estão em DVD, para você assistir em casa.” (http://filmow.com/sobre-o-filmow/)


function valida_cpf($cpf) {
// verifica se e numerico
if(!is_numeric($cpf)) {
return false;
}

// verifica se esta usando a repeticao de um numero
if( ($cpf == '11111111111') || ($cpf == '22222222222') || ($cpf == '33333333333') || ($cpf == '44444444444') || ($cpf == '55555555555') || ($cpf == '66666666666') || ($cpf == '77777777777') || ($cpf == '88888888888') || ($cpf == '99999999999') || ($cpf == '00000000000') ) {
return false;
}

//PEGA O DIGITO VERIFIACADOR
$dv_informado = substr($cpf, 9,2);

for($i=0; $i<=8; $i++) {
$digito[$i] = substr($cpf, $i,1);
}

//CALCULA O VALOR DO 10º DIGITO DE VERIFICAÇÂO
$posicao = 10;
$soma = 0;

for($i=0; $i<=8; $i++) {
$soma = $soma + $digito[$i] * $posicao;
$posicao = $posicao - 1;
}

$digito[9] = $soma % 11;

if($digito[9] < 2) {
$digito[9] = 0;
} else {
$digito[9] = 11 - $digito[9];
}

//CALCULA O VALOR DO 11º DIGITO DE VERIFICAÇÃO
$posicao = 11;
$soma = 0;

for ($i=0; $i<=9; $i++) {
$soma = $soma + $digito[$i] * $posicao;
$posicao = $posicao - 1;
}

$digito[10] = $soma % 11;

if ($digito[10] < 2) {
$digito[10] = 0;
}
else {
$digito[10] = 11 - $digito[10];
}

//VERIFICA SE O DV CALCULADO É IGUAL AO INFORMADO
$dv = $digito[9] * 10 + $digito[10];
if ($dv != $dv_informado) {
return false;
}

return true;
} // function valida_cpf($cpf)

Copie o código aqui.

Código adaptado do iMasters.

Quem está em SP e estiver disponível em 1º de março (1ª edição) ou 31 de maio (2ª edição) terá uma ótima oportunidade de conhecer ainda mais sobre práticas de segurança no desenvolvimento em php. Recebi a seguinte mensagem do Er Galvão:

No dia primeiro de Março estarei em São Paulo ministrando um workshop sobre segurança em aplicações PHP, focando em tópicos específicos e técnicas 100% práticas de defesa.

Er Galvão entende muito de segurança e tem grande facilidade em passar seu conhecimento, como pode ser visto no artigo Segurança no PHP. Se eu estivesse em São Paulo, não perderia.

Segurança no desenvolvimento é fundamental para que a internet seja, verdadeiramente, uma ferramenta benéfica para o comércio. Conheço códigos de lojas virtuais que não foram desenvolvidas com preocupação nos tópicos de segurança. Se isso acontece por terem sido construídas antes de se conhecer as práticas atuais, está mais do que na hora de que sejam reconstruídas. Imagine o prejuízo que já se tem (só não se sabe) quando algum criminoso digital conhece essas falhas.

Use a tecnologia a seu favor. Ouça o que o Er Galvão tem a contribuir.

http://www.temporealeventos.com.br/?area=88

São Paulo – SP
1 de Março 31 de maio das 9h00 às 17h00 (2ª edição)

Aprenda: 1 profissional por máquina

PHP: Proteja sua Aplicação

técnicas para defender sua aplicação PHP de ataques como SQL Injection, Cross Site Scripting e Cross Site Request Forgeries

Objetivo: Neste treinamento o profissional aprenderá técnicas para defender sua aplicação PHP de ataques como SQL Injection, Cross Site Scripting e Cross Site Request Forgeries. Primeiramente serão apresentados exemplos práticos de funcionamento de cada um destes ataques de forma à compreender os pontos fracos de cada aplicação. Serão então colocadas em prática diversas técnicas, variando das mais simples às menos óbvias que axiliarão o desenvolvedor à diminuir consideravelmente o nível de vulnerabilidade de suas aplicações.

Público Alvo: Desenvolvedores PHP e demais interessados

Pré-requisitos: Conhecimentos básicos de HTML e Conhecimentos intermediários de PHP

Sistema operacional em que o curso será ministrado: Linux

Após o término deste treinamento o participante estará imediatamente apto a: Compreender o funcionamento dos ataques mais comuns que rondam a web, desenvolver aplicações mais seguras e robustas, menos vulneráveis à ataques.

Conteúdo Programático

Boas práticas:

O que todo o programador PHP deveria saber
O que é e como funciona um ataque de SQL Injection
SQL Injection – Técnicas de defesa: Porque addslashes não é o bastante
O que é e como funciona um ataque de Cross Side Scripting (XSS)
XSS – Técnicas de defesa
O que é e como funciona um ataque de Cross Site Request Forgeries (CSRF)
CSRF – Técnicas de defesa

Vou pedir licença ao Frederico e também palpitar sobre a possibilidade de, em uma linha, converter o formato de data do banco (funciona para o MySQL e outros bancos) para o formato brasileiro em php.

Considerando que <?php $data = "2008-01-09 14:56:06"; ?>:
<?php echo date('d/m/Y H:m:s', strtotime($data)); ?> mostrará 09/01/2008 14:01:06.
<?php echo date('d/m/Y', strtotime($data)); ?> mostrará 09/01/2008.

Simples assim.

Essa solução funciona para datas no formato yyyy-mm-dd hh:mm:ss e yyyy-mm-dd.

Os 6 requisitos mínimos

por Er Galvão Abbott (http://www.galvao.eti.br/) na revista PHPMagazine (http://www.phpmagazine.org.br/)

Apresentareremos neste artigo 6 requisitos que todo o desenvolvedor PHP deveria contemplar em sua aplicação. São boas práticas e hábitos simples que implementam um nível mínimo de segurança em qualquer sistema ou ferramenta desenvolvida com a linguagem.

A linguagem PHP é, sem dúvida, uma das mais populares quando o assunto é desenvolvimento de aplicações web. Existe, porém, um preconceito muito grande com a linguagem quando a questão é segurança. Neste artigo veremos 6 requisitos básicos que toda aplicação deveria possuir e que implementarão o mínimo de segurança em tudo o que você desenvolver.

Conceito: PHP é uma linguagem mais vulnerável do que as outras?

Atualmente impera no mercado de desenvolvimento um preconceito relacionado à segurança de aplicações PHP. A linguagem é freqüentemente alvo de duras críticas por parte da própria comunidade de desenvolvimento, e não é raro presenciarmos aplicações extremamente vulneráveis que, com toda a certeza, dão razão a essas críticas.

Este preconceito, totalmente equivocado, tem suas origens na extrema flexibilidade de configuração e uso da linguagem e no número cada vez maior de desenvolvedores inexperientes que começam sua carreira desenvolvendo aplicações PHP, ignorando questões básicas, seja por falta de conhecimento ou porque estão procurando agilizar sua produção pessoal.

Este artigo não é destinado apenas aos que estão começando. É surpreendente o número de desenvolvedores mais experientes que, por terem adquirido vícios, ainda ignoram as questões que apresentaremos aqui.

Requisito #1: Esqueça register_globals!

Register_globals é, sem dúvida alguma, a diretiva de configuração mais popular e polêmica já implementada no PHP. É popular entre os desenvolvedores por tornar o processo de programação muito mais ágil e prático. É polêmica porque retira tanto do programador quanto do interpretador da linguagem a responsabilidade em definir a origem das informações utilizadas pela aplicação.

Esta diretiva causou tantos problemas que começou a vir desabilitada por default a partir da versão 4.2.0 e será eliminada na versão 6. Por isso, se você ainda programa com register_globals ligada, está mais do que na hora de mudar.

Observe o seguinte exemplo de código:

$url = "http://www.meusite.com.br/index.php";
$errMsg = "Usuário%20não%20autenticado";
if (!$autenticado) {
header("Location: $url?erro=$errMsg");
} else {
/* A aplicação age com se o usuário estivesse autenticado */
}

Este código verifica por uma variável booleana chamada $autenticado, que tipicamente viria de uma sessão aberta quando o usuário se autenticou em nossa aplicação ou mesmo de um cookie. Ao utilizarmos os recursos da register_globals, porém, não estamos dizendo ao interpretador PHP que este dado deve vir obrigatoriamente de uma destas duas fontes.

Sendo assim, o interpretador procurará por esta variável em diversas fontes (variável do servidore web, dados de formulário, cookie, arquivos enviados por upload, query string ou sessões) das quais ele obteve informações até encontrá-la, desprezando se esta fonte está correta.

Torna-se extremamente simples “enganar” a sua aplicação PHP, basta que eu chame o seu arquivo passando a variável esperada por query string.

http://www.meusite.com.br/script.php?autenticado=1

Ao receber a query string contendo a informação “autenticado”, este dado será automaticamente interpretado como uma variável pelo interpretador, quer exista sessões ou cookies ou não.

Uma dúvida freqüente é “se não tenho autorização para desligar a register_globals o que eu posso fazer?”. A resposta para isso é tão simples quanto tudo o mais na linguagem: programe como se ela estivesse desligada! Veja como fica o nosso código ao não utilizar a register_globals:

$url = "http://www.meusite.com.br/index.php";
$errMsg = "Usuário%20não%20autenticado";
if (!$_SESSSION['autenticado']) {
header("Location: $url?erro=$errMsg");
} else {
/* A aplicação age com se o usuário estivesse autenticado */
}

Observe a mudança: ao utilizarmos o array super global $_SESSION, estamos explicitando para o interpretador que a informação “autenticado” tem que, obrigatoriamente, vir de uma sessão. Isto significa que será impossível para o interpretador confundir este dado com um dado enviado pela query string, pois este fica armazenado em um array super global diferente:

• $_SERVER – Informações definidas pelo servidor web (Apache, IIS etc)
• $_GET – Informações passadas por query string ou por um formulário web utilizando o método GET
• $_POST – Informações enviadas, tipicamente, por um formulário web utilizando o método POST
• $_COOKIE – Informações fornecidas por um cookie HTTP
• $_FILES – Informações fornecidas por arquivos que foram enviados via upload HTTP
• $_ENV – Informações fornecidas pelo ambiente do servidor
• $_REQUEST* – Informações fornecidas por GET, POST ou COOKIE

* Cuidado: O uso do array super global $_REQUEST é quase tão perigoso quanto a register_globals em si, pois nesse caso a informação pode vir de qualquer um dos 3 métodos: GET, POST ou COOKIE.

Requisito #2: Use require e não include

O comando include e seus derivados – como include_once – são freqüentemente usados em detrimento do comando require. Este fato curioso a princípio é conseqüência da similaridade do comando include com outras linguagens, como C e Java.

O que muita gente não sabe, porém, é que este comando carrega consigo um risco muito grande para sua aplicação: se por algum motivo a inclusão do arquivo falhar – erro de digitação, disco corrompido etc – será gerado um erro de nível warning, um nível leve de erro que não causa a parada da execução do script.

Utilizando o comando require, garantimos que, no caso de falha na carga do arquivo, seja gerado, além do erro de nível warning, um erro de nível fatal. Em bom português isso significa que a execução do seu script será imediatamente interrompida neste caso. Por que é bom que seu script seja interrompido no caso de falha de inclusão de outro arquivo? Simples: no caso de falhas, as variáveis, as funções, as constantes e o que mais este arquivo carregava consigo, simplesmente, não estarão disponíveis.

Requisito #3: Filtre a entrada de dados!

Um dos principais conceitos de segurança é a filtragem dos dados que são recebidos antes de utilizá-los. A falta de fitlragem é a causa de inúmeros problemas de segurança, incluindo o infame SQL Injection, ou Injeção de SQL. Observe o seguinte código:

require_once("conecta.php");
$conn = conecta();
$sql = "SELECT email FROM usuarios WHERE usuario_id = " . $_GET['uid'];
$recordSet = mysql_query($sql);
while ($record = mysql_fetch_assoc($recordSet)) {
echo $record['email'] . '<br />';
}
mysql_close();

O problema deste código é utilizar um dado informado pela query string (uid) sem fazer nenhuma filtragem, ou seja, nosso script aceitará cegamente qualquer coisa que for digitada como valor de uid. Observe a seguinte URL:

http://www.meusite.com.br/script.php?uid=198%20OR%20′x’='x’

Após a conversão dos caracteres especiais desta URL, o valor de uid será (sem aspas duplas): “198 or ‘x’='x’”. Note que, quando concatenarmos isto à nossa query, ela terá sofrido uma grande modificação:

SELECT email FROM usuarios WHERE usuario_id = 198 or 'x'='x'

É por isso que a chamamos de “Injeção de SQL”. A parte em vermelho acima é formada de SQL válido, mas completamente alienígena à nossa plicação: ele modifica o comportamento original da query.

Observe que, com um mínimo de esforço, um usuário conseguiu expor todos os e-mails cadastrados em nossa base de dados: como foi utilizado o operador “OR” e a segunda condição (‘x’='x’) é sempre verdadeira, serão exibidos todos os registros.

Para evitarmos este tipo de problema, devemos aplicar um tratamento à informação antes de utilizá-la. Caso a minha query – como neste exemplo – esteja esperando um número inteiro, a solução é simples: forçamos a conversão do dado recebido para número inteiro:

require_once("conecta.php");
$conn = conecta();

settype($_GET['uid'], integer);

$sql = "SELECT email FROM usuarios WHERE usuario_id = " . $_GET['uid'];
$recordSet = mysql_query($sql);
while ($record = mysql_fetch_assoc($recordSet)) {
echo $record['email'] . '<br />';
}
mysql_close();

A partir de agora, qualquer dado enviado pela query string será primeiro convertido para inteiro e somente depois desta conversão é que o utilizaremos. No caso de uma tentativa de Injeção de SQL, nosso script considerará apenas a parte numérica (198), como deveria ser. Além disso, se por um acaso nosso script receber apenas texto, a função settype converterá isto para o número 0.

Caso a minha query esteja esperando uma string a solução reside em criar um tratamento que valide esta string. Vejamos um exemplo: possuo uma query que busca dados de um usuário através de seu endereço de e-mail:

$sql = "SELECT nome, sobrenome FROM usuarios WHERE email = '" . $_GET['email'] . "'";

Sabemos que um endereço de e-mail é formado por um nome de usuário, uma arroba e um domínio. Para fins de simplificação do exemplo, trabalharemos como se o usuário só pudesse usar letras, números e o caracterese de ponto – para quem levar a validação de e-mail a sério consulte a RFC 822. Podemos representar isso através de uma expressão regular:

/^[A-Z|a-z|0-9|\.|]+\@[A-Z|a-z|0-9\.|]+/

Sendo assim, só aceitaremos o dado de endereço de e-mail se ele estiver dentro dos padrões de minha expressão regular. Nosso código então ficaria assim:

require_once("conecta.php");
if (preg_match('/^[A-Z|a-z|0-9|\.|]+\@[A-Z|a-z|0-9\.|]+/', $_GET['email'])) {
$conn = conecta();

$sql = "SELECT nome, sobrenome FROM usuarios WHERE email = '" . $_GET['email'] . "'";
$recordSet = mysql_query($sql);
while ($record = mysql_fetch_assoc($recordSet)) {
echo $record['email'] . '<br />';
}
} else {
die("O dado informado não é um endereço de e-mail válido.");
}
mysql_close();