Scopo: Punto di ingresso combinato per l'inventario e una modalità PoC separata.

Esempi di esecuzione:

Nota importante: Il controllo basato sul tempo e la modalità PoC devono essere utilizzati solo contro sistemi per i quali esiste un'autorizzazione esplicita al test. La normale modalità di inventario utilizza esclusivamente operazioni WFS regolari.

Prerequisiti

• Python 3.10 o successivo
• Nessun pacchetto Python aggiuntivo; entrambi gli script utilizzano solo la libreria standard
• Accesso di rete all'endpoint WFS

Rendere opzionalmente eseguibili:

Avvio rapido

Cercare candidati tramite query WFS regolari

Il percorso predefinito /geoserver/wfs viene aggiunto automaticamente. Le seguenti indicazioni sono quindi equivalenti:

In caso di installazione diversa, è necessario specificare il percorso WFS completo.

Verificare i candidati con un controllo basato sul tempo

Solo per sistemi esplicitamente autorizzati:

Durante il controllo, per ogni candidato appare una misurazione su stderr:

Un screen superato non è ancora un esito positivo. Solo se anche la seconda misurazione, più lunga, viene superata, viene emesso un blocco di parametri.

Scrivere la diagnosi in un file

--valid-diagnose FILE attiva automaticamente la diagnosi dettagliata e la scrive nel file specificato.

Flusso della modalità automatica

La modalità predefinita auto elabora le informazioni WFS in questo ordine:

1. GetCapabilities viene aperto una volta:

   root@kitploit:~

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

2. La risposta XML viene trasmessa in streaming. Non appena viene trovato un FeatureType/Name, il successivo typeName è determinato.

3. Per questo layer viene eseguito immediatamente DescribeFeatureType con version=2.0.0.

4. Lo script estrae gli elementi XSD e seleziona i campi stringa/JSON con nomi simili a ID o numerici.

5. Il candidato viene verificato a seconda della chiamata:

   • Senza --sleep: i valori campione devono essere JSON sintatticamente valido.
   • Con --sleep N: vengono misurate una richiesta di controllo e una richiesta di verifica basata sul tempo. Il controllo del valore JSON viene saltato.

6. Il risultato viene emesso immediatamente e flushato.

7. Solo successivamente viene letto il successivo typeName dalla risposta GetCapabilities in corso.

In questo modo non è necessario elaborare completamente una grande risposta GetCapabilities prima che appaia il primo risultato.

Criteri per i candidati di campo

Senza --sleep, la modalità automatica considera per impostazione predefinita i campi stringa/JSON con nomi simili a ID o numerici.

Con --sleep, --candidate-scope auto utilizza invece tutti i semplici campi non geometrici. Il tipo XSD e il pattern del nome ID non bloccano più il controllo temporale. Ciò previene falsi negativi per tipi XSD numerici, data/booleani o specifici del produttore.

I pattern di nome riconosciuti includono:

Nel controllo basato sul tempo, il nome del campo deve inoltre essere un semplice identificatore nel formato [A-Za-z_][A-Za-z0-9_]*.

Differenza tra controllo JSON e controllo sleep

Senza --sleep, viene verificato se i valori osservati possono essere interpretati sintatticamente come JSON. Pertanto, ad esempio, anche la stringa "383205" è considerata un candidato, perché il suo contenuto rappresenta un numero JSON valido. Questo controllo è un'euristica e non una prova di vulnerabilità.

Con --sleep 1, decide esclusivamente la misurazione del tempo. Un candidato è considerato positivo per impostazione predefinita se la richiesta di verifica richiede almeno il 70 percento in più del tempo di sleep richiesto rispetto alla richiesta di controllo. --timing-result-type auto verifica prima resultType=hits e, in caso di risultato negativo, successivamente resultType=results.

Le misurazioni provvisoriamente positive vengono obbligatoriamente confermate con un tempo di sleep più lungo. Senza un --confirm-sleep esplicito, lo script utilizza max(3, --sleep * 3), limitato a 10 secondi. In questo modo un singolo picco di latenza con --sleep 1 non porta più a vulnerable=true.

Output compatto

L'output standard contiene un blocco per ogni layer valido:

parameter_stringN contiene l'endpoint WFS normalizzato e i valori appropriati per --typename e --field_name.

--valid-fields N conta i blocchi di layer, non i singoli campi. Se esistono meno di N layer validi, il catalogo rimanente viene ulteriormente esaminato. Con --max-layers è possibile limitare il tempo di esecuzione massimo.

Diagnosi dettagliata

Le opzioni --diagnose o --valid-diagnose FILE aggiungono tra l'altro:

• endpoint WFS normalizzato,
• URL GetCapabilities utilizzata,
• URL DescribeFeatureType,
• tipi di campo XSD,
• marcatori ID e di utilizzabilità,
• numero di campioni verificati,
• compatibilità JSON o valori di misurazione temporale,
• URL GetFeature generata e
• stringhe di parametri copiabili.

