Em resumo: um teste de intrusão à sua aplicação PHP mostra que vulnerabilidades um atacante poderia realmente explorar antes de alguém o fazer. Em conjunto com parceiros especializados, verificamos a aplicação e o servidor num âmbito acordado por escrito e entregamos um relatório com medidas priorizadas. Depois da correção, verificamos num reteste se as vulnerabilidades foram fechadas.
Porque faz sentido um teste de intrusão para aplicações PHP
O PHP2Shell mostrou que até a base de uma aplicação, o próprio PHP, pode conter uma vulnerabilidade crítica. A maior parte das intrusões em aplicações PHP faz-se, porém, através de fraquezas conhecidas no código próprio ou na configuração: SQL injection, cross-site scripting, uploads de ficheiros inseguros, sessões fracas, dependências desatualizadas ou áreas de administração abertas. O OWASP Top 10 resume estas categorias.
Um olhar independente, vindo de fora, encontra o que no dia a dia passa despercebido. Para a administração e a supervisão, fornece uma base sólida para avaliar riscos e aplicar o orçamento de forma dirigida. Para os programadores, é uma lista de trabalho concreta.
Auditoria ou teste de intrusão: o que lhe convém?
| Forma | O que é verificado | Adequado quando |
|---|---|---|
| Auditoria de configuração | Servidor, PHP, servidor web, acessos, cópias de segurança | Quer conhecer o estado da infraestrutura |
| Revisão de código | Código-fonte da aplicação, com acesso | Existem desenvolvimentos próprios ou adaptações maiores |
| Teste de intrusão black-box | Aplicação a partir do exterior, sem conhecimento prévio | Quer ver a perspetiva de um atacante externo |
| Teste de intrusão grey-box/white-box | Aplicação com contas de teste ou código | Quer encontrar o máximo possível em tempo limitado |
Muitas vezes, faz sentido uma combinação, por exemplo uma auditoria de configuração do servidor em conjunto com um teste grey-box da aplicação. Um teste black-box puro parece realista, mas consome muito tempo na exploração. Com contas de teste e conhecimento da estrutura, os avaliadores encontram, no mesmo tempo, em regra mais vulnerabilidades.
Além da aplicação, vale a pena olhar para o ambiente: que versão do PHP corre, as interfaces de administração estão acessíveis publicamente, há cópias de segurança no diretório web, as dependências estão atualizadas? Estes pontos verificamo-los também na auditoria, porque na prática pesam muitas vezes mais do que um erro isolado no código.
Qual é o momento certo para um teste?
Um teste de intrusão traz o máximo quando ocorre num ponto adequado do ciclo de vida da aplicação. Ocasiões típicas são:
- antes do lançamento de uma nova aplicação, loja ou portal de clientes
- após alterações maiores, por exemplo novos meios de pagamento, interfaces ou métodos de início de sessão
- após um incidente, quando a limpeza e o hardening estão concluídos e quer um controlo independente
- a intervalos regulares, quando clientes, parceiros ou a sua gestão de risco o exigem
Pouco útil é um teste enquanto houver vulnerabilidades conhecidas em aberto. Quem ainda opera versões do PHP sem patch deve primeiro estabelecer o estado de base. Caso contrário, paga-se um teste para confirmar o que já é conhecido.
Como ajuda concretamente a PHP SOS?
- Definir o âmbito: esclarecemos consigo que aplicações, servidores e funções são verificados, que tipo de teste é adequado e o que fica expressamente excluído. O resultado é uma encomenda escrita, com janela de tempo e interlocutores.
- Preparar: são disponibilizados contas de teste, acessos ao ambiente de teste e uma cópia de segurança atual. O seu fornecedor de alojamento é informado, se necessário, para que o teste não seja bloqueado como ataque real.
- Verificar: os nossos parceiros especializados testam segundo métodos reconhecidos, entre outros ao longo das categorias OWASP. Os achados críticos comunicamo-los de imediato, e não só no relatório final.
- Reportar: recebe um relatório com resumo para a gestão e parte técnica.
- Reteste: após a correção, voltamos a verificar as vulnerabilidades encontradas e confirmamos o que ficou fechado.
Muitos achados podem ser evitados de antemão. Os guias sobre SQL injection em PHP, uploads de ficheiros seguros e sessões em PHP ajudam os programadores na preparação.
O que recebe e o que precisamos
O relatório contém cada vulnerabilidade encontrada, com descrição, local afetado, avaliação de risco e recomendação concreta para a correção. Um resumo para a administração enquadra os resultados sem jargão. Depois do reteste, recebe uma confirmação de quais pontos estão corrigidos. Ferramentas de ataque ou exploits executáveis não fazem parte do relatório.
Precisamos de si:
- uma autorização escrita da pessoa com legitimidade para cada sistema a testar, mesmo que esteja num fornecedor de alojamento
- contas de teste com as funções que devem ser verificadas
- um ambiente de teste ou a autorização para testar o ambiente de produção numa janela de tempo
- um interlocutor técnico durante o teste
- na revisão de código: acesso ao repositório
O que não prometemos
Um teste de intrusão não encontra todas as vulnerabilidades. É um retrato do momento no âmbito acordado; novas funções ou novas vulnerabilidades em dependências podem dar amanhã um quadro diferente. Não indicamos certificados ou selos que não temos e não emitimos atestados que substituam obrigações legais. Se um teste cumpre as suas obrigações, por exemplo nos termos da NIS2, esclareça-o com os seus especialistas em direito e conformidade.
A correção dos achados assumimo-la, se desejar, nós próprios ou em conjunto com a sua agência. Para o servidor e a configuração do PHP, adequa-se o hardening de servidor.
Perguntas frequentes
Qual é a diferença entre auditoria de segurança e teste de intrusão?
Uma auditoria verifica configuração, processos e código com base em requisitos e na experiência, muitas vezes com acesso aos sistemas. Um teste de intrusão tenta, de forma dirigida e com a sua autorização, explorar vulnerabilidades para mostrar o seu efeito real. As duas complementam-se.
Um teste de intrusão é perigoso para a minha aplicação PHP?
Um teste pode sobrecarregar sistemas ou alterar dados. Por isso, o âmbito, a janela de tempo e os limites são fixados previamente por escrito e recomendamos, sempre que possível, usar um ambiente de teste. Faz sempre parte uma cópia de segurança atual.
Um teste de intrusão encontra todas as vulnerabilidades?
Não. Um teste mostra as vulnerabilidades encontradas no âmbito e no período acordados. É um retrato do momento e reduz o risco, mas não prova que não existam outras vulnerabilidades.
Um teste de intrusão ajuda com a NIS2?
As verificações regulares das medidas de segurança são um elemento habitual para cumprir as obrigações de gestão de risco. Que requisitos se aplicam concretamente à sua empresa, esclareça-o com especialistas em direito e conformidade.