Sahb %)

Bom, essa dica é bem rápida. Estava eu querendo fazer um seletor de linguagem em um site, para poder fazer urls como: exemplo.com.br/en/pages/show/4 para inglês e exemplo.com.br/es/pages/show/4 para espanhol. Um trabalho para o nosso querido routes.php não é mesmo? Porém, nas minhas andanças pela internet, não achei facilmente um tutorial que explicasse como fazer isso. Então bolei essa minha solução, baseado no que achei pela net.

A idéia é receber no controller pages algum parâmetro. Eu queria receber pelo $this->params['named'], mas não consegui achar um jeito de fazer isso. Quem conseguir, por favor, me mande como pelos comentários. A idéia é simples, e a solução também (apesar de não ter sido óbvia pra mim por não ser tão versado no routes.php). No routes.php, eu coloquei o seguinte:

Router::connect('/:lang/pages/*',
                 array('controller' => 'pages', 'action' => 'show'),
                 array("lang"=>'en|es|fr|br'));

Notem que nesse mesmo connect, eu coloquei um atalho de pages/show/id pra só pages/id. Notem também que só são aceitos os prefixos en, es, fr e br. Qualquer outra coisa, é tratado pelo Cake normalmente.

Essa variável lang, eu pego ela no $this->params, mas ela não vem no named, ela vem fora. Para acessá-lo no controller, você usa $this->params['lang'].

Bem simples né? E bem poderoso também

Espero que seja útil a vocês.

[]‘s

Sahb,.

Bom, conforme prometido, vamos dando sequência à série sobre segurança. Dessa vez serei bem breve, pois gostaria apenas de fazer um adendo importante ao post anterior. Eu tinha para mim, que era consenso que as pessoas sabiam fazer queries SQL de maneira correta e segura. Em especial, estou falando das queries que buscam id’s, ou qualquer dado inteiro, que não necessite de aspas para delimitar o valor. Pelo visto, pouca gente sabe, mas nesses casos, as aspas são opcionais. Sim, opcionais. Mas por que eu estou falando isso?

Você provavelmente já fez algum site que recebesse um parâmetro por GET do tipo noticias.php?id=2 , certo? E lá na sua query, você fazia todo feliz:

SELECT titulo,data,conteudo,autor FROM noticias WHERE id=$_GET['id'];

Aí, você leu meu artigo anterior sobre segurança e foi todo meninão (ou meninona, existem muitas mulheres programadoras ) colocar o seu mais novo amigo em ação, o mysql_real_escape_string(). Daí você passou a usar essa função a torto e a direito, achando que estava seguro. Aí um belo dia, você descobre que foi alvo de SQL Injection e me xinga todo, até a décima quarta geração… Pera lá! A tal função é muito útil, mas não é uma bala de prata.

A mysql_real_escape_string() serve para ‘escapar’ aspas de strings passadas para queries SQL, basicamente. Bão, pra uma query como a citada, o valor não é delimitado por aspas, então o atacante nem precisa se preocupar em burlá-las… Perceberam agora o problema?

Pelo que eu vi, muita gente não tem essa maldade, então sugiro que tenham… Outro dia vi um menino muito chato fazendo um noticia.php?id=2 or 1=1 e essa query pesou tanto o sistema que o site travou. Falei esse exemplo porque na maioria dos casos, esse ataque nem causa estragos, então não vão me condenar por criar monstrinhos… Bom, última chance pra você entender o que aconteceu. Fazendo aquela chamada, a query executada foi:

SELECT titulo,data,conteudo,autor FROM noticias WHERE id=2 or 1=1

Ou seja, retornaremos todos os registros do banco. Se os dados são um pouco mais complexos, e a query consulta várias tabelas, isso deitaria o servidor sem muita dificuldade.

Mas e aí? Coloque a tal aspa opcional, e junto com a nossa célebre amiga mysql_real_escape_string(), você estará mais alguns passos próximo de um site mais seguro =D

Resumindo, faça:

