Queixavam-se algumas pessoas de entrarem no browserd.com e de serem logo “infetadas” com vírus… Não era o que se passava mas ainda assim, percebo que se assustassem.

Para o utilizador menos atento, tinha acabado de apanhar um vírus!

Tentei perceber se havia algum padrão entre os casos que me relatavam e a única coisa em comum era o facto de utilizarem o Internet Explorer. Mas eu também acedi ao browserd.com com o Internet Explorer mais do que uma vez e nunca tinha detetado nada de estranho. Seria a versão do browser?

Experimentei aceder ao site através do computador da Patrícia. Diferenças para os restantes computadores cá da casa: Internet Explorer 7 e Avast Anti-Vírus (nos outros computadores que há por aqui está instalado o Internet Explorer 8 e o Trend Micro Internet Security Pro).

Surpresa minha, eis que vejo o browser ser redirecionado de browserd.com para um endereço estranho e complicado, com uma mensagem em forma de pop-up (Não era. Tratava-se de uma layer bem desenhada sobre um background que simulava uma janela do Windows Explorer) a avisar-me da existência de um vírus no meu computador e a sugerir-me o download imediato de um programa que solucionaria a questão.

Nunca carreguem em nada sem perceber do que se trata. Leiam! É assim que se apanham vírus (também).

Não foi fácil encontrar a solução admito. Após alguma pesquisa pela Internet, comecei a relacionar a situação apresentada com o recente ataque em massa a sites alojados num dos mais famosos serviços de alojamento de sites, o GoDaddy. Infelizmente, não encontrei qualquer registo de casos no meus serviço de alojamento por onde me pudesse guiar. Além disso, todos as descrições técnicas do problema que ia lendo, referiam a existência de um determinado pedaço de código em todos os ficheiros php do site que eu não encontrava (malta dos códigos, base64_decode diz-vos algo?).

Pois na realidade, o ataque de que o browserd.com foi vitima teve um upgrade relativamente às técnicas usadas no ataque o GoDaddy. Ao invés de ser injetado em todos os ficheiros php do site o tal código base64, foi antes feito de alguma forma o upload de um novo ficheiro php para a root do site onde constava o base64 e que por sua vez, inseria uma linha de código nos ficheiros php que obrigava o browser a fazer o redirecionamento para um endereço (welcometotheglobalisorg.com) onde ai sim, redirecionava uma vez mais o browser para outros endereços onde carregava então as tais páginas falsas que se assemelhavam a mensagens de sistema, levando a que utilizadores mais incautos carregassem nos botões de “OK” e infetassem as suas máquinas.

Os hackers entraram no servidor. Agora há que os tirar de lá.

Claro que até chegar a esta conclusão não foi fácil. Eu olhava para o php e não para o código final apresentado no browser. Foi ao fazer view source (no Internet Explorer) que detetei a tal linha no fundo da página, completamente despercebida, quase inocentemente a dizer-me olá…

Solução? Bem, começou por identificar os tais ficheiros php novos. Menos mal. Inteligentemente, em cada instalação de WordPress o ficheiros tinham um nome diferente mas tinham sempre o mesmo tamanho. Apagar os ficheiros era assim mais fácil mas os ficheiros php do site, alterados por este ataque? O que fazer? Abrir cada um individualmente e apagar a tal referência de redirecionamento? Não me parecia razoável. São centenas deles. Em cada instalação…

Felizmente, aquando de um anterior ataque aos servidores da GoDaddy, o site Sucuri tinha disponibilizado um script que, em teoria, removeria o problema de todos os ficheiros. Diziam tratar-se de um script para quem tinha os sites alojados no GoDaddy mas, e vejam o carinho que tenho por vós caros leitores, eu estava por tudo. Não podia deixar estar a coisa como estava. Feito o download e respetivo upload para o site, executado o script e, está resolvido. A referência de redirecionamento desapareceu de vez.

Não vou entrar em mais detalhes, aliás, porque também não sei detalhar o que se terá passado assim com tanta certeza mas, de uma coisa estou certo: Ninguém está livre de que lhe aconteça e o facto de ter os computadores, quer em casa quer no trabalho, com os browsers e anti-vírus atualizados, levava-me a desconhecer que outros, eventualmente menos protegidos, poderiam estar a ter problemas.

