Um pouco mais sobre a atualização crítica do Magento

Muito está se falando nesses dias sobre a “atualização crítica do Magento”, especialmente depois que os milhares de lojistas que usam a plataforma ficaram assustados quando se depararam com uma grande mensagem ao abrir seu painel, algo como “corra para atualizar sua loja, pois ela será invadida”.

Quem quiser saber como fazer essa atualização, lamento, mas esse não é o post; já há diversos artigos falando sobre como fazer isso pela internet, tanto em inglês como em português. Minha ideia aqui é, em poucas palavras, trazer algumas ideias sobre essa atualização e o que pode ser aprendido para as próximas.

Sim, o Magento não é perfeito. Ainda que seja bastante seguro e estável, sempre existirão brechas de segurança que podem ser exploradas. Quando essas brechas são descobertas, é preciso corrigi-las. Isso já aconteceu antes e continuará acontecendo, até o “fim dos tempos”.

O primeiro ponto a ser trabalhado aqui é a velha questão de se você pode ou não pode mexer no core. O patch divulgado pela Magento modifica três a seis arquivos do core (conforme a versão de sua loja), o que significa que eles são alterados (se você aplicar o patch via SSH) e totalmente sobreescritos se você optar por subir um novo arquivo via FTP.

Se você (ou seu desenvolvedor) alterou justamente esses arquivos, é bem provável que você tenha problemas. Se você não se lembra que fez isso, perderá bastante tempo. Se você tem módulos que fazem uso das classes existentes nesses arquivos e elas foram alteradas, você terá problemas. Aí, os problemas não serão porque você atualizou a loja mas porque sua base estava corrompida. É preciso verificar se esses arquivos não foram alterados e estar muito atento logo após a atualização, para não sair caçando o criminoso errado.

Outra coisa interessante é justamente essa questão da aplicação do patch. A Magento soltou apenas patches em formato .sh, que requer acesso ao terminal do servidor e permissões para rodar scripts. Eu sou capaz de afirmar que 70% das lojas Magento no Brasil não tem acesso SSH, o que as impede de aplicar esse patch por conta própria. Dada a qualidade dos provedores de hospedagem nacionais, eles não se preocuparão com isso e os lojistas ficarão na mão.

Porém, mais interessante do que isso, é que a princípio, a Magento poderia ter soltado essa atualização na forma de um pacote de arquivos. Está longe da minha compreensão discutir o porquê dessa escolha, mas graças à comunidade, mesmo esses lojistas poderão atualizar suas lojas. Entre as saídas possíveis está “embutir o comando de rodar o script dentro de um arquivo PHP”, que pode ser colocado no servidor via FTP e os próprios arquivos atualizados, como mostrado no site Magentary. De todo modo, não são soluções muito simples para quem não tem conhecimento na área, o que me faz reforçar a recomendação de contar com suporte de especialistas!

O terceiro ponto: mesmo lojas já atualizadas (e você pode verificar se sua loja está atualizada, visitando este site) receberam a mensagem de “corram para atualizar” por pelo menos mais duas vezes. Isso mesmo já atualizadas. Ao invés de dizer algo como “SE você ainda não atualizou, siga esses procedimentos” e explicar para o lojista (mesmo em inglês) o que deve ser feito, a mensagem diz simplesmente a mesma coisa, como um papagaio a repetir as coisas ditas para ele. É claro que isso só ajudou a deixar lojistas mais apavorados.

Era muito mais prático se essas mensagens fossem esclarecedoras, escritas para lojistas, em sua linguagem. Mas isso seria esperar demais, não?

Penúltimo ponto: a surpresa era que esse patch – SUPEE5344 – já estava disponível desde fevereiro. O SUPEE1533 foi lançado há mais de seis meses. Até agora, ninguém se preocupou. O que mudou? Segundo a Magento, uma revista especializada divulgaria na semana passada detalhes sobre a brecha de segurança – que consiste na possibilidade de, a partir de um dos arquivos que controla as requisições Ajax, ganhar acesso a diversas informações da loja, como o cadastro completo de clientes e dados de cartão de crédito (para quem armazena dados de cartão de crédito dentro do Magento, é óbvio).

Porta arrombada, corra para colocar a tranca. Detalhe: já temos lojas invadidas pelo mundo e conversando com um parceiro comercial na última quinta-feira, ele mostrou ao menos uma loja invadida. O estrago não foi grande mas foi preciso corrigir o problema rapidamente.

Pra concluir, há alguns anos postei um artigo falando sobre como melhorar a segurança do Magento. Um dos itens falava sobre mudar a URL do painel de administração. Até onde entendi, essa brecha de segurança só consegue ser explorada se o hacker souber o endereço do painel de administração. Sempre teoricamente, se sua loja utiliza outro endereço, a chance de ser atacada é praticamente nula.

A luta não termina aqui, é preciso manter as lojas atualizadas, implantar as correções, utilizar pequenas técnicas para aumentar a segurança e ainda assim, sempre teremos um pequeno risco. Lembre-se: uma loja Magento não é pra ser construída uma vez e depois abandonada. Se você compra um carro, é preciso revisões anuais, não? Com plataformas de e-commerce é a mesma coisa.