CODEWITHSUNDEEP
url
Valentin H
Valentin H

Reputation: 7458

Dot-dot removed from URL by Firefox

When I enter an URL like this, with ..

 http://SERVER:8085/../tn/d9dd6c39d71276487ae798d976f8f629_tn.jpg

I obtain a request in my Web-Server without ..-part

Does Firefox remove it silently? Are the .. not allowed in URLs?

P.S.: wget removes .. also :-(

Upvotes: 5

Views: 1851

Answers (3)

Cashiuus
Cashiuus

Reputation: 136

I have recently begun seeing this and, despite what the marked answer states, adding this to a URL does make sense and is a valid folder path in the world of IT security where we intetionally bypass security measures in mis-configured sites, classified as Directory Traversal attacks.

Web (browsers, wget, curl, etc...) tools silently evaluate the URL path and strip out the "/../" making my job of finding vulnerabilities more difficult. To get around this, I use Firefox along with Burpsuite, a proxying assessment tool that captures the request and allows me to modify it before sending to the server.

Doing this, I can type:

https://example.com/vpn/../vpns/cfg/etc

in my browser URL, and when I capture it using Burpsuite, it looks like:

https://example.com/vpns/cfg/etc

showing me that Firefox has in fact changed my original intended URL string. So within Burpsuite, I modify the request back to say:

GET /vpn/../vpns/cfg/etc HTTP/1.1

send it to the server, and voila, the path remains intact and navigates to the correct location. Yes, in a normal well-configured application with proper request handling, doing this shouldn't be necessary. This particular string acts differently in these 2 formats, so modifying it necessary to cause the server to handle it in the manner we want to show there is a configuration problem with how the application handles the request (a Directory Traversal vulnerability).

This can also be proven using curl. If you send a normal curl command like below, curl will do the same as Firefox and evaluate the path, removing "/vpn/.." from it before sending to the server:

curl -i -s -k "https://example.com/vpn/../vpns/cfg/etc"

However, if you add the "--path-as-is" argument, curl will not modify it and send it as-is, and the "/vpn/.." remains intact:

curl -i -s -k "https://example.com/vpn/../vpns/cfg/etc" --path-as-is

After some additional reading, I found this behavior is due in part to URI Normalization standards (https://en.wikipedia.org/wiki/URI_normalization).

This points to RFC 3986 for defining URI Syntax https://www.rfc-editor.org/rfc/rfc3986#section-5.2.4.

Upvotes: 8

flukeman
flukeman

Reputation: 21

Complementary information:

"../" will be stripped by the developer tools as well (up to 54.0.1 at least), meaning you cannot use the "Edit and resend" to hand-craft a valid request like this:

GET /../tn/d9dd6c39d71276487ae798d976f8f629_tn.jpg

... which could potentially result in a directory traversal and the file being retrieved.

Upvotes: 2

Psytho
Psytho

Reputation: 3384

".." means a relative path and used for moving up in the hierarchy. So ".." is not a valid name for a folder therefore you cannot use it in the middle of URL. It just makes no sense.

So to answer your question: ".." is allowed in url but only in the beginning.

Upvotes: 2

Related Questions