[Esapi-user] Path Manipulation Validation

Jim Manico jim.manico at owasp.org
Tue Nov 16 07:11:56 EST 2010


> The first is when we are simply opening an existing file. In most cases,
the files are configuration files, typically XML, where the path of the
'common' directory is system configurable. In my situation, I may have a
dozen nodes participating in a cluster and sharing a common file system. The
common file system may be a completely different mount point than where the
software is installed. Therefore, the common directory is configurable, but
the filenames of the configuration files are always the same.

 

I would use normal FileIO for this. First I'd instantiate the Java File
object with your configuration path, and verify that the configurable path
is really a directory, it exists, and its readable.  

 

File myFolder = new File(path);
myFolder.exists()
myFolder.isDirectory()

myFolder.canRead()

 

> The second scenario is when perform a directory listing and for each file
in the directory we check to see if the file validates against a known XML
schema. If so, then we need to process the file. The directory where this
pickup is located is configurable, and the file names are unknown at
runtime. In fact, the filenames and their content will constantly be
changing. Think of a trading system where documents keep on coming into and
out of the system on a regular basis (100 docs per second per node
typically)

 

Now, if you are just doing a OS directory listing - then the filenames
returned are trusted data. You can add validation here, if you are worried
that legal file names may be tainted. But really, it does not seem like the
inputs that drive this mechanism are user driven, and are therefore trusted.
Fair?

 

- Jim

 

From: esapi-user-bounces at lists.owasp.org
[mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of Springett Steven
Sent: Monday, November 15, 2010 6:22 AM
To: esapi-user at lists.owasp.org
Subject: Re: [Esapi-user] Path Manipulation Validation

 

Jim,

There are really two different scenarios that I'm attempting to resolve path
manipulation vulnerabilities in.

The first is when we are simply opening an existing file. In most cases, the
files are configuration files, typically XML, where the path of the 'common'
directory is system configurable. In my situation, I may have a dozen nodes
participating in a cluster and sharing a common file system. The common file
system may be a completely different mount point than where the software is
installed. Therefore, the common directory is configurable, but the
filenames of the configuration files are always the same.

The second scenario is when when perform a directory listing and for each
file in the directory we check to see if the file validates against a known
XML schema. If so, then we need to process the file. The directory where
this pickup is located is configurable, and the file names are unknown at
runtime. In fact, the filenames and their content will constantly be
changing. Think of a trading system where documents keep on coming into and
out of the system on a regular basis (100 docs per second per node
typically)

In both cases, we are already validating the content inside the file against
a schema and use some of the helper methods in the esapi jar to verify that
elements conform to their expected type and the content of the files are
properly escaped.





  _____  

From: Jim Manico  <mailto:jim.manico at owasp.org> <jim.manico at owasp.org>
Sent: Sat, 13 Nov 2010 23:35:36 -1000
To: 'Springett Steven'  <mailto:sspringett at us.axway.com>
<sspringett at us.axway.com>, esapi-user at lists.owasp.org
Cc: 
Subject: RE: [Esapi-user] Path Manipulation Validation




> If I'm attempting to open a file, then it is my assumption that the
getValidFileName should be used. Is this assumption correct? 

 

Saving a file, yes. But opening a file? It depends on the situation. Can you
tell us more about the architecture of the feature you are trying to fix?

 

When I write FileIO code with user-driven files, I try to never let user
data drive FileIO commands. For example, if the user is submitting a file
upload, I create a new random file name and save the file in a private
directory using this new file name that I created. I validate and use the
original file name just for a user reference. Make sense?

 

> When is a good time to use getValidDirectoryPath?

 

I can normally get away with never letting the user drive a path as well.
For example, I might create a folder based on the userId (a private internal
piece of data) lookup the file based on a fileID that I created at upload
time. But can you tell us more about this feature? It will be easier to
provide good advice.

 

- Jim

 

From: esapi-user-bounces at lists.owasp.org
[mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of Springett Steven
Sent: Monday, November 08, 2010 10:51 AM
To: esapi-user at lists.owasp.org
Subject: [Esapi-user] Path Manipulation Validation

 

Hello all,

I'm attempting to remove many path manipulation vulnerabilities in some
code.

I've been playing with DefaultValidator and the getValidFileName and
getValidDirectoryPath methods and need some clarity.

If I'm attempting to open a file, then it is my assumption that the
getValidFileName should be used. Is this assumption correct? When is a good
time to use getValidDirectoryPath?

Also, I'm looking at the Javadoc for getValidDirectoryPath and there's a
parameter missing from the doc. Specifically, 'java.io.File parent'. What is
parent suppose to be? I'm a little confused. Is this the parent directory of
the directory I'm suppose to be checking? If so, then that doesn't make a
whole lot of sense, but perhaps I do not understand the reasoning.

Any clarification would be extremely helpful.

Thanks,
Steve 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20101116/59f53c0a/attachment.html 


More information about the Esapi-user mailing list