web-dev-qa-db-fra.com

Impossible de comprendre pourquoi l'application Web est vulnérable à une attaque de traversée d'annuaire

Je travaillais avec cette application Web, lorsque quelqu'un l'a testée au stylo et m'a envoyé un énorme rapport indiquant que mon application est vulnérable à une attaque de traversée d'annuaire.

Voici un exemple:

Testing Path: http://127.0.0.1:80/??/etc/issue <- VULNERABLE!

J'ai mis http://127.0.0.1:80/??/etc/issue Dans mon navigateur, mais cela m'a donné la page d'accueil, il n'a pas du tout renvoyé le fichier /etc/issue.

Ensuite, j'ai essayé avec curl et il a également renvoyé la page d'accueil.

Quelqu'un pourrait-il m'expliquer comment mon application est vulnérable si le fichier /etc/issue N'est pas renvoyé.

L'application est codée en Python 2.7, avec flask comme framework et Nginx comme proxy inverse).

Deux autres échantillons du rapport, avec la réponse correspondante: -

  1. Testing Path: http://127.0.0.1:80/??/etc/passwd <- VULNERABLE!

    GET Request - app: 0|req: 1587/1587] 127.0.0.1 () {34 vars in 488 bytes} [Tue Sep 6 15:47:13 2016] GET /??/etc/passwd => generated 982 bytes in 4 msecs (HTTP/1.1 200) 2 headers in 80 bytes1

  2. Testing Path: http://127.0.0.1:80/??/??/etc/passwd <- VULNERABLE!

    GET Request - 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

web-applicationpythondirectory-traversal
39
Batman

J'ai envoyé un rapport pour une vulnérabilité similaire récemment et j'ai obtenu une réponse similaire.

Il s'avère que la plupart des navigateurs et des clients HTTP CLI suppriment les composants de cheminement de chemin de l'URL.

Par exemple, si sur Firefox vous tapez l'URL http://example.com/../../../etc/passwd la demande GET qui arrive sur example.com ressemblera à ceci:

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

Même chose avec wget.

Vous devriez essayer avec un outil de niveau inférieur, comme telnet ou 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)

Là encore, il pourrait s'agir d'un faux positif, votre auditeur aurait dû inclure le contenu de /etc/issue dans le rapport. C'est un peu l'intérêt d'utiliser le problème et non le mot de passe.

Vous devriez au moins faire un suivi auprès de votre auditeur pour confirmer s'il s'agit d'un faux positif. Si ce n'est pas possible, organisez un nouveau pentest ou effectuez le vôtre avec un fuzzer de parcours comme dotdotpwn

Ne jamais supposer que vous êtes en sécurité, vous assurer que vous l'êtes. Surtout après un rapport comme ça.

45
GnP

Tout d'abord, personne ne l'a testé au stylo. Ils ont exécuté un scanner et vous ont remis les résultats.

Un stylo-testeur aurait confirmé la vulnérabilité et expliqué comment la recréer.

Il est possible que le scanner ait signalé à tort le fait qu'il ait obtenu votre page d'accueil en réponse à ces données utiles comme une conclusion positive.

Je pense aussi, comme Jesse, que le double point d'interrogation cache la vraie charge utile parce que je n'ai jamais entendu parler de ?? dans le cadre d'une charge utile de traversée de répertoire et ne trouve rien qui puisse me faire penser que c'est un. Essayez de remplacer .. dans tous les endroits que vous voyez ??

Le scanner aurait utilisé une version de navigateur qui ne suivait pas https://tools.ietf.org/html/rfc3986#section-5.2 qui est la spécification pour supprimer/résoudre ces points dans l'URL .

Si le scanner n'avait signalé qu'une seule charge utile comme vulnérable alors que des dizaines d'autres ne l'étaient pas, je serais plus inquiet, mais il semble que vous ayez obtenu des dizaines de résultats avec diverses charges utiles, non? Comme @Gnp l'a dit, demandez au scanner une preuve (et demandez à ce sujet ?? charge utile).

30
mcgyver5

C'était très probablement un faux positif.

Après avoir vu les informations mises à jour ci-dessous dans votre question

GET Request -

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

Il est assez clair qu'il a été produit par un scanner automatisé.

Puis vient la question de savoir comment le scanner a décidé qu'il était vulnérable?

Comme vous l'avez mentionné,

Ensuite, j'ai essayé avec curl et il a également renvoyé la page d'accueil.

Le scanner automatisé a simplement supposé que depuis qu'il a obtenu un HTTP/1.1 200 (OK) comme réponse du serveur, il a pu lire ce fichier /etc/passwd sur le serveur. Scanner automatisé idiot.

Le scanner automatisé attend quelque chose comme un HTTP/1.1 404 (Introuvable) ou HTTP/1.1 302 (Redirection d'URL) pour que cette page ne soit pas vulnérable.

2
Sravan