Esempio:

Ulteriori modalità di inventario

Elencare tutti i layer

Limitare a un namespace:

Visualizzare i campi XSD di un layer

Ogni campo viene emesso come oggetto JSON con nome, tipo XSD, nillable, id_candidate e usable_property.

Esportare i valori dei campi selezionati

Esportare tutte le proprietà:

Con --unique, le combinazioni identiche di valori di campo selezionati vengono emesse una sola volta.

Parametri di wfs_inventory.py

Punto di ingresso combinato

geoserver_sqli_working.py può chiamare direttamente la funzione di inventario. Non appena viene specificato --valid-fields, viene eseguito esclusivamente l'inventario e il programma termina successivamente.

Inventario tramite lo script combinato

Internamente vengono passati i seguenti parametri a wfs_inventory.py:

Senza un --sleep esplicito, il controllo basato sul tempo rimane disattivato in modalità inventario.

Modalità PoC separata

Solo per sistemi di test esplicitamente autorizzati:

In modalità PoC, il percorso di destinazione non viene normalizzato automaticamente. Qui dovrebbe essere specificato l'endpoint WFS completo.

La modalità esegue prima un test baseline/sleep, testa successivamente le varianti oracle basate sul tempo presenti e, in caso di conferma riuscita, legge per impostazione predefinita i metadati del server/database. Con --query è invece possibile specificare una propria query scalare.

La modalità PoC disattiva attualmente internamente la verifica del certificato TLS. Per un semplice inventario, è preferibile utilizzare wfs_inventory.py, poiché lì TLS viene verificato per impostazione predefinita.

Parametri di geoserver_sqli_working.py

Report JSONL

La modalità automatica può generare JSON Lines invece di blocchi di testo:

Con --diagnose, ogni record contiene inoltre URL, metadati dei candidati, valori di verifica e URL GetFeature specifici del campo.

Proxy e TLS

Utilizzare un proxy:

Fidarsi di una CA proxy personalizzata:

Disattivare la verifica TLS per un sistema di test autorizzato:

--proxy-ca e --insecure non possono essere utilizzati insieme.

Grandi cataloghi WFS e prestazioni

Per risposte GetCapabilities di grandi dimensioni, le seguenti opzioni aiutano:

Note:

• GetCapabilities viene richiesto una sola volta e successivamente trasmesso in streaming.
• --valid-fields 4 termina la scansione solo dopo quattro layer validi. Se esistono meno risultati, la ricerca continua fino alla fine o fino a --max-layers.
• --sample-size 1 riduce il costo dell'euristica JSON.
• In modalità sleep, il campione JSON viene saltato. Per ogni percorso di query vengono eseguite una richiesta di controllo e una di verifica. Con --timing-result-type auto, dopo un risultato hits negativo vengono eseguite inoltre due richieste results.
• Un candidato provvisoriamente positivo causa due ulteriori richieste per la conferma scalata. Solo successivamente è considerato vulnerabile.
• --candidate-scope id riduce il numero di richieste temporali, ma può tralasciare campi vulnerabili con altri nomi.
• --namespace e --start-layer-index possono limitare ulteriormente lo spazio di ricerca.

Risoluzione dei problemi

The read operation timed out

• Aumentare --timeout se il server risponde lentamente.
• Impostare --retries 0 per evitare lunghi tentativi.
• Utilizzare --max-layers e --namespace.
• Per l'euristica JSON, utilizzare --sample-size 1.

Nessun output

• Senza --sleep, i candidati devono superare il controllo XSD/nome e il controllo della sintassi JSON a seconda di --candidate-scope.
• Con --sleep, vengono emessi come blocco di parametri solo i candidati confermati temporalmente; le misurazioni negative appaiono come [sleep-check] su stderr.
• Se esistono meno risultati del numero desiderato, la scansione può continuare a lungo. In questo caso, impostare --max-layers.

Cannot do natural order without a primary key

Per la prima pagina GetFeature, lo script non invia startIndex=0, poiché alcuni layer GeoServer/JDBC senza chiave primaria impongono già un ordinamento naturale. Durante l'esportazione di ulteriori pagine, un tale layer può comunque richiedere una chiave primaria o un ordinamento supportato lato server.

schema does not define ...Type

Lo script considera sia il consueto <LayerName>Type sia un complexType diverso, referenziato nell'elemento layer XSD globale o anonimo. Se l'errore persiste, la risposta DescribeFeatureType interessata dovrebbe essere verificata con --diagnose.

HTTP 400 durante il controllo dei campioni

Il messaggio di errore OWS completo viene emesso su stderr. Le cause comuni sono proprietà non supportate, impostazioni di paging lato server o una configurazione dell'origine dati specifica del layer.

Aiuto direttamente nel terminale