[Esapi-user] Path Manipulation Validation

Springett Steven sspringett at us.axway.com
Mon Nov 15 11:21:50 EST 2010


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 <jim.manico at owasp.org> <mailto:jim.manico at owasp.org> 
Sent: Sat, 13 Nov 2010 23:35:36 -1000
To: 'Springett Steven' <sspringett at us.axway.com> <mailto:sspringett at us.axway.com> , esapi-user at lists.owasp.org
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.

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

More information about the Esapi-user mailing list