Arquivo

Arquivo da Categoria ‘Programação’

URL’s Amigáveis nos permalinks do seu WordPress preservando a estrutura antiga

13, abril, 2011 Sem comentários

Bom, outro dia sugeri ao super fotógrafo e guitarrista Sergio Buss que usasse um sistema de URL’s no site dele que fosse mais amigável. Como já ia escrever um pequeno passo a passo pra ele aplicar em seu blog, resolvi fazer um post, pra ajudar qualquer um que queira fazer isso também.

Começando

Se você tem um blog WordPress (como esse aqui :D ), provavelmente já deve ter notado que na instalação padrão, os links permanentes (permalinks) para seus posts e páginas são identificados como algo do tipo http://www.seusite.com.br/?p=221. Provavelmente também, deve ter reparado que algumas pessoas usam um sistema de url mais amigável, como http://www.seusite.com.br/2011/04/nome-do-post. Bem mais legal, né? Além de legal, os buscadores (principalmente o Google) adoram esse tipo de URL, e isso fará com que sua página apareça melhor colocada em buscas. Hoje vamos descobrir que fazer essa mágica da URL não é nada complicada.

Antes de começar a brincar com isso, certifique-se que seu servidor Apache tenha o mod_rewrite habilitado. Se você não sabe o que é mod_rewrite, nem o que é Apache, o suporte técnico da sua hospedagem saberá, daí você checa com eles se sua conta tem esse módulo (o mod_rewrite é um módulo). Estou sendo breve neste ponto porque praticamente todos os serviços de hospedagem têm esse módulo habilitado. Caso você tenha dificuldades, me avise que te ajudarei com mais detalhes.

Cuidado! Não são só flores!

Uma coisa importante a se fazer é garantir que você não perca o que conquistou nos resultados de pesquisa do Google. A estrutura nova de URL soará ao Google como novas páginas e as antigas terão desaparecido. Assim você voltará a idade da pedra, do ponto de vista dos buscadores. Mas nem tudo está perdido. Este plugin (dentro do admin WP, procure o plugin chamado Dean’s Permalinks Migration 1.0) permite que as URL’s antigas, se chamadas, redirecionem para a estrutura nova. Após instalá-lo e ativá-lo, é só ir em Configurações (ou Settings, em inglês), e de lá clique em PermalinksMigration. Coloque a regra que criava a estrutura antiga e salve. Se você não sabe qual é essa tal regra, vá em Configurações (Settings) e dentro dela, vá em Links permamentes (Permalinks). O campo Estrutura personalizada (ou Custom structure) irá conter a regra atual que gera seus links permamentes. Por exemplo, se seu site tinha a estrutura de links site.com/archives/5803, a regra nesse campo era /archives/%post_id%. É esse valor que você irá copiar e colar no PermalinksMigration. E assim, você agora está pronto para fazer a mágica das URL’s. Não prossiga se não tiver feito todos esses passos!

E agora, URL’s!

Chegou a hora de fazer seus links permanentes ficarem bonitões! Vá em Configurações (ou Settings, em inglês) e escolha o sub item Links permanentes (ou permalinks, em inglês). A mágica acontece na tela que carregará. Serão mostradas as opções de como sua url pode ficar. É bem auto explicativo. As opções fornecidas pelo WP por padrão, são as mais indicadas (eu por exemplo, uso a opção Mês e nome ou Month and name). Há a opção de fazer URL’s customizadas do tipo /%category%/%postname%/ (na notação dessa ferramenta), que é bem vista por muitas pessoas. Porém, por motivos de desempenho, prefira opções que antes de aparecer o nome do post, mostre um campo numérico. O sistema de Mês e nome é o mais bacana, a meu ver, porque esse campo numérico tem um valor que diz alguma coisa (é o ano e o mês de publicação), ao invés de um número arbitrário do id do post. Após selecionar a opção de mês e nome, clique em salvar. Lembre-se de testar se os links antigos estão funcionando corretamente, apontando para a estrutura nova, caso não estejam, volte rapidamente para sua configuração antiga, de links permanentes e cheque o que aconteceu de errado. Qualquer dúvida, me procure.

É isso então pessoal. Hoje aprendemos um jeito bacana de melhorar tanto a legibilidade das nossas URL’s, quanto a nossa relevância nos sites de busca. Espero que seja útil!

[]‘s

Sahb,.

Usando prefixos como parâmetros em URL’s do CakePHP

30, dezembro, 2010 Sem comentários

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

Scrum – Pontapé inicial para aprender

11, abril, 2010 2 comentários

Bom, conforme disse anteriormente, estou começando a aprender Scrum. Parece ser muito interessante, a ponto de me motivar dar uma parada nas minhas tarefas para compartilhar algumas impressões e materiais relevantes.

Mas antes de tudo, vamos nivelar todo mundo aqui. Se você chegou por aqui pelo Google, provavelmente já sabe o que é Scrum. Mas, se você caiu aqui sem saber por que, vamos dar uma visão rápida do que é essa metodologia.

