Directory Traversal: Che effetto ha questo '?' e '.' hai sull'URL?

6

Ho fatto una domanda su questo stesso sito - Impossibile comprendere il motivo per cui l'app Web è vulnerabile a un attacco di directory trasversale , in cui mi è stato fornito un rapporto in cui si afferma che la mia app Web era vulnerabile.
Ho pubblicato pochi esempi dal rapporto, come Testing Path: http://127.0.0.1:80/??/etc/issue <- VULNERABLE! , ora mi è stato chiesto cosa fossero questi due% di% di urlatura nell'URL postato.

Ho eseguito alcuni test:
/?? restituisce la home page.
http://127.0.0.1:80/??/etc/issue restituisce la home page.
http://127.0.0.1:80/.?/etc/issue restituisce la home page.

Quindi, lo schema seguente restituisce la home page:
http://127.0.0.1:80/?./etc/issue , dove
 Se http://127.0.0.1:80/Position1Position2Anything/Anythingcouldbehere = Position1 , la home page viene restituita indipendentemente dal contenuto in ? .

Se Position2 = Position1 allora . deve essere Position2 , per la pagina iniziale.
? potrebbe anche essere una stringa vuota.

Ora, tutto ciò che non corrisponde al modello sopra restituisce 400/404.
Ho eseguito il test precedente per Anything e anch'esso ha restituito lo stesso risultato (seguito lo stesso schema di security.stackexchange.com/ e . ) e ho restituito la sua Home page sul browser.

Spiega il ruolo di ? e ? negli URL.

EDIT:
È solo questo schema (quello sopra, con . e ? ) che rende l'app Web vulnerabile all'attacco di directory trasversale come da rapporto inviato dai pen-tester.

    
posta Batman 08.09.2016 - 15:00
fonte

1 risposta

3

Nell'URL di tutto quello che succede dopo che il simbolo ? è una parte dei richiesta GET dati.

  • Quindi in http://127.0.0.1:80/??/etc/issue e http://127.0.0.1:80/.?/etc/issue la parte ?/etc/issue è essenzialmente un dato nella richiesta GET all'URL http://127.0.0.1:80/ .

Nota che ?/etc/issue non è un percorso file valido.

  • In http://127.0.0.1:80/?./etc/issue la parte ./etc/issue è essenzialmente i dati nella richiesta GET all'URL http://127.0.0.1:80/ .

Nota Qui ./etc/issue è un percorso valido. (potrebbe essere ./etc/passwd è migliore)

Nell'ultimo caso, poiché lo scanner ha ottenuto un (HTTP/1.1 200) , si presuppone che abbia letto il file sul server e lo abbia contrassegnato come vulnerabile.

Lo scanner si aspetta qualcosa di simile a HTTP/1.1 404 (non trovato) o HTTP/1.1 302 (reindirizzamento URL) affinché quella pagina non sia vulnerabile.

    
risposta data 08.09.2016 - 19:01
fonte

Leggi altre domande sui tag