Agora a segunda parte da questão: Mudar passwords de tudo e mais alguma coisa, não vá o Diabo lembrar-se…

Dei maior destaque à subscrição da RSS (acho que já merecia tendo em conta as estatísticas) e evidenciei também a minha presença nos sites da chamada Web Social. Ainda que por vezes o tempo seja pouco para tanta solicitação, são realidades cada vez mais importantes e que merecem o devido destaque.

A mudança no header (assim como o esquema de cores) também não é completamente inocente. É de intenção propositada para reflectir a chegada da época do ano em que me considero mais produtivo e criativo (na minha vida pessoal e profissional os dois conceitos estão por demais interligados).

A janela é efectivamente a minha janela, onde verei a chuva a cair e o dia acordar cinzento. Os ramos, ainda que quase desprovidos de folhas, estão lá, fortes, para ficar. Esperam como sempre, um renascer…

Ainda não é um trabalho finalizado. Faltam ainda alguns ajustes para ficar como deve de ser mas de qualquer forma tentei que o resultado fosse agradável e “usável” para a grande maioria dos visitantes.

Aqui por casa, para além da preocupação da validação do código, fiz ainda o check no IE7 e no Firefox 3.0.3. Aparentemente não noto diferenças o que me satisfaz. Fico à espera de eventuais comentários de utilizadores que por aqui passem (ou tenham instalados) browsers diferentes para me certificar de que está tudo ok.

Sim, eu efectivamente gosto que o meu código valide na W3C. É acima de tudo uma forma de me obrigar a fazer a coisa como deve ser e não cair na tentação de deixar metade à vontade do browser.

O que é que estava a falhar? Não sei. Por mais que me esforçasse, por mais voltas que desse, não havia forma do código validar. Entre a informação de tags por fechar (que nunca encontrei) e as referências invalidas a <br /> em sítios onde não podem existir, quase dava em doido.

Foi por pouco que não abandonei este theme e parti para um qualquer outro, completamente despersonalizado, mas que validasse.

Mas depois pensei que, em muito tempo, este theme actual é o que mais se tem aguentado. E não me refiro às imagens nem ao esquema de cores mas sim à estrutura. A coisa funciona. Sempre funcionou desde o primeiro dia. Era parvoíce desistir além de que, não aguentaria muito tempo sem querer personalizar qualquer theme que aqui usasse e isso iria obviamente levar tempo. Mais noites agarrado ao laptop e a fazer previews sem fim. Não era opção. Não agora.

Voltei ao ataque. Valeu a pena. Já valida outra vez. Ainda há toques a dar mas, que valida valida.

E vocês caros leitores? Preocupam-se com a validação do vosso código?

Voltas e mais voltas pela Internet e pelos vistos há muita gente a queixar-se do mesmo e ainda ninguém chegou a uma conclusão final. Uns dizem que é da cache, outros do plugin, outros dizem que não fazem ideia de qual seja a causa mas que sabem a solução enfim, cada um diz o que quer. Tentei seguir aqueles que me pareciam mais lógicos. Cache do WordPress, plugin, cache do browser, tudo o que não implicasse mexer no código da aplicação pois, se funcionava e deixou de funcionar sem nenhuma alteração à aplicação, em principio não deveria obrigar a nenhuma alteração de fundo… Nada funcionou. Cansei-me. A sério. Se fosse um daqueles erros que dá nas aplicações da Microsoft e que ninguém consegue explicar (tenho em mãos um problema com resources em CMS 2002 que nem queiram saber) a queixa ia direitinho para a Microsoft e esta lá iria disponibilizar os recursos possíveis para resolver o problema. Esperava. A culpa era de alguém que não minha e pouco poderia fazer (não sou programador certo?). Neste caso não pode ser assim. Quando sou eu a sugerir usar uma plataforma open source que mais ninguem usa lá pelo trabalho, se a coisa falha é a mim que me pedem contas. E sou eu que as devo pagar. Vai ser uma noite pêras.

