Week 58 - Directory Traversal

Did you know that most modern web servers do not serve content like:

/var/www/html/register.php => File stored on server

GET /register.php => Request to get static file

Instead, many servers rely on dynamically defined routes:

Router.route(“/register”)

.get(require(“.getRegisterFields.js”)

.post(require(“.addNewUser.js”)

These dynamically defined routes are often used to generate an additional request (say, to an API) before returning data to a user. This could look like the following:

GET /profile?id=1 => Request generated by user HOST: example[.]com

GET /api/v1/users/profile/1 => Request generated by the server, to the internal API HOST: internal[.]example[.]com

CONTENT-TYPE: application/json => Response to user {“name”:”jake”}

How can we exploit this? Let’s try the below scenario:

GET /profile?id=../ => Request generated by user with directory traversal payload HOST: example[.]com

GET /api/v1/users/profile/../ => Request generated by the server, to the internal API GET /api/v1/users/ => Request normalized and executed by the internal API

CONTENT-TYPE: application/json => Data for all users returned {“name”:”jake”, “name”:”dahvid”, “name”:”james”}

And we can view information for all users within the API! The big takeaway from this is to keep in mind that the server may be taking your input and appending it to another back-end request, allowing you to manipulate what data is returned to you. See if you can trigger error messages to help you enumerate further, or try some of the below tips:

-Directory traversal attempts

-Fuzzing using valid URL characters (%23 (#), %3f (?), %26 (&), %2e (.), %2f (/), %40 (@))

-Different headers returned for certain pages

-Error messages revealing internal API’s and services