Scrum (esse nome veio de uma formação do rugby) é uma metodologia ágil de desenvolvimento de projetos, muito interessante e muito usada em diversas empresas de desenvolvimento de software ao redor do mundo. Esse framework é iterativo e incremental e privilegia o cliente, pois ele passa a fazer parte do processo de maneira bem significativa, passando uma excelente impressão para o mesmo. É relativamente simples e desburocratizado. Poderia ficar me alongando mais aqui sobre o Scrum, mas acho mais prático dar uma olhada nos tópicos da Wikipedia em português e inglês.

Indicando estes 2 tópicos, mesmo quem já tem alguma noção e quer aprender, pode obter algumas informações novas. Recomendo a leitura. Mas há bem mais a se ler. Muito mais, dependendo do seu apetite. Estou nessa fase de ler muito sobre o Scrum, e ainda não acho que sei o suficiente pra explicar de maneira geral esta metodologia. Vou compartilhar os links para os materiais a que tive acesso gratuitamente pela internet, através de indicações de amigos e parceiros.

Minha primeira indicação é para este artigo bem sintético e objetivo sobre o assunto. Foi-me passado por Israel Guerra e João Victor, meus coordenadores no LSL (onde trabalho) e principalmente meus amigos pessoais. Atualmente, pode ser baixado seu PDF neste link aqui (em inglês). Caso não esteja mais disponível quando ler este post, me notifique postando um comentário por aqui. Isso vale para todos os links que eu postar. Outro link interessante indicado por estes 2 peças raras é uma página com o conceito do Scrum descrito de maneira bem breve, mas com links para vários outros tópicos importantes. O endereço da página está aqui, e infelizmente só tem a versão em inglês também. Ainda nas referências indicadas pelo Guerra e pelo João, temos “Agile Software Development with Scrum“, de Ken Schwaber.

Uma outra referência muito interessante que estou lendo atualmente é o livro “Scrum e XP direto das Trincheiras“, de Henrik Kniberg. Pelo título, já dá pra imaginar que é um material em português, e realmente é. Trata-se de fato de um livro e conta com uma versão gratuita online disponibilizada aqui. Será necessário criar um login no site, mas até hoje não recebi nenhum spam deles, então podem se cadastrar sem maiores preocupações. É um material relativamente extenso (148 páginas) e conta com exemplos impressões e conceitos. Este material me foi passado gentilmente pelo Henrique Castro da Helpper Soluções Inteligentes (uma das empresas ao redor do mundo que usam Scrum). Caso seja contra sua religião se registrar em sites para baixar arquivos, uma versão desatualizada (com 105 páginas) e em inglês pode ser encontrada na página do autor neste link aqui. Note que a primeira página é uma recomendação do próprio autor falando para baixar o livro no site citado anteriormente.

São poucas as minhas indicações para se ler agora, mas é porque elas são mais baseadas na reputação de quem me indicou (o Henrique, por exemplo, é Certified Scrum Master). No Google, uma pesquisa simples retorna inúmeros resultados e não duvido nada que a grande maioria seja relevante.

Sinta-se a vontade para indicar mais links interessantes pelos comentários. Pondero apenas que apagarei links para download de materiais protegidos por direitos autorais disponibilizados indevidamente.

Boa leitura e vamos estudar Scrum! :)

Por ora, é isso.

[]‘s

Sahb,.

P.S. 1: Adicionado em 13/04/2010: Mais um link interessante que encontrei. É um apanhado com vários documentos interessantes, inclusive o “Scrum Guide“, escrito pelo Ken Schwaber. Acesse por aqui.

Dicas mínimas para um site mais seguro – parte 2 – PHP

12, agosto, 2009 2 comentários

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 :D ) 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,.

Conflito entre prototype.js e jquery.js

28, abril, 2009 29 comentários

Bom, estou com o tempo curto aqui no trabalho, mas deixo esse post aqui para alertá-los sobre possíveis problemas que vocês podem encontrar usando aplicações web que usem o prototype.js (como o meu querido Lightbox ) junto com o meu também querido jquery.js. Por estar com pouco tempo, infelizmente não poderei me alongar nos detalhes dessas ferramentas que acho muito úteis e indispensáveis.

Mas enfim, se você chegou até aqui através do nosso amigo google, deve ser porque você está passando por esse problema agora :P

Vamos direto ao ponto. O jQuery possui um modo ‘noConflict’ para casos em que haja conflito com declarações de outras bibliotecas. Mas isso você já deve ter notado né? :P Para resolver isso, carregue o jQuery primeiro, e faça:

<script type="text/javascript" src="jquery.js"></script>

    <script type="text/javascript">
        jQuery.noConflict();
    </script>

