php

Vulnerabilidade no acesso de administrador do WP

Hoje em dia é natural ter diferentes ambientes rodando uma mesma aplicação. Para o meu blog por exemplo mantenho três ambientes, “Desenvolvimento”(aka localhost), Homologação e Produção.

Modificando um plugin para o wordpress neste final de semana, me deparei com um fato interessante. Estava logado no localhost(que está configurado como virtualhost apontando para eliasgranja.com) editando algumas configurações. Decidi conferir se as mudanças batiam com os settings de produção. Estava “deslogado” do ambiente, mas resolvi acessar diretamente pela URL de administração. Por algum motivo estranho consegui entrar diretamente na seção de administrador.  Acreditando fielmente que eu estava ficando doido acessei meu site no Chrome para fazer um teste. Garanti que não estava logado em produção, liguei o localhost e me loguei. Logo após desliguei o apache, apontei o dominio para o local certo e então acessei produção e magicamente estava logado.

Fiquei em estado de alarme, já que esse tipo de erro nos cookies é algo perigoso, principalmente em ambientes corporativos onde nem todos que tem acesso ao ambiente de desenvolvimento deveria ter ao de produção.

Fui estudar como o wp criava seus cookies e achei o seguinte trecho de código no arquivo wp-config.php.

Pouco acima deste trecho existe um comentário dizendo para trocar esses valores utilizando a ferramenta do wordpress disponível no endereço “https://api.wordpress.org/secret-key/1.1/salt/“. Assim, após trocar estes dados no wordpress local refiz o teste acima e não consegui ser redirecionado diretamente para o painel de administração em produção.

Resumindo, o sistema de cookies do wordpress se baseia nessas keys para criar os cookies de login, assim elas devem ser únicas para cada “instância” da aplicação.

Minha recomendação é gerar as chaves de autenticação diferentes para cada ambiente, evitando assim que usuários sem permissão de acesso em outros ambientes acessem o painel de administração de seu blog. No meu caso, por exemplo, eu gerei um código diferente para os ambientes de produção, homologação e produção. Assim evito por exemplo de algum amigo que venha a desenvolver para o meu blog tenha acesso a ele em produção pelo simples fato de ter o código do meu wordpress. Além disso, caso tenha deixado o seu blog logado em algum ambiente público, como na faculdade, basta você fazer o mesmo procedimento de trocar as keys que automaticamente forçará todos os usuários logados a entrar com username/password novamente.

[SLIDES] Internacionalização com o Drupal

Na empresa onde trabalho temos o costume de toda a segunda-feira separar uma hora do dia para alguém ensinar ao grupo alguma matéria que envolva ferramentas do nosso trabalho. Já que estamos trabalhando com drupal 6 para nosso cliente, a matéria que requisitaram para mim foi Internacionalização com o Drupal.
A matéria está num ods e em inglês, a parte prática da coisa foi feita na hora, porém acredito que a parte teórica esteja boa o suficiente para apresentar o caminho das pedras.
O conteúdo foi baseado no livro “Drupal….”  e em vivências dentro do projeto.
Para o bem ou para o mau não deixem de comentar.

Baixar i18n_drupal.

[]‘s

Uma visão geral de Hooks

Comecei recentemente a trabalhar com programação para aplicações web com Drupal e durante o treinamento/leitura de materiais sobre esse CMS o que eu mais via era a palavra hooks, mas o que são hooks?

O conceito lembra muito um event listener, pois é executado quando uma “ação” acontece. Porém a ideia por trás dele é interceptar funções, mensagens e eventos de componentes do software e alterar eles conforme a vontade do programador.

Então se eu quero adicionar uma funcionalidade ao core do Drupal, ao invés de eu modificar o código e ter que verificar erros/modificar novamente a cada atualização, eu posso usar uma hook. O próprio Drupal tratará de executar a minha função hook quando for o momento certo e ela alterará o core da forma que eu desejar/for permitido.

Para criarmos uma no Drupal, basta que criar uma função com o nome do modulo “underline” nome da hook, por exemplo se quisermos alterar o menu do Drupal para o nosso módulo “fotos”, basta fazer: “function fotos_modulo(){}” e fazer as modificações necessárias de acordo com a api do framework.

Hooks também podem ser muito úteis para debugar códigos, emular interação com o usuário e até mesmo gerar códigos maliciosos.

Além do Drupal, o Emacs também usa hooks para definir os “modes”(como php-mode). Porém a forma de faze-lo é um pouco diferente por estarmos falando de uma linguagem funcional. Caso fique interessado nas hooks de emacs lisp, aqui tem uma introdução legal ou se quiser saber sobre as hooks do Drupal tem esse do site oficial.

Importando códigos em php

Não sei se é o caso de todo mundo, mas quando aprendi php, o aprendi da forma mais suja possível. Sempre usava programação funcional e algumas vezes coisas das quais não me orgulho muito. Por causa disso, a forma como aprendi a importar código foi usando include e nem imaginava que haveria outras formas.

Quando conheci o paradigma(ou sub-paradigma) de orientação a objetos tentei traze-lo para o php. Mas notei que os includes necessários para fazer duas classes funcionarem juntas estavam se repetindo e dando erro de reescrita de funções.

Mais tarde fiquei conhecendo as outras três maneiras de importar códigos em php, que são:

  1. include()
    Tenta importar o arquivo que foi instruído a fazer, caso não o encontre ele é simplesmente ignorado. Caso seja um arquivo de funções e que você use alguma delas, você terá o erro alertando da falta da definição dela.
  2. require()
    Tenta importar o arquivo, caso não o encontre ele “mata” a aplicação e o interpretador para de rodar. Tem funcionalidade igual ao de um include() or die().
  3. include_once()
    Mesma funcionalidade do include, exceto que ele verifica se o arquivo já foi incluído antes, caso fora ele não faz nada.
  4. require_once()
    Basicamente a mesma coisa que o include_once, porém trava se o arquivo não foi encontrado e nem fora incluído antes.

Para classes sempre escolho usar o include_once() ou o require_once() para evitar redefinir classes, porém vejo mais gente usando o require_once() do que o include_once(), já para adicionar conteúdo estáticos, como html ou imagens, prefiro usar o include().

 Scroll to top