Finalidade: Ponto de entrada combinado para o inventário, além de um modo PoC separado.

Exemplos de execução:

Aviso importante: A verificação baseada em tempo e o modo PoC só podem ser usados contra sistemas para os quais exista autorização expressa de teste. O modo de inventário normal utiliza exclusivamente operações WFS regulares.

Pré-requisitos

• Python 3.10 ou superior
• Nenhum pacote Python adicional; ambos os scripts usam apenas a biblioteca padrão
• Acesso de rede ao endpoint WFS

Tornar opcionalmente executável:

Início Rápido

Buscar candidatos por meio de consultas WFS regulares

O caminho padrão /geoserver/wfs é adicionado automaticamente. Portanto, as seguintes especificações são equivalentes:

Em caso de instalação diferente, o caminho WFS completo deve ser especificado.

Verificar candidatos com uma verificação baseada em tempo

Somente para sistemas expressamente autorizados:

Durante a verificação, uma medição por candidato aparece em stderr:

Um screen aprovado ainda não é um achado positivo. Somente se a segunda medição, mais longa, também for aprovada, um bloco de parâmetros é emitido.

Escrever diagnóstico em um arquivo

--valid-diagnose FILE ativa automaticamente o diagnóstico detalhado e o escreve no arquivo especificado.

Fluxo do Modo Automático

O modo padrão auto processa as informações WFS nesta ordem:

1. GetCapabilities é aberto uma vez:

   root@kitploit:~

   /geoserver/wfs?service=WFS&acceptVersions=2.0.0&request=GetCapabilities
   

2. A resposta XML é transmitida em fluxo. Assim que um FeatureType/Name é encontrado, o próximo typeName é definido.

3. Para esta camada, DescribeFeatureType é executado imediatamente com version=2.0.0.

4. O script extrai os elementos XSD e seleciona campos string/JSON com nomes semelhantes a ID ou número.

5. O candidato é verificado dependendo da chamada:

   • Sem --sleep: valores de amostra devem ser JSON sintaticamente válido.
   • Com --sleep N: uma consulta de controle e uma consulta de verificação baseada em tempo são medidas. A verificação de valor JSON é ignorada nesse caso.

6. O resultado é emitido e liberado imediatamente.

7. Somente depois disso, o próximo typeName é lido da resposta GetCapabilities em andamento.

Dessa forma, uma resposta GetCapabilities grande não precisa ser totalmente processada antes que o primeiro resultado apareça.

Critérios para candidatos de campo

Sem --sleep, o modo automático considera por padrão campos string/JSON com nomes semelhantes a ID ou número.

Com --sleep, --candidate-scope auto usa, por outro lado, todos os campos simples que não sejam de geometria. O tipo XSD e o padrão de nome ID não bloqueiam mais a verificação de timing. Isso evita falsos negativos em tipos XSD numéricos, de data/booleano ou específicos do fornecedor.

Padrões de nome reconhecidos incluem, entre outros:

Na verificação baseada em tempo, o nome do campo também deve ser um identificador simples no formato [A-Za-z_][A-Za-z0-9_]*.

Diferença entre verificação JSON e verificação de sleep

Sem --sleep, é verificado se os valores observados podem ser interpretados sintaticamente como JSON. Portanto, por exemplo, a string "383205" também é considerada candidata, porque seu conteúdo representa um número JSON válido. Essa verificação é uma heurística e não uma prova de vulnerabilidade.

Com --sleep 1, apenas a medição de tempo decide. Um candidato é considerado positivo por padrão se a consulta de verificação exigir pelo menos 70 por cento do tempo de sleep solicitado adicionalmente em relação à consulta de controle. --timing-result-type auto verifica primeiro resultType=hits e, em caso de resultado negativo, em seguida resultType=results.

Medições preliminarmente positivas são obrigatoriamente confirmadas com um tempo de sleep mais longo. Sem --confirm-sleep explícito, o script usa max(3, --sleep * 3), limitado a 10 segundos. Dessa forma, um único pico de latência com --sleep 1 não leva mais a vulnerable=true.

Saída Compacta

A saída padrão contém um bloco por camada válida:

parameter_stringN contém o endpoint WFS normalizado e os valores adequados para --typename e --field_name.

--valid-fields N conta blocos de camadas, não campos individuais. Se existirem menos de N camadas válidas, o restante do catálogo continua sendo investigado. Com --max-layers, o tempo máximo de execução pode ser limitado.

Diagnóstico Detalhado

As opções --diagnose ou --valid-diagnose FILE adicionam, entre outros:

