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

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

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