0

I trying to pentest website. I know that there are files named "file1" and "file2". The server is nginx.

So I did this test:

  1. http://example.com/file1..%2ffile2 => 404

  2. http://example.com/file1..%2f..%2ffile2 => 200 and it showed me file2, so it worked!

After this test I assume that the website is vulnerable.

So I did this test:

  1. http://example.com/file1..%2f..%2f..%2f => 400

  2. http://example.com/file1..%2f..%2f..%2fetc/passwd => 400

  3. I tried windows files and linux files...so I did a lot of tests.

As it shows above, I am not able to get files from outside of the web root.

Is this considered vulnerable to path traversal even if I am not able to get any files from outside of the web root?

schroeder
  • 123,438
  • 55
  • 284
  • 319
Mosa Salman
  • 1
  • 1
    It **is** vulnerable to path traversal, the scope is just limited to the web root. – schroeder Sep 23 '20 at 10:58
  • Is that what you wanted to know? I mean, it is vulnerable because you can do `http://example.com/file1..%2f..%2ffile2`. The core issue is what the potential impact might be since it is limited to the web root. – schroeder Sep 23 '20 at 11:35
  • Are you sure it is limited to the web root? Perhaps you just didn't go "up" enough directories. If the web root is more than 3 sub folders deep the. You wouldn't have found /etc/passwd even if it was fully vulnerable. – Conor Mancone Sep 23 '20 at 12:03
  • 4
    I'm not sure that this is a security vulnerability in the first placel. Are you able to access files this way you would not be able to access otherwise (i.e. directly using `http://example.com/file2`)? If not it can hardly be called a security issue. If it instead can be used to bypass security restrictions, then it is a vulnerability. – Steffen Ullrich Sep 23 '20 at 14:34

2 Answers2

0

I am hesitant to comment on whether or not this specific situation is indeed a path traversal. I would need to play with the application to get a better idea.

However, considering your question:

Is this considered vulnerable to path traversal even if I am not able to get any files from outside of the web root?

Considering a true path traversal vulnerability, it is still a vulnerability even if you cannot break the barrier of the web root path. For instance, if you can include a web.config or similar file that resides at the web root but is not accessible directly with a web request, that can result in significant information disclosure.

deletehead
  • 632
  • 4
  • 9
0

To expand on Steffen's comment:

How far you can, or can't, go with path traversal does not directly define whether it is a vulnerability. It doesn't matter whether path traversal works at all or not. Nor does it matter what the web server software is, or what characters are allowed or filtered, or anything else like that.

All that matters for this type of vulnerability is one simple question: Can you get access to any files that you shouldn't have access to, or cause any unauthorized server behavior? That's it. Everything else is a distraction from the real question.

  • Are you, the user, authorized to access "file2" via any means? If so, it doesn't matter what means you use; it's not a vuln.
  • Are you able to access files that other users can access but that you shouldn't be able to? That's a vuln, even if it doesn't go outside the webroot.
  • Are you able to access files that no user should have access to, such as TLS private keys? That's a vuln, regardless of whether it's within the webroot.
  • Are you able to cause a denial-of-service because the server tries to read a file that's too long, or a stream that doesn't end (such as /dev/zero)? That's a vuln, regardless of how you triggered the DoS.
  • Are you able to browse the entire file system, but its a "toy" environment running a server specifically intended to let you browse it? That's not a vuln, regardless of whether you use path traversal, because such browsing is authorized anyhow.

You didn't give us enough information here to say either way, but hopefully this answer helps you answer your own question.

CBHacking
  • 40,303
  • 3
  • 74
  • 98