$query = sprintf("SELECT titulo,data,conteudo,autor FROM
     noticias WHERE id='%s';", mysql_real_escape_string($_GET['id']));

Acho que fui claro. Qualquer coisa, estou às ordens nos comentários. Depois tem mais.

[]‘s

Sahb,.

Sobre essa série sobre segurança

Irei fazer uma série de posts sobre segurança na internet. Cobrirei segurança no site em si e no servidor que o contém. Em cada post irei cobrir um pouco das minhas “neuras” com segurança. Espero que seja útil!

Neste primeiro falarei sobre algumas atitudes que podem fazer seu código em PHP lhe poupar algumas dores de cabeça.

Começando

Fazer códigos em PHP é fácil. Sabendo um pouco de lógica de programação, com meia hora de google, você já está fazendo coisas simples, mas úteis. Porém, essa facilidade em qualquer um conseguir fazer ferramentas web traz alguns problemas com ela. Como tem muitos “fazedores de site” por aí, e vários são adeptos da cultura do “Ctrl+c, Ctrl+v”, não é difícil achar sistemas web que tenham algumas falhas de segurança graves, ou se comportem de maneira imprevisível se alguma entrada incomum for feita.

Não quero me adentrar demais no assunto dos “fazedores de site”, pois é uma questão que vai muito além do escopo do que quero passar hoje. Mas, gostaria apenas de dizer que nada tenho contra quem não tem tanto conhecimento técnico e ganha vida fazendo sistemas web, pois afinal, todos nós já fomos assim um dia. Gostaria também de alertá-los para algumas práticas simples que podem lhes poupar de dores de cabeça e prejuízos. Vamos lá.

O código fazer o que você quer que ele faça não é tudo

Bom, você pode ler esse subtítulo e se perguntar “se faz tudo que eu quero, não faz tudo então??”. A resposta é simples: não. Um sistema web está exposto (como vários outros sistemas computacionais), a usuários mal-intencionados. Não vou entrar muito em detalhes sobre o que esses “usuários do mal” do seu site podem querer, mas eles podem desejar assumir seu site para ter uma base para enviar spam, disseminar vírus, entre outras malfeitorias que incluem também apagar seu banco de dados só por diversão. “Quem iria querer fazer isso com o meu site???” você pode se perguntar. Bom, existem pessoas mal-intencionadas em qualquer lugar, a vida real já deve ter te mostrado exemplos de maldade gratuita, e novamente, não irei me aprofundar nesse viés do ser humano.

O fato é: uma aplicação web deve se preocupar em se comportar corretamente recebendo as entradas corretas. Mas mais importante, deve se preocupar em “aguentar” uma certa dose de entradas incorretas (isso se chama robustez). Seu banco de dados de usuários cadastrados pode parecer de baixo valor para você, mas se você perdê-lo e não tiver backup, você provavelmente vai sentir muitas saudades dele Sim, backup é importante também, faça muito backup (farei um tópico sobre isso um dia desses). Mas ter o site fora do ar, por ter perdido sua base de dados faz você perder visitas, e isso custa dinheiro, seja pra você (se você for o dono do site), seja para o seu cliente (se você for o “fazedor de sites”), o que faz você perder dinheiro também. Eu poderia gastar parágrafos e parágrafos explicando sobre os problemas que falhas de segurança trariam, mas meu objetivo aqui é apenas dar umas dicas mínimas para ter um sistema web seguro, pois, afinal, se você está lendo isso, já está sensibilizado que segurança é importante. Pra quem não está, e continua fazendo sites, digo que o mundo é uma selva, e rola uma seleção natural, projetos grandes trazem mais dinheiro, e projetos grandes são só pra quem dá conta de matar mamutes grandes E pra quem continua pagando pelo desenvolvimento de sites sem medidas de segurança, digo “Boa sorte”, por que é o que vocês vão precisar, pois é a única coisa que protege o negócio de vocês. E espero que estejam pagando bem barato pelo serviço.

Feito esse desvio filosófico no assunto, vou continuar. Entre as entradas incorretas que seu sistema pode receber, faço a seguinte distinção:

• Entradas incorretas não maliciosas: Datas em formato incorreto (e.g. 20/15/2009), endereços de e-mail digitados com erros (e.g. usuario@@mail.com), entre outros.
• Entradas incorretas maliciosas: essas entradas são para fazer o seu servidor realizar operações indevidas (como enviar e-mails em massa ou apagar o banco de dados), dando acesso não permitido a áreas restritas do site (para alterar seu conteúdo), etc.

Existem diversas soluções para lidar com esse problema. Eu particularmente gosto da seguinte abordagem:

• Problemas por entradas incorretas não maliciosas são tratadas no lado do cliente, com o bom e velho JavaScript; mostrando ao usuário o que está errado e sugerindo como corrigir. A partir do pressuposto de que essas entradas são corrigidas no lado do cliente, elas não são verificadas novamente no lado do servidor, certo? ERRADO! Elas são verificadas novamente, mas de maneira superficial, só que desta vez, o usuário não será notificado de erros. A política de como lidar com esses erros inesperados varia de pessoa para pessoa, mas eu sou da opinião de que tais entradas deveriam ser simplesmente ignoradas, pois não vieram do seu formulário e gastarão processamento precioso do seu servidor para tentar “consertá-la”. Sim, existe um ataque chamado Form Injection.
• Problemas por entradas incorretas maliciosas são tratadas no lado do servidor. Elas devem ser, a meu ver, ignoradas, e acho interessante fazer log de tal atividade, registrando o ip do invasore o que ele fez. Eu gosto da idéia de “punir” os usuários mal-intencionados notificando seu provedor de acesso a internet

Talvez agora você esteja se sentindo um pouco desolado em saber dessa selvageria que pode ser feita no seu site. Talvez você não tenha se importado muito com isso, mas tenho fé que você se preocupa com a segurança do seu sistema web (ou do seu cliente), pois como disse antes, você está lendo isso aqui. Não sei se isso serve de conforto, mas eu conheço uma série de sites com falhas de segurança desastrosas. Logicamente não irei listar quais são, mas não são poucos e não é exclusividade de sites pequenos. Bom, então você não está sozinho no mundo dos sites “escancarados”, mas recomendo que você venha para o time dos “menos escancarados”. Não posso chamar meu time dos sites seguros, porque minhas convicções me proíbem de aceitar que algo com 0′s e 1′s seja 100% seguro.

Muita conversa e pouca ação até agora… Vamos listar agora algumas atitudes mais concretas para melhorar a segurança do seu site.

Defendendo-se de ataques de Form Injection

Existe como você verificar de que página veio uma requisição para seu script PHP, então você pode pensar “oba! esqueça a validação server-side, é só eu olhar isso então e boa!”. Pelo meu sarcasmo, você já deve ter sacado que não é por aí né? De fato existe como você verificar esse tal referer. O problema é que isso pode ser burlável facilmente, e aí, pior do que não ter segurança, você vai ter uma falsa sensação de segurança. Então, minha recomendação é, valide os campos do lado do servidor. Como você já validou com JavaScript no seu formulário legítimo (conforme discutido anteriormente), sugiro jogar fora todos os campos que vieram dessa requisição, boa coisa não devem ser. Atente que o problema pode ser no seu validador JavaScript, então garanta que ele funciona realmente, antes de jogar fora as coisas no server-side. Podem existir outras políticas para lidar com isso, mas, essa é a minha, e no meu ver ela é suficientemente adequada.

Outra coisa importante, para campos numéricos. Se o campo é puramente numérico (id’s por exemplo), cheque no lado do servidor se ele é realmente numérico. E cheque também se ele está dentro do intervalo de valores válidos.

Os campos de texto são olhados com mais afinco na próxima seção, pois eles são mais delicados e levam a ataques mais pesados.

Defendendo-se de ataques de SQL Injection

Bom, esse é um dos ataques mais comuns e mais perigosos. Também, é um dos ataques mais fáceis de se previnir. Chega a me deixar preocupado como algo tão simples de se corrigir seja tão ignorado. Já tive acesso a muitas áreas restritas de sites com um simples

' or '1'='1

no campo usuário e senha. Alguns podem me condenar por ter ensinado como fazer um ataque de SQL Injection, mas tenho 2 coisas a dizer para essas pessoas:

• isso é a coisa mais fácil do mundo de se achar;
• isso serve para chocar e sensibilizar pessoas com sites que não tratam isso.

Vou explicar brevemente porque essa simples entrada dá acesso à área restrita do seu site. Vamos supor que você receba o usuário e senha através de um POST, e faz a seguinte query ao seu banco de dados.

$usuario = $_POST['usuario'];
$senha = $_POST['senha'];
$resultado = mysql_query("SELECT * FROM
 cadastro WHERE usuario='$usuario' AND senha = '$senha'");
if(mysql_num_rows($resultado) > 0){
   //codigo para dizer que o usuario foi autenticado no sistema
}
//resto do codigo vem aqui.

Com aquela entrada mostrada anteriormente, essa query chegaria ao SGBD da seguinte forma (para verificar por você mesmo, copie a entrada e cole-a nos lugares exatos das variáveis PHP):

SELECT * FROM cadastro WHERE usuario='' or '1'='1' AND senha = '' or '1'='1';

Isso retornaria um resultado com mais de um resultado, e lhe daria acesso a alguma coisa que você não deveria ter acesso. Tá, você pode dizer que fazer aquele “>0″ foi exagero, que você na verdade faz “==1″ no seu código. Eu só precisaria saber um usuário válido para fazer a mesma coisa com seu código. E fora que eu conseguiria apagar seu código inteiro com um DROP.

Como contornar isso? Existem alguns meios, mas o que eu acho mais recomendado é usar funções próprias do PHP para lidar com isso. É um pouco razoável você rejeitar todas as entradas que tenham a famigerada aspas simples ( ‘ ), com uma função feita por você mesmo. Você atingiria algum nível de segurança, mas o usuário Eduardo Sama’an ficaria muito chateado e confuso em não conseguir se cadastrar em seu sistema (um abraço para meu amigo Sama’an! iraquiano safado!). O jeito mais elegante, simples e correto, no meu ponto de vista, de tratar as entradas para o banco é usar a função mysql_real_escape_strings(). O link explica como utilizá-la. O mais impressionante é que para aquele código inseguro ficar bem mais seguro, só precisaria ser feito:

$usuario = mysql_real_escape_strings($_POST['usuario'],$variavel_da_conexao_do_BD);
$senha =  mysql_real_escape_strings($_POST['senha'],$variavel_da_conexao_do_BD);
$resultado = mysql_query("SELECT * FROM cadastro WHERE usuario='$usuario' AND senha = '$senha'");
if(mysql_num_rows($resultado) > 0){
   //codigo para dizer que o usuario foi autenticado no sistema
}
//resto do codigo vem aqui.

Sobre isso, cabe uma nota. Existe uma opção do PHP que permite um nível de segurança parecido, é a chamada magic quotes gpc. Sugiro que você clique nesse link para ver porque ele não é uma boa idéia. Se você ficou com preguiça de clicar, ou de ler aquele tanto de texto (Delgado, você tá lendo isso aqui também???), saiba que essa política deixa o programador mal-acostumado, torna o código dependente da configuração do servidor e gasta muito processamento inutilmente, pois nem todas as requisições precisam ser escapadas. Tanto foi execrada que a partir do PHP 6.0.0, ela foi removida. E ainda devo dizer que existem jeitos de burlá-la, mas para evitar mais protestos, não irei ensinar como, o google está aí pra isso (e já fiz mal de dizer que tem jeito de atravessar essa segurança)

Existem mais coisas entre o céu e a terra do que julgam nossa vã filosofia

O que fiz aqui foi ilustrar 2 problemas sérios conhecidos mas que recebem pouca atenção por programadores inexperientes. Existem inúmeras outras maneiras de se fazer coisas erradas em seu site, mas pelo menos agora você tem 2 problemas a menos para se preocupar E ainda está mais sensibilizado sobre segurança, e acredito que passará a dar mais atenção a isso. Se você tiver sugestões para próximos posts, sou todo ouvidos Se você tiver reclamações e/ou quiser comentar algo que falei, sou todo ouvidos também! Se você se sentiu ofendido pelo meu tratamento aos “fazedores de site” (ou sobrinhos, pronto, falei!), bom… Tá, pode discutir isso comigo também… hehehe

[]‘s

Sahb,.

Outro dia precisei fazer alguns feeders RSS para o Guia Entrada Franca, daí dei uma zapeada pela net e não tive maiores problemas em achar material de qualidade para me informar sobre como fazer meu próprio feeder. Porém, achei que as informações estavam muito espalhadas, então resolvi fazer esse mini-tutorial com o mínimo necessário para você ter um feeder RSS funcionando sem dores de cabeça. É um tutorial que realmente tem o mínimo necessário, então não reclamem pela falta de profundidade (você deve saber o mínimo de PHP e seu uso com MySQL) Ao final do post, vou colocar umas referências sobre RSS, além de colocar umas durante a explicação, quando for pertinente.

Uma pincelada sobre formato do XML do RSS

Vamos lá. O formato RSS é um XML que segue umas regrinhas especiais. Um Exemplo de RSS olá mundo seria:

<?xml version="1.0"?>
<rss version="2.0">
 <channel>
    <title>Meu Primeiro RSS</title>
    <link>http://rss.meuprimeirorss.com.br</link>
    <description>Este é o meu primeiro alimentador RSS</description>
    <language>pt-br</language>
    <item>
          <title>Título do meu primeiro item</title>
          <description>Esta é a descrição do meu primeiro post</description>
          <link>http://www.meuprimeirorss.com.br/topico.php?id=3400</link>
    </item>
</channel>
</rss>

Para testar, coloque salve esse arquivo com o nome de rss.xml (o nome não é importante, é apenas uma sugestão), e coloque em algum lugar visível pelo seu navegador. Vale ressaltar que esse tal lugar visível deve ser dentro de um servidor http (como o Apache), não funcionando se for aberto com o comando abrir arquivo do navegador. No meu caso, eu o coloquei pra rodar no meu Apache, então no Firefox (no meu caso, versão 3.0.6), fiquei com o seguinte resultado no navegador:

Resultado no Firefox 3.0.6

Vamos por partes agora (sem referências ao “Jack, o Estripador” ). Na primeira linha, nós temos um início padrão pra arquivos XML, nada fora do comum ou que você tenha que se preocupar (considerando que você só está interessado em fazer um feeder RSS). Bom, acho que posso dizer a mesma coisa sobre a segunda linha. Então eu quase poderia dizer idem pra terceira, mas gostaria só de falar que ela abre o channel, e pediria pra vocês notarem que ela termina no final do RSS. Agora vamos às linhas mais interessantes. O título vai em <title></title>, acho tranquilo (sem a trema ) mapear o título no XML e no Firefox. A descrição do canal vai em <description></description>, idem na facilidade de mapeamento. O endereço do próprio feeder vai entre as tags <link></link>, e no caso da figura acima, deveria ser http://localhost/rss.xml, mas deixei http://rss.meuprimeirorss.com.br para ficar mais claro, não sei se foi a opção mais didática, mas, enfim, está explicada a tag link. A tag <language> denota a linguagem em que o RSS está escrito (não, não é linguagem de programação se você pensou nisso ). Bom, creio que você não irá usar outra que não seja pt-br (Português do Brasil). Uma lista dos códigos das linguagens que pode ser encontrada aqui (está em inglês). É interessante notar que para definir o canal (channel), são obrigatórias as tags title, description e link apenas. Para ver todas as opções para o canal e para o item, que vai ser discutido agora, dê uma olhada aqui (em inglês também, mas gosto de pegar a referência mais oficial, e no meu ver, essa é a mais oficial e completa).

Vamos agora ao tal item mencionado anteriormente. O item é meio que o item do RSS mesmo, sendo uma notícia, um evento, um post ou qualquer coisa que seja listada no feed. O item não possui campos obrigatórios, porém a especificação do RSS 2.0 apenas recomenda que existam pelo menos os 3 campos que eu listei no exemplo, title, description e link. Mais uma vez, acho que não preciso explicar o que eles são, apenas falar que o título vira um link para o endereço listado pela tag com esse nome. Mas como pôde ser visto na referência, existem inúmeros outros campos que podem aparecer no item. O feed pode ter tantos itens quanto você deseje, então creio que dito isso, você sabe o mínimo necessário para ter um feeder RSS “na mão”. Vamos agora ao mínimo necessário para você fazer um feeder em PHP, para facilitar sua vida.

Fazendo um Feeder RSS em PHP

Se você opta por fazer um RSS em PHP, provavelmente você já tem um banco de dados com as notícias ou o que seja que você irá listar, e provavelmente sabe se conectar ao banco usando PHP. Se você não sabe, nem tem nada disso, um tutorial mais completo nesse sentido pode ser encontrado aqui (em inglês). Vamos então a um esqueleto de um feeder RSS em PHP.

<?
ob_start();
header("Content-Type: application/xml; charset=UTF-8");
//conexao ao banco, query, etc vem aqui

//aqui, como os delimitadores do php podem ser confundidos com
// o delimitador do XML, coloquei essa primeira linha dentro de
// 'echo' como forma mais simples, a meu ver, de resolver isso.
echo "<?xml version=\"1.0\"?>";
?>
<rss version="2.0">
 <channel>
    <title>Meu Primeiro RSS</title>
    <link>http://rss.meuprimeirorss.com.br</link>
    <description>Este é o meu primeiro alimentador RSS</description>
    <language>pt-br</language>
<?
// aqui sao feitas as atribuicoes aos campos retornados pelo banco
// suponha que o banco tenha as colunas id, titulo e descricao
while($linha = mysql_fetch_array($resultado_da_query)) {
   echo"      <item>\n";
   $id = $linha['id'];
   $descricao = $linha['descricao'];
   $titulo = $linha['titulo'];
   echo "          <title>$titulo</title>\n";
   echo "          <description>$descricao</description>\n";
   echo "          <link>http://www.meusite.com.br/noticia.php?id_noticia=$id</link>\n";
   echo "      </item>\n";
}
?>
   </channel>
</rss>
<? ob_end_flush(); ?>

Você pode estar se perguntando, só isso? É… só isso… Como você deve saber programar em PHP, deve ter notado que usei ob_start() e ob_end_flush(). Por que? Se sua requisição ao banco demorar algum tempo, ou o carregamento do conteúdo do PHP demorar, o Firefox pode não interpretar o conteúdo como um RSS e mostrar um XML sem muito sentido para o usuário. Então o servidor só manda o conteúdo inteiro, depois de tudo processado. Talvez hajam maneiras mais elegantes de se resolver isso, mas essa foi a que adotei, por achar mais simples (a boa e velha Navalha de Occam, ou, Occam’s Razor). Sugestões nos comentários serão bem-vindas sempre

Note também o que o cabeçalho da página  (header) foi forçado a ter codificação UTF-8 (caso tenha problemas com codificação, recomendo dar uma lida nisso aqui, o título é bem elucidativo ), e foi avisado que era um XML, para que não hajam sobressaltos nem problemas na interpretação do seu feed pelos leitores. Funciona sem, mas recomendo deixar aí por via das dúvidas

Dica para tornar seu feeder mais bacaninha

Você já deve ter visto vários sites que têm aquele simbolozinho do RSS na barra de endereços do Firefox para você se inscrever no Feed daquela página. Como fazer isso? Simples, é só adicionar o seguinte código ao cabeçalho (header, ou seja dentro das tags <head></head>):

<link rel="alternate" type="application/rss+xml"
    title="Meu RSS 1" href="http://www.meusite.com.br/rss/">

<link rel="alternate" type="application/rss+xml"
    title="Meu RSS 2" href="http://www.meusite.com.br/rss2/">

<link rel="alternate" type="application/rss+xml"
    title="Meu RSS 3" href="http://www.meusite.com.br/rss3/">

Você pode colocar só um, mas coloquei 3 só pra mostrar que podem haver vários.

Por onde começar a se aprofundar

Especificação do RSS

Tópico na Wikipedia em português sobre RSS

Tópico na Wikipedia em inglês sobre RSS

Bom, é isso… Talvez tenha sido muito superficial, mas… era só o mínimo necessário mesmo. Espero que seja útil. Comentários, dúvidas, sugestões, comentários off-topic e qualquer outra coisa serão bem-vindos (menos spam…)

[]‘s

Sahb,.