Cibersegurança FAQ: Desenvolvedor web

Versão Beta para testes e avaliações: Aguarde em breve a versão final. É um especialista em cibersegurança e quer contribuir com sua opinião sobre este FAQ? Clique aqui para acessar os Contatos.

Caso não seja possível seguir na íntegra os protocolos recomendados neste projeto, adote ao menos os procedimentos de segurança a seguir, que serão eficazes na contenção da maioria das vulnerabilidades:

  • Usar logins pouco óbvios e senhas fortes (Vide Checklist do Usuário de Internet e FAQ do Usuário da Internet, Questão 8)
  • Conceder função de administrador somente quando imprescindível, limitando ao máximo o número de usuários do website. Criar uma conta de “Editor” para atualizações do website.
  • Escolher uma excelente hospedagem.
  • Escolher temas e plugins de confiança, instalando somente aqueles imprescindíveis e deletando os que não estiverem em uso.
  • Manter tudo sempre atualizado: WordPress, temas, plugins, bem como os softwares do seu próprio computador.
  • Instalar um excelente antivírus no seu computador e mantê-lo sempre atualizado. Recomendamos McAfee.
  • Instalar o plugin Wordfence e configurá-lo para limitar várias tentativas de login. (Veja sugestão de Configuração do Wordfence aqui)
  • Instalar o UpdraftPlus, configurando backups automáticos, realizando o download dos backups e testando-os periodicamente.

Ataques de força bruta parecem vir, em sua maioria, da Rússia, Cazaquistão e Ucrânia. Por isto, muitos desenvolvedores optam por bloquear o acesso destes países aos websites, eliminando grande parte dos problemas.

No caso das GLAMs, que precisam garantir ampla acessibilidade para cumprir sua função social, esta atitude drástica não é recomendada, pois a questão da isonomia de acesso não estaria plenamente contemplada com este bloqueio.

Outro procedimento comum é tentar impedir ou descobrir os dados de quem navega no website de forma anônima. Contudo, as GLAMs têm a obrigação ética de levar o conhecimento à todos, o que incluem pessoas bem intencionadas que podem estar acessando anonimamente o website de países não-democráticos, simplesmente para se instruir.

Isto é especialmente importante no caso, por exemplo, de museus que tratam de temas sensíveis, como holocausto, inquisição, refugiados, meio ambiente e direitos humanos.

As formas de ataque mais comuns aos websites WordPress incluem o envio de pedidos HTTP para o servidor, explorando vulnerabilidades como plugins e temas desatualizados, bem como o ataque de força bruta, que utiliza um robô para tentar adivinhar login e senha dos usuários, especialmente os administradores.

Ataques de força bruta, contudo, não são as formas principais de hackeamento bem sucedido de websites em WordPress, mas sim a existência de vulnerabilidades no core (instalação padrão) do WordPress, temas e plugins. Mantenha tudo sempre atualizado.

Raramente. Tendo em vista que a quase totalidade dos ataques acontecem por robôs e, portanto, atacam websites indistintamente, a adoção destes recursos aqui propostos é uma informação que um bot, por não ser humano, não terá.

Entretanto, se o cracker estiver promovendo um ataque direcionado à uma instituição específica, quanto mais informações o mesmo obtiver sobre o website, melhor (para o cracker). Neste sentido, divulgar publicamente a adoção destes ou de qualquer recurso (temas, plugins, empresas de segurança contratadas, etc.) facilita, sim, a vida do invasor.

Contudo, tenha em mente que “segurança por obscuridade” (vide questão 5 a seguir) é extremamente frágil e ineficaz. É por isto que muitas instituições anunciam em seus blogs a adoção do WordPress ou a contratação de um serviço específico sem grandes reservas.

Segurança por obscuridade é uma estratégia primária e pouco eficaz, que consiste em tentar esconder dados de um invasor, para dificultar a invasão. Estes dados podem ser a versão do WordPress, a página de login, etc.

O fato é que um invasor experiente e obstinado descobrirá isto muito mais coisas a respeito do seu website com grande facilidade e rapidez. Daí a importância de cumprir rígidos protocolos de segurança, ao contrário de tentar esconder aquilo que é tranquilamente revelável por um cracker em poucas horas de investigação.

Por surtir quase nenhum efeito, recomendamos poucas práticas para obscurecer informações, como deletar arquivos desnecessários de instalação, mover o wp-config.php um diretório acima, não utilizar logins óbvios (ex: “admin”) ou alterar o table_prefix do banco de dados no momento da instalação. Para bancos existentes, deixe como está, pois pode causar danos à instalação.

Não, pelo contrário: alguns destes procedimentos podem ser danosos ao website. Como explicamos na questão 5 deste FAQ, segurança por obscuridade não é eficaz.

Somente no momento da instalação é possível realizar alguns procedimentos de obscuridade, como alterar o prefixo do banco de dados. Jamais realize o procedimento posteriormente, com códigos e plugins para alterar o prefixo.

No caso de um banco de dados já estabelecido com table_prefix “wp_”, deixar como está. A alteração coloca a integridade do banco de dados em risco por quase nenhum resultado real de segurança. Qualquer cracker eficiente descobrirá este prefixo rapidamente, bem como os demais dados, como a versão do WordPress.

Não. Via cPanel é extremamente fácil realizar o procedimento, contudo, isto pode quebrar funcionalidades (ex: AJAX) e dificultar a navegação de usuários comuns não logados, que podem se deparar com um pop up solicitando senha sem explicação alguma.

Visitantes comuns também utilizam recursos que acessam este diretório, não somente Administradores. Portanto, não adicione senha!

Depende. Se os servidores da sua instituição possuem equipamentos com boa manutenção, sistemas de backups confiáveis, suporte 24/7 (vinte e quatro horas por dia, sete dias por semana), softwares e linguagens sempre na última versão, dentre outros aspectos listados no Checklist Dev Selecionando a Hospedagem, então você pode hospedar o website nos servidores próprios.

Entretanto, não é esta a realidade que temos observados nas instituições GLAM brasileiras, pelo contrário. É extremamente comum, por exemplo, não ser possível atualizar o WordPress para a última versão por incompatibilidade com os servidores, colocando em grande risco a segurança dos sistemas. Também é comum os setores de TI, em especial de serviço público, não possuírem suporte 24/7 e demorarem dias, até semanas, para responder à um chamado. A manutenção dos sistemas, com frequência, tira as instalações do ar: não há “poder de fogo” para manter tudo funcionando durante os reparos. Por fim, seja por questões de sobrecarga de trabalho, seja por desconhecimento, diversos protocolos de segurança não raro são completamente ignorados, como a realização de backups frequentes.

Um outro aspecto cultural bastante comum em alguns países, dentre estes o Brasil, é a centralização de poderes e informações do pessoal de informática. Alguns setores de TI têm dificuldade de delegar e de liberar acessos e funções à profissionais externos ao setor, o que burocratiza a manutenção dos websites e, por consequência, compromete a segurança das instalações WordPress. Se, por um lado, as intenções podem ser boas (proteger os sistemas), essa desconfiança acaba gerando o efeito oposto.

Não é possível gerir um sistema seguro e oferecer um serviço de qualidade nestas condições. Nesses casos, sem dúvida alguma, contrate uma empresa e terceirize este serviço. Veja aqui neste Checklist como selecionar um bom provedor de hospedagem.

Versão inicial de autoria de Ana Cecília Rocha Veiga.