7 Vulnerabilidades Seus plugins de segurança do WordPress não podem protegê -lo (e como corrigi -los manualmente)

Se você é como a maioria dos usuários do WordPress, provavelmente instalou um plug -in de segurança para ajudar a manter seu site em segurança. Este é um excelente primeiro passo e lidará com grande parte da sua proteção-especialmente se você ativou a autenticação de dois fatores.

Mas observe que enfatizei o primeiro passo. Eu fiz isso deliberadamente porque muitas pessoas pensam que é o único passo que eles precisam dar. Se você realmente se importa com a segurança do seu site, não deveria ser.

A boa notícia é que, com alguma configuração manual de luz, você pode aprimorar sua segurança do WordPress no nível do servidor e tornar seu site significativamente mais resistente a ataques. Como um bônus adicional, você se sentirá como um especialista em segurança do WordPress ao fazê -lo - sem dúvida a parte mais importante de todo o processo. 😉

Portanto, se você estiver pronto para se transformar de um usuário casual do WordPress em um profissional e tornar seu site à prova de balas, vamos começar.

Caixa de ferramentas

Acredite ou não, para fazer isso, você só precisará de três (possivelmente quatro) ferramentas.

• Verificação do site Sucuri : ferramenta gratuita para executar sua varredura inicial e verificar suas alterações.
• Cabeçalhos de segurança : outra ferramenta gratuita que fornece feedback detalhado sobre as configurações de segurança do site.
• Acesso ao seu painel de controle de hospedagem : estou usando o CPALEL, mas abordarei o que fazer se tiver outra coisa.
• Um editor de texto (talvez): seu painel de controle de hospedagem provavelmente possui um incorporado, para que isso possa não ser necessário, mas estou listando aqui apenas por precaução.

A coisa mais complicada da lista acima será acessar o CPALEL. Não é difícil, mas toda empresa de hospedagem tem sua própria maneira de fazê -lo e, se você nunca fez isso antes, precisa descobrir.

A maneira mais fácil de abordá -lo (se você não tiver certeza) é ir à base de conhecimento do site da sua empresa de hospedagem e pesquisar "cpanel". Se isso não o levar a lugar nenhum, procure o suporte ao cliente.

Executando suas verificações iniciais de segurança

Antes de começar a mexer no código do seu site, primeiro você deseja verificar como ele atualmente lida com a segurança. As mudanças que vou mostrar que você é muito específico, então você deseja garantir que elas sejam de fato necessárias para o seu site.

Na maioria dos casos, especialmente se você confiar na hospedagem compartilhada - precisará fazê -los. No entanto, em alguns planos de hospedagem gerenciados de nível superior, é possível que seu host possa fazer os ajustes em seu nome. Portanto, por que executar essas varreduras de antemão é importante.

Verificação do site de Sucuri

Para começar, vá até a ferramenta de verificação do site da Sucuri e cole o endereço do seu site no scanner:

Clique em Enviar e deixe Sucuri trabalhar sua mágica.

Para os propósitos deste tutorial, intencionalmente desprotegi meu site pessoal para mostrar como é a configuração padrão do WordPress (antes de fazer as edições):

Como você pode ver, a varredura revelou cinco lacunas de segurança que você veria em qualquer configuração típica do WordPress. Vou explicar o que eles significam em um momento.

Cabeçalhos de segurança

Enquanto Sucuri nos deu uma boa visão panorâmica, vamos ficar realmente nerds por um momento e verificar o que os cabeçalhos de segurança têm a dizer. O primeiro passo é exatamente o mesmo que Sucuri - basta digitar ou colar o endereço do seu site na ferramenta e clique em Digitalizar .

Dependendo do tamanho do seu site, os resultados podem levar de um segundo a ... bem, mais tempo. 😅 Meu resultado inicial parecia assim:

Todas as cores vermelhas e o g gigante podem parecer um pouco intimidadoras, mas na verdade está nos dando algumas informações muito úteis. Cada uma dessas marcas vermelhas está apontando um cabeçalho de segurança ausente que torna seu site mais vulnerável.

Eu também quero reafirmar que você verá esses resultados , mesmo com o WordFence ou algum outro plug -in de segurança instalado no seu site. A exceção é se sua empresa de hospedagem ou outra pessoa fizer as edições que faremos antes de você.

Compreendendo todas as bandeiras vermelhas

Agora, vamos organizar tudo o que nossos exames encontrados - há alguma sobreposição entre as ferramentas, mas cada uma delas também capturou alguns problemas únicos.

Emitem ambas as ferramentas capturadas 🤝

