Em resumo: um site estático é composto por ficheiros HTML, CSS e de imagem prontos, que o servidor web apenas entrega. Como no servidor não correm PHP nem base de dados, vulnerabilidades como o PHP2Shell, a SQL injection ou webshells introduzidas deixam em grande parte de ser um risco. Para a segurança de um site estático contam, em contrapartida, outras coisas: acessos protegidos ao alojamento, ao domínio e às ferramentas de compilação, dependências mantidas e serviços de terceiros escolhidos com cuidado. Adequa-se sobretudo a sites que raramente são alterados e não precisam de contas de clientes.
Porque é que a pergunta se coloca agora
O PHP2Shell mostrou a muitas empresas quanto depende de um único componente. Um site de empresa com dez páginas, atualizado uma vez por trimestre, corria no mesmo PHP que uma grande loja online e estava assim exposto à mesma vulnerabilidade crítica. Segundo notícias dos media, até autoridades e municípios desligaram sites por precaução.
A pergunta surge naturalmente: precisamos sequer de PHP no servidor para o nosso site? Em muitas pequenas e médias empresas, a resposta honesta é: para a entrega, muitas vezes não. O PHP gera a página de novo a cada acesso, embora o conteúdo não mude há semanas. Como isto decorre tecnicamente, descreve-o Como o PHP gera uma página web. O que significa a própria vulnerabilidade, explica-o O que é o PHP2Shell?.
Como funciona um site estático
Num site estático, a página não é gerada na visita, mas antes. Um gerador de páginas estáticas, como o Hugo, o Jekyll ou o Eleventy, pega em textos, imagens e modelos e constrói com eles ficheiros prontos. Estes ficheiros são carregados para um servidor web simples ou para uma rede de entrega de conteúdos (content delivery network), isto é, uma rede de entrega distribuída.
Para os editores, pode haver à frente uma ferramenta de edição que recebe as alterações e desencadeia a reconstrução. Em parte, usa-se para isso um chamado CMS headless, que apenas gere conteúdos e não precisa de ser acessível ao público. O visitante não vê nada disto; recebe apenas os ficheiros prontos.
Site estático e segurança em comparação
| Critério | CMS dinâmico em PHP | Site estático |
|---|---|---|
| Lógica de programa no servidor público | Sim, a cada acesso | Não |
| Risco por vulnerabilidades no interpretador PHP | Sim, como no PHP2Shell | Deixa de existir no servidor de entrega |
| Base de dados ligada ao público | Sim | Não |
| Portas de entrada típicas | Plugins, início de sessão de administração, uploads, servidor | Acessos ao alojamento, ao domínio, ao sistema de compilação, serviços de terceiros |
| Formulários, pesquisa, conta de cliente | Integrados | Só através de serviços externos ou funções separadas |
| Esforço de manutenção para editores | Baixo, interface habitual | Depende da ferramenta editorial |
| Manutenção | Atualizações regulares do CMS, dos plugins e do PHP | Atualizações das ferramentas de compilação e das dependências |
| Adequação | Lojas, portais, muitos editores, alterações frequentes | Sites de empresas, páginas de destino, documentação |
A tabela mostra: a superfície de ataque desloca-se, não desaparece. Em vez de um servidor PHP acessível ao público, tem de proteger a conta no fornecedor de alojamento, o domínio, o pipeline de compilação e, se for o caso, a ferramenta editorial.
Que riscos permanecem nos sites estáticos
Primeiro, os acessos. Quem assume a conta de alojamento, o acesso ao domínio ou o repositório de código pode alterar o site, sem qualquer PHP. A autenticação de dois fatores e as contas pessoais são por isso obrigatórias.
Segundo, as dependências. Os geradores e modelos trazem muitas vezes muitos pacotes, por exemplo do npm. Estes têm de ser mantidos atualizados, porque uma dependência comprometida pode, na compilação, escrever código malicioso nos ficheiros prontos. Como organizar isto, descreve-o Manter as dependências atualizadas.
Terceiro, os serviços de terceiros. Serviços de formulários, funções de pesquisa, ferramentas de análise e scripts integrados correm no navegador dos visitantes ou em servidores alheios. Cada um destes serviços é uma relação de confiança, também do ponto de vista da proteção de dados.
Quarto, o lado do navegador. Também uma página estática deve definir cabeçalhos de segurança, por exemplo uma Content-Security-Policy, que determina que scripts podem ser carregados. As bases estão em Cabeçalhos de segurança para sites.
Antes de mudar, verifique que funções o seu site realmente usa. Muitas vezes são menos do que se pensa: páginas, imagens, um formulário de contacto. Então o caminho para o site estático é mais curto do que parece à primeira vista.
Para quem compensa a mudança e para quem não
Um site estático é muito adequado para páginas de empresa de dimensão reduzida, páginas de destino de campanhas, documentação de produtos e páginas de carreiras. A mudança compensa sobretudo se o site atual corre numa versão antiga do PHP e uma atualização estaria de qualquer modo pendente.
Adequa-se menos a lojas online, portais de clientes, sistemas de reservas e sites com muitos editores que publicam todos os dias. Aqui continua a fazer sentido um sistema dinâmico. Uma forma mista pode ajudar: a loja permanece dinâmica e é bem protegida com hardening, guias e páginas da empresa são entregues de forma estática.
Uma vantagem muitas vezes subestimada mostra-se numa emergência. Como os ficheiros prontos podem ser reconstruídos a qualquer momento a partir de modelos e conteúdos, um site manipulado pode ser rapidamente reposto num estado conhecido e limpo. O pré-requisito é que conteúdos e modelos estejam num repositório protegido, que as alterações sejam registadas de forma rastreável e que ninguém edite os ficheiros diretamente no servidor.
Para a mudança, não precisa necessariamente de um prestador de serviços de segurança; pode assumi-la uma agência ou um programador. Se o site anterior esteve comprometido, os conteúdos devem, porém, ser verificados antes da migração. Disso trata Mudar de CMS depois do ataque?.
Como ajuda concretamente a PHP SOS?
- Verificamos que funções o seu site realmente precisa e dizemos abertamente se uma solução estática é adequada.
- Numa mudança, protegemos os acessos ao alojamento, ao domínio e ao sistema de compilação com autenticação de dois fatores e contas pessoais.
- Verificamos serviços de terceiros e definimos cabeçalhos de segurança, para que o novo site fique também bem protegido no navegador.
- Para os sistemas PHP que permanecem, assumimos atualizações e vigilância no contrato de manutenção de segurança.
Conclusão
Um site estático não é uma panaceia, mas para muitos sites de empresa é a forma mais simples de se livrar de toda uma classe de riscos. Onde não corre PHP, o PHP2Shell nada pode fazer. A segurança ganha só se mantém, porém, se os acessos, as dependências e os serviços de terceiros forem levados tão a sério como antes o servidor.
Perguntas frequentes
Um site estático também pode ser invadido?
Sim. Desaparece a lógica de programa do lado do servidor e, com ela, uma grande classe de ataques. Continuam atacáveis os acessos ao alojamento, ao domínio e ao sistema de compilação, os serviços de terceiros integrados e as ferramentas com que a página é gerada.
Um site estático pode ter formulários de contacto?
Sim, através de um serviço externo de formulários ou de uma pequena função operada em separado. O tratamento dos dados fica então a cargo desse serviço. Esclareça a proteção de dados e a subcontratação do tratamento antes de o integrar.
Os editores podem manter um site estático por si próprios?
Com uma ferramenta editorial adequada, sim. Muitas soluções oferecem uma interface de edição, a partir da qual a página é depois gerada de novo. Para equipas que alteram muitos conteúdos todos os dias, um CMS clássico é porém muitas vezes mais cómodo.
Compensa a mudança para uma loja online?
Na maioria dos casos, não por inteiro. Carrinho de compras, conta de cliente e pagamento precisam de lógica do lado do servidor. É possível entregar partes como guias ou páginas da empresa de forma estática e operar a loja em separado.