No se puede entender por qué la aplicación web es vulnerable a un ataque transversal de directorio

Recientemente envié un informe para una vulnerabilidad similar y obtuve una respuesta similar.

Resulta que la mayoría de los navegadores y clientes CLI http eliminan los componentes de la ruta de la URL.

Por ejemplo, si en Firefox escribes la URL http://example.com/../../../etc/passwd , la solicitud GET que llega a example.com se verá así:

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

Lo mismo con wget.

Debes probar con una herramienta de nivel inferior, como 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)

Nuevamente, podría haber sido un falso positivo, su auditor debería haber incluido el contenido de /etc/issue en el informe. Ese es el punto de usar el problema y no la contraseña.

Al menos debe hacer un seguimiento con su auditor para confirmar si fue un falso positivo. Si eso no es posible, organice un nuevo pentest o realice uno propio con un fuzzer de recorrido como dotdotpwn

Nunca asuma que está seguro, asegúrese de que lo está. Especialmente después de un informe como ese.

Primero, Nadie lo probó con una pluma. Ejecutaron un escáner y le entregaron los resultados.

Un pen-tester habría confirmado la vulnerabilidad y explicado cómo volver a crearla.

Es posible que el escáner haya marcado erróneamente el hecho de que obtuvo su página de inicio como respuesta a esta carga útil como un resultado positivo.

También pienso, como Jesse, que el doble signo de interrogación está ocultando la carga útil real porque nunca he oído hablar de ?? como parte de una carga útil transversal del directorio y no puedo encontrar nada que me haga pensar que es uno . Intenta sustituir .. en todos los lugares donde veas ??

El escáner habría utilizado una versión del navegador que no seguía enlace , que es la especificación para Eliminando / resolviendo esos puntos en la URL.

Si el escáner hubiera marcado solo una carga útil como vulnerable, mientras que docenas de otros no lo estaban, me preocuparía más, pero parece que obtuviste docenas de resultados con varias cargas útiles, ¿verdad? Como dijo @Gnp, pida una prueba al escáner (y pregunte por esa carga útil ?? ).

Esto fue probablemente un falso positivo.

Después de ver la información actualizada a continuación en tu pregunta

Solicitud 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

Está bastante claro que fue producido por un escáner automatizado.

Luego surge la pregunta de cómo el escáner decidió que era vulnerable.

Como usted mencionó,

  

Luego lo intenté con curl y también devolví la página de inicio.

El escáner automatizado simplemente asumió que, dado que obtuvo un HTTP/1.1 200 (OK) como respuesta del servidor, pudo leer ese archivo /etc/passwd en el servidor. Escáner automatizado tonto.

El escáner automatizado espera algo como HTTP/1.1 404 (No encontrado) o HTTP/1.1 302 (redirección de URL) para que esa página no sea vulnerable.