• A política de segurança de conteúdo está ausente completamente-o que significa que não há nada controlando quais scripts e conteúdo podem carregar no site. ℹ️ Por que isso é ruim? Sem esses controles, o código malicioso pode ser injetado e executado em suas páginas, potencialmente comprometendo seu site e visitantes.
• Falta o X-Frame-opções , o que deixa o site vulnerável a tentativas de roubo de cliques por meio de incorporação não autorizada. ℹ️ Por que isso é ruim? O ClickJacking é quando os invasores induzem os usuários a clicar em algo diferente do que vêem, geralmente colocando invisivelmente o seu site legítimo sob conteúdo malicioso.
• As opções do tipo conteúdo não estão definidas, o que pode permitir ataques de confusão do tipo MIME. ℹ️ Por que isso é ruim? A confusão do tipo MIME ocorre quando um navegador é enganado a tratar um tipo de arquivo como outro, potencialmente executando o código prejudicial.

As descobertas únicas de Sucuri 🔍

• A versão PHP é visível nos cabeçalhos HTTP. ℹ️ Por que isso é ruim? Quando os atacantes podem ver sua versão PHP, eles sabem exatamente quais vulnerabilidades podem funcionar contra o seu site - como ter um plano do seu sistema de segurança.

INSIGHTS EXTRA DE CABEÇO DE SEGURANÇA 🔬

• Nenhuma política de referenciador em vigor. ℹ️ Por que isso é ruim? Sem essa política, seu site pode vazar informações confidenciais sobre os padrões de navegação de seus usuários para outros sites.
• A política de permissões não foi configurada. ℹ️ Por que isso é ruim? Isso significa que qualquer página do seu site pode solicitar acesso às câmeras, microfones ou dados de localização dos visitantes sem restrições.
• Falta a segurança rigorosa . ℹ️ Por que isso é ruim? Sem esse cabeçalho, as conexões com o seu site podem fazer o downgrade de HTTPs para HTTP, tornando -os vulneráveis ​​à interceptação.

A beleza de corrigir esses problemas é que você não precisa entender todos os detalhes técnicos - você só precisa implementar as soluções corretamente. O que, convenientemente, é exatamente o que estamos prestes a fazer.

Encontrando o seu caminho para os arquivos do servidor

Supondo que você tenha cpanel como eu, clique no gerenciador de arquivos no seu painel:

Se você estiver usando algo diferente do CPALEL, pode baixar o FileZilla (é gratuito e aqui está um guia rápido sobre como usá -lo). Depois de instalá -lo, use seus detalhes FTP do painel de hospedagem para conectar -se ao seu servidor:

• Host: ftp.yoursite.com - Verifique se esse é o endereço correto na seção FTP do cpanel
• Nome de usuário: your-username
• Senha: your-password
• Porta: 21 - Verifique também se esta é a porta que sua configuração está usando (FTP em cpanel)

Alguns hosts também fornecerão a você sua própria alternativa cpanel que pode funcionar da mesma forma. Em outras palavras, talvez você não precise usar o Filezilla. Se você não tiver certeza, pergunte ao suporte ao cliente.

Localizando o arquivo .htaccess

Depois de fazer login, você verá algo que se parece com o navegador de arquivos do seu computador. Precisamos encontrar um arquivo específico chamado .htaccess - ele controla como o servidor lida com várias configurações de segurança. A maneira mais fácil de descobrir é usar a função de pesquisa do CPanel File Manager no canto superior direito. Os usuários da FileZilla podem confiar em um recurso semelhante.

Digite .htaccess na janela e clique em Go .

Se você tiver apenas um site vinculado à sua conta de hospedagem, isso deve ser bastante direto. Se você possui vários sites, certifique -se de clicar no arquivo .htaccess associado ao site para o qual você fará essas edições.

Outro detalhe potencial do TripWire a observar é o fato de que, mesmo em uma única configuração do site, você provavelmente ainda terá outros arquivos .htaccess -ish. Basicamente, arquivos que têm .htaccess em seu nome, mas também outras palavras ou caracteres.

Você não quer nenhum deles. Você só quer o que é chamado .htaccess e nada mais.

Adicionando código ao arquivo .htaccess para corrigir os problemas de segurança

Depois de localizar o arquivo, você desejará baixá -lo antes de fazer edições. Dessa forma, se algo der errado, você terá um backup que poderá voltar para a pasta.

Nada deve dar errado, mas melhor estar seguro do que você sabe o que .

