Dot (.) Does Matter for Cross platform Application

Recently, my network software encountered strange security issues. The vulnerability testing software showed me that it can gain access to protected resources without authorization.

Access Protected Resource

I have a protected resource:

https://ip/secured/neverseen.txt

If you try to access “https://ip/secured/neverseen.txt”, it will redirect to authorization page. Everything looks fine.

https://ip/./secured/neverseen.txt

When you try to access “https://ip/./secured/neverseen.txt”, it is still okay. According the RFC 3986, the “.” will be normalized so that client will send “https://ip/secured/neverseen.txt”, too.

Of course, the web access shouldn’t depend on client side to sent standard URI request. I try to use “curl” to test the issue again.

Test with curl Tool

curl https://ip/./secured/neverseen.txt
daemon: ip/secured/neverseen.txt

My web handler receive: “ip/secured/neverseen.txt”.
Okay, curl will normalize the Dot (.).

Try use URL encode command:

curl https://ip/%2e/secured/neverseen.txt”
daemon: “ip/./secured/neverseen.txt”.

My simple web handler fails to be triggered. It doesn’t think
“ip/secured/neverseen.txt” and
“ip/./secured/neverseen.txt” are the same string.

Now, I refer to RFC 3986 to standardize URIs before any of my URI handlers. Thereafter, all request URIs are the same, and these 2 strings will correctly trigger the same handler.

Test It Again!

I run the vulnerability test again. Unfortunately, it still reports errors. They can download my “neverseen.txt” file directly without authorization.

Oops !!! Why ?

I need to check the logs in the exploit tool and understand why they can download secure files?

https://ip/secured%2e/neverseen.txt

It’s weird. I expect it will be HTTP 404 Error.

Linux vs Windows

This is filesystem related problem between “Windows” and “Unix/Linux”.

On Windows, “Myfolder.” and “Myfolder” means the same folder.
However, Unix / Linux considers them to be different files.

You can try to use Windows file explorer to create “abc” and “abc.” folders. It will show that the file already exists.

Finally!

I added a rule to convert “folder.” to “folder” in my URI normalization tool, and it finally passed the vulnerability test!

This is really a simple but completely unexpected problem.