Isso deverá vir antes de carregar qualquer outra biblioteca de scripts. A partir daí, você pode carregar os demais js’s, inclusive o prototype.js. Porém, não é só isso, mas calma, não vai ter nada de muito difícil. Nas chamadas ao jquery.js que usem o $, substitua esse por jQuery. Um exemplo é:

$("#conquistapg").load(url);

// Vira:

jQuery("#conquistapg").load(url);

Pronto! Agora é só isso mesmo!

Espero ter ajudado :)

Mais pra frente vou me alongar mais nessas bibliotecas bacanas.

[]‘s

Sahb,.

Codificação Drops

15, abril, 2009 1 comentário

Depois de muito tempo sem postar, eis que volto %) Estou trabalhando aqui na 5Clicks agora. Uma experiência muito bacana, trabalhando com coisas legais. Depois rola um post só pra puxar o saco da 5′. hehehe

Bom, vamos ao que interessa. Hoje me deparei com um problema que muitos devem passar por aí, e vejo que a maioria prefere se adaptar ao inconveniente a corrigí-lo. De fato, é meio chatinho achar a resposta para a pergunta, mas antes de me adentrar na solução, acho que seria legal eu falar qual é o problema.

Codificação. Sim, se você programa ou faz alguma coisa pra web, já teve dor de cabeça com os ISO-8859-1 (ou latin1), UTF-8, etc… Antes que seus olhos encham de lágrimas e seu coração pule de alegria, não se engane: não irei resolver todos os seus problemas de codificação (a menos que todos os seus problemas se resumam no problema que irei listar aqui, mas aí, ah, que sem graça… :P )

Tá, qual é o problema? Bom, o nosso querido MySQL retorna por padrão (pelo menos até onde sei, os comentários estão aí para corrigir as besteiras que eu falo também) na codificação latin1. Então, independente de como os dados são adicionados, ele sempre retorna em latin1. Com isso, numa pesquisa feita ao banco, se impressa na tela em uma página em UTF-8, o resultado da consulta vai mostrar as malditas interrogações de erro de codificação. O latin1 é bacana, o latin1 é legal, mas utf-8 foi criado pra unificar essa bagunça de codificações (aguardem um post só pra defender o unicode). Então, já que inventaram essa codificação pra facilitar nossa vida, que a usemos então!

Muitas pessoas passam a usar páginas iso-8859-1 por não saber como fazer o queridíssimo MySQL retornar em outra codificação. Bom, não é difícil achar isso, com algum empenho dá pra achar como, tanto que eu nem sou um gênio e achei :P . O problema em achar essa resposta, é que se costuma fazer uma pesquisa do tipo “codificação mysql utf8″. Isso retorna muitos resultados em como mudar a “collation” do banco. Daí, um colega com menos empenho ou com um prazo apertando o pescoço (acho que isso ocorre a maioria das vezes), acaba sucumbindo em não conseguir resolver isso, e faz a página toda em iso-8859-1.

E agora, sem mais delongas, uma solução bacaninha pra mudar o retorno do banco de dados MySQL pra unicode. Basta passar o seguinte comando toda vez que uma conexão ao banco for criada:

SET NAMES 'utf8';

Não entendeu? Tipo, você está lá, fazendo sua conexão ao banco, no PHP por exemplo, daí você faz:

$conexao = mysql_connect($host,$usuario,$senha);
mysql_select_db($database);
mysql_query("SET NAMES 'utf8'");

É só fazer isso %) E sigam usando seu unicode felizes e contentes. Depois vou postar mais dicas pra lidar com a codificação, um assunto que dá muita dor de cabeça pra muuuita gente.

Espero que tenha ajudado!

[]‘s

Sahb,.

PSPP

12, março, 2009 1 comentário

Bom, para quem não conhece o PSPP, ele é um programa livre para análises estatísticas similar e alternativo ao software proprietário SPSS. O Michel Boaventura (amigo pessoal pra todas as horas :) ), está fazendo um trabalho fenomenal colaborando no desenvolvimento do PSPP, inclusive na versão Windows do mesmo. Ele fez um blog sobre a jornada dele nessa empreitada e ficam aqui meus parabéns pelos avanços realizados até agora, e minha propaganda para seu blog.

Não é um software para uso de um público amplo, mas quem interessar, vale a pena. Creio não ser necessário me adentrar demais nas explicações sobre o PSPP pois o blog do Michel faz isso já :)

O endereço do blog é http://www.cecaps.ufmg.br/pspp/blog/

[]‘s

Sahb,.

Categories: Programação Tags:

Dicas mínimas para um site mais seguro – Parte 1 – PHP

4, março, 2009 5 comentários
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 :P 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,.

Categories: PHP, Programação, Segurança Tags: ,

Criando Feeder RSS usando PHP

27, fevereiro, 2009 1 comentário

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) :P 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

Resultado no Firefox 3.0.6

Vamos por partes agora (sem referências ao “Jack, o Estripador” :P ). 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 :P ) 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 :P ). 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 :P ), 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,.

Categories: PHP, Programação Tags: , ,