2014-07-24 10 views
9

Desidero verificare che la mia applicazione Web non abbia una vulnerabilità di attraversamento del percorso.Verificare la vulnerabilità di attraversamento del percorso nel server Web

sto cercando di utilizzare curl per questo, come questo:

$ curl -v http://www.example.com/directory/../ 

vorrei che la richiesta HTTP da effettuare in modo esplicito all'URL /directory/../, per verificare che una regola specifica che coinvolge nginx proxy non è vulnerabile al path traversal. Vale a dire, vorrei questa richiesta HTTP da inviare:

> GET /directory/../ HTTP/1.1 

Ma curl sta riscrivendo la richiesta come all'URL /, come si può vedere nella uscita:

* Rebuilt URL to: http://www.example.com/ 
(...) 
> GET/HTTP/1.1 

E 'possibile utilizzare curl per questo test, costringendolo a passare l'URL esatto nella richiesta? In caso contrario, quale sarebbe un modo appropriato?

+0

Hai bisogno di ulteriori informazioni sulla mia risposta? – SilverlightFox

+1

fernando, hai mai avuto una risposta a questa domanda che usa solo arricciatura? –

+0

Quale versione di 'curl' stai usando? Non riesco a replicare questo comportamento, almeno non quando ho "arricciato" un URL localhost. – alexw

risposta

1

È possibile utilizzare uno intercepting proxy per acquisire una richiesta per l'applicazione e ripetere la richiesta con parametri modificati, ad esempio l'URL non elaborato richiesto dall'applicazione.

La versione gratuita di Burp Suite consentirà l'utilizzo del ripetitore.

Tuttavia, ci sono alternative che dovrebbero consentire anche questo come Zap, WebScarab e Fiddler2.

1

Non sono a conoscenza di un modo per farlo tramite curl, ma è sempre possibile utilizzare telnet. Provate questo comando:

telnet www.example.com 80

vedrete:

Trying xxx.xxx.xxx.xxx... Connected to www.example.com. Escape character is '^]'.

Ora avete una connessione aperta a www.example.com. Ora basta digitare il comando per andare a prendere la pagina:

GET /directory/../ HTTP/1.1

E si dovrebbe vedere il risultato. per esempio.

HTTP/1.1 400 Bad Request

11

La bandiera ricciolo che stai cercando è curl --path-as-is.

Problemi correlati