From [email protected] on October 19, 2009 17:16:24
What steps will reproduce the problem? 1. checkout current trunk on a unix system (linux treid)
2. mvn -Dtest=ValidatorTest test What is the expected output? What do you see instead? Tests should pass. These tests fail:
testGetValidDirectoryPath(org.owasp.esapi.reference.ValidatorTest)
testIsInvalidFilename(org.owasp.esapi.reference.ValidatorTest)
testIsValidDirectoryPath(org.owasp.esapi.reference.ValidatorTest)
testIsValidFileUpload(org.owasp.esapi.reference.ValidatorTest) What version of the product are you using? On what operating system? trunk revision 900 on Linux (debian stable & unstable). Please provide any additional information below. testGetValidDirectoryPath, testIsValidDirectoryPath & testIsValidFileUpload
All suffer from the distributed ESAPI.properties not allowing a '/' in a
directory path (Validator.DirectoryName). A backslash '' is allowed so
this test probably works in windows tough will fail on anything using '/'
as a directory separator. Adding '/' to the properties.
Adding a '/' easily solves this problem but I wonder if there is a better
way. It would be nice if there was a way to add the current platform's
directory separator to the regex without listing the separators for other
platforms.
testIsValidDirectoryPath:
fails on line 330:
assertTrue(instance.isValidDirectoryPath("test", "/bin/sh", parent,
false)); // Standard shell
The test here, and not isValidDirectoryPath, is incorrect.
isValidDirectoryPath should, and does, return false. The path, though
valid, points to a file and not a directory.
testIsInvalidFilename:
This test fails on a filename being passed as valid when it has a backslash
('') in it. The test expects this to be rejected as invalid which is
probably a good idea. The problem is that during the validation the
filename is canonicalized using the encoder. The encoder includes the
JavaScript codec which removes the backslash. When the canonicalized
filename is validated it no longer contains the backslash and validation
succeeds.
I am not familiar enough with the ESAPI.properties, but changing
"Encoder.DefaultCodecList" is not having any affect on the encoders
actually used (validated by inserting printlns). Canonicalize is also
applying the codecs repeatedly until nothing changes which seems to be
contrary to the default Encoder.AllowMultipleEncoding=false as well.
Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=39