• endpoint WFS normalizado,
• URL GetCapabilities usada,
• URL DescribeFeatureType,
• tipos de campo XSD,
• marcações de ID e usabilidade,
• número de amostras verificadas,
• compatibilidade JSON ou valores de medição de timing,
• URL GetFeature gerada e
• strings de parâmetros copiáveis.

Exemplo:

Outros Modos de Inventário

Listar todas as camadas

Limitar a um namespace:

Exibir campos XSD de uma camada

Cada campo é emitido como um objeto JSON com nome, tipo XSD, nillable, id_candidate e usable_property.

Exportar valores de campos selecionados

Exportar todas as properties:

Com --unique, combinações idênticas de valores de campo selecionados são emitidas apenas uma vez.

Parâmetros de wfs_inventory.py

Ponto de Entrada Combinado

geoserver_sqli_working.py pode chamar a função de inventário diretamente. Assim que --valid-fields é especificado, apenas o inventário é executado e o programa termina em seguida.

Inventário por meio do script combinado

Internamente, os seguintes parâmetros são repassados para wfs_inventory.py:

Sem --sleep explícito, a verificação baseada em tempo permanece desativada no modo de inventário.

Modo PoC separado

Somente para sistemas de teste expressamente autorizados:

No modo PoC, o caminho de destino não é normalizado automaticamente. Aqui, o endpoint WFS completo deve ser especificado.

O modo primeiro executa um teste de baseline/sleep, depois testa as variantes de oracle baseadas em tempo existentes e, em caso de confirmação bem-sucedida, lê por padrão metadados de servidor/banco de dados. Com --query, uma consulta escalar própria pode ser especificada em vez disso.

O modo PoC desativa atualmente a verificação de certificado TLS internamente. Para um inventário puro, wfs_inventory.py deve ser preferido, pois lá o TLS é verificado por padrão.

Parâmetros de geoserver_sqli_working.py

Relatório JSONL

O modo automático pode gerar JSON Lines em vez de blocos de texto:

Com --diagnose, cada registro contém adicionalmente URLs, metadados de candidatos, valores de verificação e URLs GetFeature específicas de campo.

Proxy e TLS

Usar proxy:

Confiar em CA de proxy próprio:

Desativar verificação TLS para um sistema de teste autorizado:

--proxy-ca e --insecure não podem ser usados juntos.

Grandes Catálogos WFS e Performance

Com respostas GetCapabilities grandes, as seguintes opções ajudam:

Observações:

• GetCapabilities é solicitado apenas uma vez e depois transmitido em fluxo.
• --valid-fields 4 encerra o scan somente após quatro camadas válidas. Se existirem menos resultados, a busca continua até o fim ou até --max-layers.
• --sample-size 1 reduz o esforço da heurística JSON.
• No modo sleep, a amostra JSON é ignorada. Por caminho de consulta, são feitas uma consulta de controle e uma de verificação. Com --timing-result-type auto, após um resultado negativo de hits, duas consultas results adicionais são executadas.
• Um candidato preliminarmente positivo causa duas consultas adicionais para a confirmação escalada. Somente depois disso ele é considerado vulnerável.
• --candidate-scope id reduz o número de consultas de timing, mas pode omitir campos vulneráveis com outros nomes.
• --namespace e --start-layer-index podem limitar adicionalmente o espaço de busca.

Solução de Problemas

The read operation timed out

• Aumentar --timeout se o servidor responder lentamente.
• Definir --retries 0 para evitar repetições longas.
• Usar --max-layers e --namespace.
• Para a heurística JSON, usar --sample-size 1.

Sem saída

• Sem --sleep, os candidatos devem passar pela verificação XSD/nome e pela verificação de sintaxe JSON, dependendo de --candidate-scope.
• Com --sleep, apenas candidatos confirmados por tempo são emitidos como bloco de parâmetros; medições negativas aparecem como [sleep-check] em stderr.
• Se existirem menos resultados do que o número desejado, o scan pode continuar por muito tempo. Nesse caso, definir --max-layers.

Cannot do natural order without a primary key

Para a primeira página GetFeature, o script não envia startIndex=0, pois algumas camadas GeoServer/JDBC sem chave primária já forçam uma ordenação natural por causa disso. Ao exportar páginas adicionais, essa camada pode, no entanto, exigir uma chave primária ou uma ordenação suportada pelo servidor.

schema does not define ...Type

O script considera tanto o usual <LayerName>Type quanto um complexType divergente, referenciado no elemento de camada XSD global ou anônimo. Se o erro persistir, a resposta DescribeFeatureType correspondente deve ser verificada com --diagnose.

HTTP 400 na verificação de amostra

A mensagem de erro OWS completa é emitida em stderr. Causas comuns são properties não suportadas, especificações de paginação do servidor ou uma configuração de fonte de dados específica da camada.

Ajuda Direto no Terminal