Come invertire le route URL dell'ingegnere da una grande quantità di richieste / risposte HTTP

Naviga le tue risposte
2

Sto costruendo un crawler di applicazioni web che esegue la scansione per le richieste HTTP (GET, PUT, POST, ...). È progettato per uno scopo specifico; caccia alle taglie bug. Consente ai pentesters di inserire payload di exploit su parti specifiche delle richieste HTTP.

Problema

Quando si utilizza il crawler, talvolta eseguo il crawling di molte richieste simili (ad esempio /article/1 , /article/2 , /article/3 , ...). Questo è un problema poiché, se so che /article/1 non è vulnerabile, c'è una grande possibilità che /article/2 e /article/3 non siano vulnerabili. Questo perché probabilmente eseguono lo stesso codice sul back-end (ricevono solo un articolo diverso dal database). Pertanto, non desidera eseguirne la scansione.

Esempio

Diciamo che il mio crawler ha eseguito la scansione degli URL di seguito. 

https://example.ltd/
https://example.ltd/news/some-news-alias
https://example.ltd/news/another-news-alias
https://example.ltd/contact
https://example.ltd/news/some-other-news-alias
https://example.ltd/news/and-yet-another-one

Quindi posso supporre che tutti gli altri URL che corrispondono allo schema /news/[alphabet&dash] non debbano essere sottoposti a scansione perché probabilmente eseguono lo stesso codice di back-end.

Tuttavia, diciamo che il mio crawler ha eseguito la scansione di questi URL. 

https://example.ltd/
https://example.ltd/users/sign-up
https://example.ltd/users/sign-in
https://example.ltd/contact
https://example.ltd/users/forgot-password

Quindi non posso presumere che tutti gli altri URL che corrispondono allo schema /users/[alphabet&dash] non debbano essere sottoposti a ricerca per indicizzazione perché probabilmente non eseguono lo stesso codice back-end.

Domanda

Come posso decidere (con il più alto tasso di correttezza possibile) quali richieste sono simili alle richieste che ho sottoposto a scansione prima?

I dati di richiesta e di risposta (intestazioni, corpo, ...) di tutte le richieste sottoposte a scansione precedente (nel runtime di scansione) sono disponibili per l'analisi per decidere se la richiesta corrente è simile alle richieste sottoposte a ricerca precedente.

La soluzione non deve funzionare immediatamente ma può iniziare a funzionare dopo aver raccolto abbastanza informazioni (forse dopo che sono state sottoposte a scansione circa 200 richieste di una determinata (possibile) rotta.

Ho pensato di individuare prima i possibili percorsi in base agli URL e in seguito verificare se la struttura / struttura HTML di un determinato percorso è simile a tutte le richieste con quella rotta. Tuttavia, questo sembra essere un po 'difficile dal momento che le strutture HTML possono variare se hai, ad es. una sezione di commento sotto gli articoli di notizie.

    
posta Tijme 31.10.2017 - 00:19
fonte

1 risposta

2

Quindi in termini generici stai cercando una funzione di fitness per determinare la probabilità che una richiesta web venga gestita da un percorso di codice che non è già stato sondato, in base all'URL e all'insieme di altri URL che sono già stati scoperto (e possibilmente sondato).

Una semplice regola empirica potrebbe essere sufficiente per giudicare il numero di percorsi figlio univoci: segmenti di un determinato segmento di percorso.

es. Usando il tuo esempio, se https://example.ltd/news/ ha centinaia di "figli": 

https://example.ltd/news/first-child
https://example.ltd/news/second-child
...
https://example.ltd/news/one-hundred-and-thirty-second-child

è una scommessa sicura che quelle richieste sono gestite dallo stesso codice.

Funzionerebbe se i segmenti del percorso fossero word, interi o ID.

Ovviamente la scelta della soglia per determinare quanti bambini sono troppi sarebbe informata dai set di dati esistenti e impostarla sarebbe un compromesso tra i falsi positivi (ad esempio percorsi di codice univoci ignorati per la gestione delle richieste) e false negativi (rilevamento ridondante di percorsi di ripetizione del codice).

Mi aspetto che l'utilizzo di questa euristica con una soglia relativamente alta (20?) sarebbe efficace nel ridurre il numero di URL ridondanti sottoposti a scansione, poiché se un percorso URL ha un numero basso di figli, il costo della scansione ridondante di tutti loro sono bassi, confrontati con un percorso URL con un numero elevato di bambini.

potresti combinare questo con altre misure di fitness ovvie e facili da implementare, ad esempio se il percorso include segmenti numerici o basati su ID.

Oltre a questo, penso che avresti bisogno di utilizzare una sorta di analisi semantica dei percorsi dei segmenti (ad esempio parole come "articolo" dovrebbe segnare un punteggio elevato), ma sospetto che un simile approccio avrebbe un alto rapporto fatica / rendimento.

UPDATE per indirizzare il commento:

Uno scenario in cui potrebbero essere applicate le ultime due tecniche potrebbe riguardare i siti in cui le pagine di tipo "duplicato" siedono come fratelli di pagine univoche in base all'organizzazione del percorso di un sito. Per esempio:.

Quando identificate un sito con un numero elevato di "fratelli", la vostra funzione fitness potrebbe:

  • aumenta la "probabilità di punteggio di unicità" per cose come "corrisponde alla parola del dizionario"
  • diminuisce 'probabilità di univocità' se il segmento del percorso corrisponde a un insieme di espressioni regolari per stringhe id-like (es. interi, GUID, stringhe alfanumeriche a lunghezza fissa) E c'è un alto numero di fratelli che corrispondono a stessa espressione regolare .
risposta data 02.11.2017 - 01:51
fonte

Leggi altre domande sui tag

Come ottenere la corretta dipendenza da MVP Android, tra Presenter, Dominio e Livello dati? Architettura basata su eventi e sincronizzazione con un "microservizio del primo timer"