Vá lá então, venha dai uma ajudinha… Enquanto o site muda e não muda (não muda tão cedo quase de certeza), que faço ao raio dos “Apontamentos”?

A resposta está em CMSMatrix. Neste site podemos seleccionar múltiplos sistemas (a lista é enorme) e ele apresenta-nos uma tabela com tudo o que cada um dos CMS’s pode fazer, os requisitos, os custos, enfim, um manancial de informação que nos pode facilitar e muito a escolha. Fica a dica.

A parte do trabalho está dita. Pronto. Já deu para reparar que é muito e que o tempo nunca chega. Não é novidade. Agora a parte da volta ao site. Há uns tempos atrás ganhei coragem e fiz uma transladação da base de dados aqui do site. Para deixar a coisa mais arrumadinha, mais limpinha e organizada. Na altura aproveitei e limpei a referida base de dados de todas as referências ao plugin de estatísticas que aqui corria. E porquê? Porque os conteúdos do site ocupavam cerca de 20 megas na base de dados e as estatísticas ocupavam 170. O plugin que eu usava era o WP-ShortStat. Estava bastante satisfeito com ele é verdade mas só até ao dia em que tive problemas com o backup do site devido ao espaço que o menino ocupava. Conclusão, fiquei sem estatísticas do WordPress. Ok, pensei eu. Vou vivendo com o Google Analytics que dá informação que nunca mais acaba. Sim. Dá. Mas sobre o site em geral. Os plugins existentes para o WordPress dão mais ênfase às funcionalidades do WordPress ou pelo menos parece ser nestes muito mais fácil identificar a informação que é relevante para a análise que se quer fazer ao weblog. E assim sendo voltei a procurar um plugin que satisfizesse essa necessidade. Há muitos. O WordPress Plugins Database lista mais de 80. Os mais famosos são, para além do atrás referido WP-ShortStat, o Stat Traq que é bastante completo mas também pede recursos e com um mais elevado grau de complexidade para uma correcta configuração, o WP-Stat que disponibiliza a informação numa página do site ao invés de o fazer na área reservada à administração do mesmo e o Live Stat que permite ter uma actualização em tempo real de quem está, quem entra e sai do site. No meio de tanta escolha (e atenção que só desenvolvi os mais famosos) acabei por optar pelo WP-SlimStat-ex. Baseado no WP-SlimStat este WP-SlimStat-ex acrescenta-lhe algumas funcionalidades entre elas aquela que me fez optar: Poder limpar a base de dados das estatísticas antigas. Pode parecer uma contradição querer apagar a informação histórica do site mas este plugin permite-me por exemplo remover os indexes da base de dados ou definir um espaço de tempo dentro do qual os dados são mantidos. Informação desde sempre, numero de visitas, pageviews, tempo no site e coisas do género, essa estará sempre disponivel no Google Analytics onde não afectará a performance do browserd.com. A informação do momento, mais rápida e apontada directamente ao que quero saber, fica a cargo do WP-SlimStat-ex.

Já chega de conversa técnica por hoje.

Voltou também a vontade de passear pela net em busca de coisas interessantes e de bastante utilidade tal como algo que descobri enquanto visitava o site de um certo macaco: Quanto vale o meu cadáver? Ora ai está uma boa pergunta para um provável futuro pós-apocalíptico. Parece-me ser bastante útil saber qual o valor que o meu cadáver poderá alcançar no mercado não? Se não o meu, o de alguém… Fiquei contente de saber que o meu cadáver tem o fantástico valor de $4325.00. Não está mal não senhor.

Agora adeus que se faz tarde eu eu tenho que ir trabalhar e daqui até lá ainda são três estações de Metro.

Uma outra alteração de monta é a localização dos “Apontamentos”. Estão mais visiveis, mais acessiveis. A ideia é publicar cada vez mais e melhores daquelas pequenas pérolas.

O layout anda em estudos por isso não se admirem com algumas pequenas alterações que vão aparecendo. Não se admirem também com alguns erros escabrosos que possa aparecer. Façam o favor de mos reportar ok? E digam também de vossa justiça se gostam, se não gostam, se preferiam o outro..