I have a Linux-based embedded system with web-interface for management purposes. According to one security paper, this web-server has rudimentary filter against directory traversal attacks in URL parameters. So in order to bypass the "../" filter, an URL with special strings needs to be used. What are the common path traversal filter bypass techniques?

  • 1
    This is quite broad. Bypass techniques vary greatly depending on the blacklist that is used, the backend application environment (Windows, Linux-based, ASP.NET, Ruby, Perl, etc.). ..\ can be used, ..//..// can be used, various encodings %252e%252e%252f is an example, and other techniques.
    – user79537
    Aug 16, 2015 at 22:39
  • 3
    It would be helpful if you mentioned what linux system, what web application/server, and what 'security paper' you are asking about.
    – KDEx
    Aug 17, 2015 at 4:53
  • It is a VoIP phone based on Linux. However, while I analyzed the firmware image with hex editor, checked the phone boot log messages and used nmap service and OS detection scans, I got fairly little information. All I can say is that phone firmware is based on Linux 2.6 for MIPS, uses /proc file-system, uses JFFS2 file-system and web-server type is unknown. Even debugging log provides fairly little information regarding web server. All it says is that PHN: WEBSV: init http_https, protected 0. Security paper can be seen here.
    – Martin
    Aug 17, 2015 at 10:37
  • I recommend editing your question and adding the additional data including the link to the vulnerability report. Aug 18, 2015 at 19:44
  • So you are looking to test whether your firmware has a fix for a specific vulnerability? Do you have access to a known vulnerable version of the firmware? I'd recommend testing there until you find the problem and then testing on the patched firmware. Aug 18, 2015 at 19:48

2 Answers 2


There are various encodings you can try to enable you to bypass a filter:

  • Try / and \ at the start of the folder name to try and reach the root directory.
  • Try %2f and %5c (percent encoded versions of the above).
  • Try using 16-bit Unicode encoding (. = %u002e, / = %u2215, \ = %u2216).
  • Try double URL encoding (. = %252e, / = %252f, \ = %255c).
  • Try overlong UTF-8 Unicode encoding (. can be %c0%2e, %e0%40%ae, %c0ae, / can be %c0%af, %e0%80%af, %c0%2f, etc, \ can be %c0%5c, %c0%80%5c).

If you get a different response trying one of the above then you have managed to change either the execution path or the file system path that is being accessed. This may indicate that the particular sequence used may be worthy of additional investigation.

  • Thanks for all those encodings! Now I should use those instead of expected user input? I mean for example instead of I need to use and other similar combinations?
    – Martin
    Aug 17, 2015 at 16:09
  • 2
    Without knowing which server or the vulnerability this is hard to answer. Look especially for parameters that take a file parameter, and test as you described. Aug 18, 2015 at 8:39
  • All the information I have is here. As much as I analyzed the phone (bootup) log files and did nmap service detection scans, then it does not seem to have some well-known web server. I also used the dotdotpwn tool(for example dotdotpwn.pl -m http-url -u -f /etc/passwd%00 -o unix -x 80 -U user -P passwd -k "user") in order to generate URL's automatically, but I feel like I'm just randomly trying.
    – Martin
    Aug 18, 2015 at 11:41
  • I would guess that in the reference The string [removed] at the end is necessary that [removed] could be the null byte (%00). Bear in mind this is guess work and it is impossible to hack by proxy in such a way. Aug 20, 2015 at 9:15
  • I see. I tested with %00 at the end when I used dotdotpwn.pl -m http-url -u /line_features.htm?l=TRAVERSAL -f /etc/passwd%00 -o unix -x 80 -k "root". This will send GET requests like GET /line_features.htm?l=%2e.%c1%af%2e.%c1%afetc%c1%afpasswd%00 HTTP/1.1 to phone.
    – Martin
    Aug 25, 2015 at 9:58

For web app security, many common hacks are documented in the associated OWASP test guides and attack pages. OWASP provides a path traversal attack and testing guide.

The general concept is to use characters that can fool the path traversal code. Things like embedded nulls, unicode notation, and such can sometimes bypass the path traversal filter.

Note that a strong implementation will not be susceptible to any of these. It will use a character white-list and other measures that will prevent any of these tricks from succeeding.

  • Thanks! As I understand, first step is to enumerate all the parts of web-application which accept content from the user. For example or I guess usually those are found by crawling the web-application and searching for ?(query string) in URLs?
    – Martin
    Aug 17, 2015 at 10:49
  • 1
    That's a start but far from the entire process. Paths can be passed as POST data that won't show up in query parameters. Also, you could have an URL like http://example.com/upload.jsp/c:/foo/bar where the c:/foo/bar is a filename. It is best if you are intimate with the functionality of the app you are testing to identify the path locations. Aug 17, 2015 at 21:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .