Impossibile comprendere perché l'app Web sia vulnerabile a un attacco trasversale directory

Ho recentemente inviato un rapporto per una vulnerabilità simile e ho ottenuto una risposta simile.

Risulta la maggior parte dei browser e i client http della CLI rimuovono i componenti di attraversamento del percorso dall'URL.

Ad esempio se su Firefox si digita l'URL http://example.com/../../../etc/passwd la richiesta GET che arriva su example.com sarà simile a questa:

GET /etc/passwd HTTP/1.1
[Ommitted headers]

Lo stesso accordo con wget.

Dovresti provare con uno strumento di livello inferiore, come telnet o netcat:

$ telnet example.com 80
GET /../../../etc/issue HTTP/1.1

HTTP/1.1 400 Bad Request
Content-Type: text/html
Content-Length: 349
Connection: close
Date: Wed, 07 Sep 2016 12:38:13 GMT
Server: ECSF (fll/078B)

Inoltre, potrebbe essere stato un falso positivo, il tuo auditor avrebbe dovuto includere il contenuto di /etc/issue nel rapporto. È un po 'il punto di usare il problema e non passwd.

Dovresti almeno seguire il tuo auditor per confermare se si tratta di un falso positivo. Se ciò non è possibile, organizza un nuovo pentest o esegui il tuo con un path traversal fuzzer come dotdotpwn

Mai presumi che tu sia sicuro, assicurati di essere. Soprattutto dopo un rapporto del genere.

Primo, nessuno lo ha testato con la penna. Hanno eseguito uno scanner e ti hanno consegnato i risultati.

Un pen-tester avrebbe confermato la vulnerabilità e spiegato come ricrearlo.

È possibile che lo scanner abbia erroneamente segnalato il fatto che ha ottenuto la tua home page come risposta a questi payload come risultato positivo.

Penso anche, come Jesse, che il doppio punto interrogativo stia nascondendo il vero carico utile perché non ho mai sentito parlare di ?? come parte di un carico utile di directory directory e non riesco a trovare nulla per farmi pensare che sia uno . Prova a sostituire .. in tutti i luoghi che vedi ??

Lo scanner avrebbe utilizzato una versione del browser che non seguiva il link che è la specifica per rimuovendo / risolvendo quei punti nell'URL.

Se lo scanner avesse contrassegnato un solo carico utile come vulnerabile mentre altri non lo erano, sarei più preoccupato, ma sembra che tu abbia ottenuto dozzine di risultati con vari payload, giusto? Come ha detto @Gnp, chiedi allo scanner prove (e chiedi del carico di lavoro ?? ).

Questo era probabilmente un falso positivo.

Dopo aver visto le informazioni sottoelencate nella tua domanda

Richiesta GET -

app: 0|req: 1591/1591] 127.0.0.1 () {34 vars in 493 bytes} [Tue Sep  6 15:47:14 2016] GET /??/??/etc/passwd => generated 982 bytes in 5 msecs (HTTP/1.1 200) 2 headers in 80 bytes

È piuttosto chiaro che è stato prodotto da alcuni scanner automatici.

Segue la domanda su come lo scanner abbia deciso di renderlo vulnerabile?

Come hai detto,

Then I tried with curl and it too returned the homepage.

Lo scanner automatizzato ha dato per scontato che dal momento che ha ottenuto un HTTP/1.1 200 (OK) come risposta del server, è stato in grado di leggere quel file /etc/passwd sul server. Silly Automated Scanner.

Lo scanner automatico 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.