Definition of Directory Traversal

Directory traversal is a form of HTTP exploit in which a hacker uses the software on a Web server to access data in a directory other than the server's root directory. If the attempt is successful, the hacker can view restricted files or even execute commands on the server.

How Directory Traversal impacts the Android O.S

Directory Traversal within Android, allows attackers to perpetrate a path traversal attack in the context of a user application and read/write files inside internal storage.

Android Directory Traversal attack Example

App Name:

ES File Explorer v3.2.4.1 - Path Traversal Vulnerability

Product & Service Introduction:

ES File Explorer is a free all-in-one including a file manager & application & tasks, support for online storage spaces (Dropbox, Google Drive, SkyDrive, Box.net, Sugarsync, Yandex, Amazon S3),



References (Source):



Technical Details & Description:

A Path Traveral web vulnerability has been discovered in the official in the official ES File Explorer v3.2.4.1 mobile android web-application. The security vulnerability allows a remote attacker to unauthorized request local files and device system paths to compromise the application or device.

The vulnerability is located in the content://com.estrongs.files/system/ path request with the context. The vulnerability can be exploited by local or remote attackers without user interaction. The attacker needs to replace the sdcard path request in the com.estrongs.files/system with a malicious path request like ./etc/passwd ./etc/hosts and continues the request. The attack vector is located on the application-side of the service and the request is http.

My Question

Although I understand what Directory Traversal is and how Directory Traversal can take place. I don't know what factors makes a selection of Android code vulnerable to such an attack.

  • are all of these from a school project?
    – schroeder
    May 22, 2015 at 18:49
  • 1
    No, I'm researching vulnerabilities within Android. And I've figured out all I can without asking for help on forums like this one. So here I am.
    – user77088
    May 22, 2015 at 18:51
  • One android App being vulnerable doesn't really make the whole android O.S. vulnerable. I'd just want to make clear that it is up to the application to validate user input, and one App being vulnerable does not mean all apps are vulnerable. Mike Ounsworth provides a good example of how an application can be vulnerable.
    – daboross
    Jul 1, 2015 at 7:31

1 Answer 1


The generic answer for "is my code vulnerable to directory traversal?" is to ask yourself if your code:

  1. Uses filename strings that you got from an untrusted source to read/write files on disk? "Untrusted sources" could be direct user input, things you read from files (which could have been tampered with), or from 3rd party code that your code interacts with.

  2. If you answered 'yes' to (1), then what happens if instead of "filename.txt", you enter the string "../someOtherDir/secret.txt" (assuming this file exists)? Will the program reject it as a malicious file access, or will it happily open this file?

This kind of traversal works because unix-like environments will accept /tmp/../etc/passwds as a valid path for /etc/passwds.


Mitigating against Directory Traversal Attacks usually involves making sure that if you allow filenames from untrusted sources, that you restrict those file accesses to a single directory. AFAIK there's no single best way to do this, but some things to think about are:

  1. If you are only allowing the user to specify a filename (not a folder or path) then simply reject any filename strings that contain the '/' or '\' characters. Just silently drop that request. Better is to look up the list of legal file name characters on your OS (Android in this case) and reject any string that contains a non-legal character.

  2. If all the files that you are allowing the user access to are in /publicDir, then before you open a file with the untrusted string, make sure that the file pointed at is actually inside /publicDir. This sounds obvious, but turns out to be really tricky to get right since there are many ways to construct malicious paths, for example: "/publicDir/../etc/passwds" will fool many naive checks. So I wouldn't advise this option.

A final note is not to get into the game of "cleaning" user input, just reject it. For example, a common thing programmers like to do is to remove dangerous characters and attempt to process the request on the "cleaned" string. Don't do this. If they gave you a bad string, just reject it and let them try again. I have two reasons for this:

  1. If the user asked you to open "../../../etc/passwd", that wasn't a typo, they didn't mean "passwd.txt", they're being an asshat. Just ignore it.

  2. As soon as you write a function to clean strings, the game becomes to pass in a string which your cleaner with make malicious. The more complicated your string cleaner gets, the more room there is to abuse it.

So don't play the game, if it look suspicious, just reject it. I personally use mitigation option #1: rather than trying to guess which characters could be malicious, I just reject anything that contains a character other than letters, numbers, and '.'

  • Suppose I have PUBLIC_DIR = "/publicDir/", and I use File file = new File(PUBLIC_DIR, "../../../../system/etc/hosts"); If I do this, path name I get is /publicDir/hosts. I don't understand how I can access files outside /publicDir because the file API would only search for files within /publicDir/ Dec 28, 2015 at 10:33

You must log in to answer this question.