Scanner de métodos HTTP perigosos

Como funciona esta verificação

O Scanaris envia um pedido OPTIONS ao URL analisado, sem seguir redirecionamentos, e lê dois cabeçalhos da resposta: Allow, com o qual um servidor declara que métodos aceita nessa rota, e Access-Control-Allow-Methods, o de CORS. Se em qualquer um deles aparecer TRACE, TRACK, PUT, DELETE ou CONNECT, abre um achado de severidade baixa com a lista. É uma verificação conservadora: só marca o que o servidor anuncia explicitamente. Não envia nenhum PUT nem DELETE de teste, e se o servidor não responder ao OPTIONS ou não devolver esses cabeçalhos, não há achado.

Porque importa

Um site normal precisa de GET, HEAD, POST e, para CORS, OPTIONS. O resto são métodos com história. O TRACE devolve o pedido tal como o recebeu, cabeçalhos incluídos; combinado com outra falha permite ler cookies marcados como HttpOnly (o ataque chama-se Cross-Site Tracing). PUT e DELETE criam, substituem ou apagam recursos: num servidor de ficheiros mal configurado, um PUT envia um ficheiro para o diretório público. O CONNECT transforma o servidor num proxy. Estarem ativos não significa que funcionem sem autenticação, daí a severidade baixa; mas anunciá-los sem os usar é superfície de ataque grátis.

Como corrigir

• Apache: TraceEnable Off na configuração principal (o TRACE vem ativado por defeito em versões antigas). Para o resto, dentro do Directory ou Location do teu site: <LimitExcept GET POST HEAD OPTIONS> Require all denied </LimitExcept>.
• nginx: não implementa TRACE. Para limitar o resto num bloco location: limit_except GET POST HEAD OPTIONS { deny all; }. Se usares if ($request_method !~ ^(GET|HEAD|POST|OPTIONS)$) { return 405; }, põe-no ao nível do server.
• IIS: o módulo WebDAV é a causa típica de PUT e DELETE anunciados. Desinstala-o se não o usas, e no web.config limita os verbos com requestFiltering/verbs.
• Express e APIs: se a tua API usa PUT ou DELETE com autenticação, é legítimo que o Access-Control-Allow-Methods os liste; o que não deve fazer é listá-los em todo o site nem usar *. No middleware de CORS, põe methods: ['GET', 'POST'] nas rotas públicas e alarga só onde for preciso.
• Vercel, Netlify, Cloudflare Pages: não anunciam estes métodos por defeito. Se o achado aparecer, costuma vir de um cabeçalho CORS que configuraste tu com a lista completa.

Confirma que está corrigido

curl -si -X OPTIONS https://teudominio.com | grep -iE "^(HTTP|allow|access-control-allow-methods):"
curl -si -X TRACE https://teudominio.com | head -1

Na primeira, nem Allow nem Access-Control-Allow-Methods devem incluir TRACE, TRACK, PUT, DELETE ou CONNECT nas rotas públicas. A segunda deve devolver 405 ou 403, nunca 200 com o teu pedido refletido no corpo.

Perguntas frequentes

A minha API REST usa PUT e DELETE. Tenho de os tirar?

Não. O que importa é que essas rotas exijam autenticação e que o cabeçalho CORS não os anuncie para todo o domínio nem para qualquer origem. Se a análise aponta para a raiz da tua API, podes dar o achado de severidade baixa por aceite depois de confirmares isso. A configuração de origens é revista por CORS permissivo.

O Access-Control-Allow-Methods lista métodos, mas sem Allow. É a mesma coisa?

Não exatamente. O Allow descreve o que o servidor aceita; o cabeçalho CORS descreve o que permite a páginas de outras origens. Ambos são lidos porque ambos são informação que dás. O que significa cada parte de uma resposta CORS explica-o CORS mal configurado.

Porque é que o OPTIONS não é considerado perigoso?

Porque é o método com que o browser pergunta pelo CORS antes de certos pedidos. Bloqueá-lo parte as chamadas entre domínios. É inofensivo e necessário.