Boas práticas de envio de e-mail

O envio de e-mails de newsletter é algo sensível para os servidores de hospedagem. Ainda que já tenhamos esse tipo de propaganda, ainda é grande o desconhecimento de como realizar o envio de maneira que não sejam identificados como fonte de spam.

O que é spam?

Spam é o termo usado para referir-se aos e-mails não solicitados, que geralmente são enviados para um grande número de pessoas. Quando o conteúdo é exclusivamente comercial, esse tipo de mensagem é chamada de UCE (do inglês Unsolicited Commercial E-mail).

O conceito é simple mesmo. Ainda que seja uma só mensagem, caso ela seja indesejada do destinatário já a caracteriza como spam e quem a recebeu pode reclamar aos órgão de controle de abuso da internet.

Diante da reclamação, o IP do remetente vai para análise e inicia-se uma busca por novas reclamações provenientes de envio de mensagens por aquele IP ou de mensagens iguais enviadas por aquele IP (nesse caso, a caracterização de de spam para envio em massa – bulk mail). Após a caracterização o IP entra no banco de dados desses órgão, que propagam a informação para os servidores de e-mail espalhados na internet, que começam a recusar e-mails que vierem daquele IP, ou seja, qualquer domínio que utilize aquele IP para o envio de mensagens é recusado, ainda que não tenha sido o domínio responsável pelo spam.

Como desenvolvedor, quero prevenir que meus clientes tenham estes problemas. Vou utilizar este espaço, que será sempre atualizado, para divulgar a política de utilização e as práticas corretas do envio delistas de e-mail (as newsletters).

  1. O envio deve ser para um destinatário por vez e não para mais de um endereço ao mesmo tempo;
  2. O envio precisa ser feito com um período entre uma mensagem e outra (de 5 a 10 minutos, por exemplo);
  3. É imprescindível monitorar o retorno dos e-mails inexistentes (ou outros erros) e removê-los da lista de envio;
  4. Dar a opção em todas as mensagens enviadas para que o destinatário possa se descadastrar da lista.
  5. Não iniciar o primeiro contato com o cliente por e-mail, ou seja, o envio do primeiro e-mail, sem prévia autorização do cliente, caracteriza a prática de spam.

Leia também:

Tropeçando 2

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 exemplos de menu de navegação

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

Validar CPF com php

Uma função utilíssima para cadastros que exigem CPF. Returna true se o CPF for válido e false se inválido.


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.

Aonde você deseja se conectar hoje?

O site ConnectionString vem com uma proposta simples e muito útil: fornecer linhas de conexão. Tem conexão para tudo. Há conexões bancos de dados (SQL Server, Informix, MySQL, Progress, Paradox, Firebird etc), arquivos de dados (Excel, TXT, SQL Lite etc) e também para outros tipos (MS Project, Active Directory, Exchange, DNS etc).

A idéia de ConnectionString é fornecer uma fácil referência para linhas de conexão.

Hoje, existem 213 linhas de conexão no banco de dados coletadas a partir de outros sites da internet, livros, arquivos de ajuda, msdn ou que tenham sido submetidos pelos colegas desenvolvedores de todo o mundo.

Se alguém conhecer algum projeto semelhante para outras linguagens, não deixe de colocar nos comentários, por favor.

Galvão bota a mão na massa em SP

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

Converter formato de data para o formato BR, em uma linha de código só

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

Segurança no PHP

Os 6 requisitos mínimos

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

logo-phpmagazine

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