Depois que seu backup for baixado com segurança, você poderá prosseguir com a edição do arquivo .htaccess . No gerenciador de arquivos da CPALEL, clique com o botão direito do mouse no arquivo e selecione Editar . Se você estiver usando o FileZilla, clique com o botão direito do mouse e escolha Exibir/Editar -isso abrirá o arquivo no seu editor de texto padrão.

A próxima parte é o ápice de toda essa missão. É aqui que você se sente como um especialista em segurança do WordPress por um breve momento. Aproveite enquanto dura.

Onde colocar o código no seu arquivo .htaccess 👨🏻‍💻

As instalações do WordPress normalmente têm várias seções aqui, marcadas por comentários que começam com # BEGIN e # END .

Procure uma linha que diga o seguinte:

 # END WordPress

A abordagem mais segura é adicionar os cabeçalhos de segurança logo depois disso . Se você não vir a linha exata ou, se não tiver certeza, poderá adicionar os cabeçalhos no final do arquivo - apenas deixe uma linha em branco entre qualquer código existente e as novas adições.

Aqui está o código:

 # BEGIN Security Headers Header unset X-Powered-By php_flag expose_php Off Header set X-Frame-Options "SAMEORIGIN" Header set X-Content-Type-Options "nosniff" Header set Strict-Transport-Security "max-age=31536000; includeSubDomains" Header set Content-Security-Policy "default-src 'self' 'unsafe-inline' 'unsafe-eval' *; script-src 'self' 'unsafe-inline' 'unsafe-eval' * data: blob:; style-src 'self' 'unsafe-inline' *; img-src 'self' data: *; frame-src 'self' *; font-src 'self' data: *; media-src 'self' *;" Header set Referrer-Policy "strict-origin-when-cross-origin" Header set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()" # END Security Headers

Depois de terminar, clique em Salvar alterações no canto superior direito. Para usuários que não são do CPALEL, encontre o que o botão equivalente estiver em sua própria interface.

Com isso fora do caminho, você pode executar as varreduras de segurança novamente para ver o impacto de suas alterações.

Re-execução de verificações de segurança

Primeiro, verifique os cabeçalhos de segurança:

Não é tão ruim, hein?

Fomos de um F para um A.

Fale sobre um brilho!

Todo cabeçalho de segurança que configuramos está sendo exibido de maneira adequada.

Em seguida, vamos verificar Sucuri:

Muito melhor, mas estranhamente, ainda existem dois avisos.

O primeiro é realmente um falso positivo, pois sei que meu site tem o WordFence em execução. Não tenho nenhuma explicação para isso, exceto que Sucuri não reconhece o WordFence por qualquer motivo. Se você vir o mesmo aviso e também sabe que tem um WAF instalado, basta ignorá -lo.

A segunda mensagem é um pouco diferente. Ele também aparece no resultado dos cabeçalhos de segurança, abaixo do relatório estelar de uma nota que eu já mostrei:

Aqui está a coisa:

Apesar de ser sinalizado como "perigoso" por ambas as ferramentas, o uso de ingressos inseguros é realmente perfeitamente bom.

O WordPress precisa de determinadas habilidades JavaScript e CSS para funcionar - especialmente para o editor de blocos e os plugins. Portanto, embora existam maneiras tecnicamente mais rigorosas de lidar com isso (é disso que se trata essas referências a não -ces ), isso quebraria seu site. Literalmente.

A melhor analogia aqui é pensar em uma casa. Tecnicamente, você pode tornar sua casa "mais segura", vendendo todas as suas janelas e portas com cimento, mas isso tornaria sua casa não funcional. Esta é a mesma ideia.

Embrulhando

As capturas de tela antes e depois das varreduras de segurança que você viu são a prova disso.

E agora que você leu este tutorial, você também pode levar sua segurança do WordPress de "Plugin Protected" para "Nível de servidor protegido".

Em uma nota final, como prática recomendada de segurança, também recomendo fazer o seguinte:

• Execute essas varreduras de segurança mensalmente.
• Mantenha a documentação de suas configurações de segurança.
• Teste após as principais atualizações do WordPress para garantir que tudo ainda esteja funcionando como pretendido.
• Altere seu endereço de página de login.
• Limite as tentativas de login.
• Ative a autenticação de dois fatores (ou 2FA para abreviar).
• Mantenha os plugins e os temas atualizados e excluam os que você não usa.

... e muito mais. A segurança do WordPress pode levá -lo a uma toca de coelho profunda, mas o que você aprendeu aqui é suficiente para iniciar e protegerá seu site da maioria dos ataques.

Você tem alguma dúvida? Deixe -me saber nos comentários. Eu ficaria feliz em ajudá -lo.