esapi / esapi-java-legacy Goto Github PK

From [email protected] on September 03, 2009 03:40:07

What steps will reproduce the problem? 1. Download trunk
2. Try to run the maven build What is the expected output? What do you see instead? I expect it to build and all tests to pass What version of the product are you using? On what operating system? trunk on winxp Please provide any additional information below. I know about: http://www.owasp.org/index.php/ESAPI-Building But in my opinion that is not good enough. The unit tests are not working,
which does not give me confidence in the product. Not sure if it's realted
but the pom.xml contains a file path to a local file
c:/users/jwilliams/desktop/keystore

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=30

From [email protected] on July 28, 2009 16:55:12

Line 608 of DefaultHttpUtilities:
String value = request.getHeader(name);

So it gets a header, just like getHeader, instead of the parameter. I think
getParameter was what was intended: http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/ServletRequest.html#getParameter(java.lang.String) But that spec is decidedly ambiguous - Does the param come from POST or
GET? I'm not sure if we really want to use that... What version of the product are you using? On what operating system? SVN revision 574 .

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=24

Skipping this issue number to maintain synchronization with Google Code issue IDs.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=324

From [email protected] on October 15, 2009 16:27:59

What steps will reproduce the problem? 1. build espi
2. look fof META-INF/esapi.tld in final jar What is the expected output? What do you see instead? esapi.tld needs to be in the final jar's META-INF directory so that servlet
containers can find it during deployment of a web application using esapi. What version of the product are you using? On what operating system? Trunk 688 Please provide any additional information below. It looks like when the patch was applied esapi.tld was put into
src/main/java/META-INF/ instead of src/main/resources/META-INF/. I'm a
rather new maven user but it looks like maven isn't including the META-INF
directory from src/main/java/. Moving it to the resources directory fixes
the issue.

Thanks!

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=36

Skipping this issue number to maintain synchronization with Google Code issue IDs.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=330

From [email protected] on October 19, 2009 23:10:32

What steps will reproduce the problem? 1. checkout current trunk from svn on a unix/linux system
2. run mvn -Dtest=ExecutorTest test 3. What is the expected output? What do you see instead? Test should succeed. Test fails What version of the product are you using? On what operating system? Trunk revision 700 Please provide any additional information below. There are four causes to this test failure. Two of them relate to the
platform dependent ESAPI.properties: 1. Executor.ApprovedExecutables=C:\Windows\System32\cmd.exe,C:\Windows\System32\runas.exe
When the ExecutorTest tries to run /bin/sh it fails as this is not in the
list of approved executables.

1. Appending or changing the ApprovedExecutables is insufficient as many
   unix/linux systems have /bin/sh sym linked to a different executable
   (Debian sid points to /bin/bash or /bin/dash depending on your configs).
   This also causes the test to fail.
2. Executor.WorkingDirectory=C:\Windows\Temp
   As this is unusable as a working directory on most unix/linux systems, this
   test fails.
3. There are four seperate calls to executeSystemCommand. The first and the
   third are identical except that the first expects it to work without
   exception and the third expects it to fail with an exception. I see no
   difference between the two but perhaps I am missing something.

Attached is a patch that is one viable solution to these problems. It
includes a SecurityConfigurationWrapper that just wrapps requests to
another SecurityConfiguration. This allows for a easy replacement of
properties at test run time.

With such in hand, the patch get's the canonical path for /bin/sh and
replaces the allowed executables with this fixing 1 & 2 above. Similarly it
replaces the working directory with /tmp fixing 3 above.

Lastly, the patch removes the duplicate, yet contradictory, test discussed
in #4.

As this patch uses a different implemenation of SecurityConfiguration, the
issue discussed in issue 40 needs to be fixed first or the test fails with
a ClassCastException.

It seems like there should be a way to configure esapi in a non-platform
dependent manner. This is especially problematic with proposals for 2.0
including a esapi properties in the jar. Deployment of the jar on a
different platform would require external configurations or modification of
the jar itself. The latter would cause issues with jar signing or policies
forbidding librarys from being modified. Is there a way around this problem
that I am not seeing?

Thanks

Attachment: trunk-executortest-fix.patch

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=41

From [email protected] on August 07, 2009 14:23:39

Bad test case:
public void testSeal2() throws IntegrityException, EncryptionException {
Encryptor instance = ESAPI.encryptor();
String plaintext = "MY:DATA";
String seal = instance.seal( plaintext, instance.getTimeStamp() +
1000*60 );
instance.verifySeal( seal );
String unsealed = instance.unseal(seal);
assertEquals(unsealed, plaintext);
}

Information:

The seal/unseal system in JavaEncryptor uses a colon (':') to delimit the
parts of the seal (expiration, random data, and data). Because colons are
not escaped and the data not encoded, colons in the data will cause the
produced seal to be unsealable, throwing an "Invalid seal" exception.

In addition, the unseal method is not tested in the unit tests.

Recommendations in descending order of preference:

• Ascii armor the data by base64 encoding it to ensure the delimiter is not
  in the data when composing the seal.

OR

• Use an escaping scheme to escape the delimiter.

OR

• State explicitly in the doc that the data cannot contain the delimiter.

AND test the unseal method in the unit tests. What version of the product are you using? On what operating system? SVN revision 574 .

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=28

From [email protected] on October 17, 2009 12:53:51

What steps will reproduce the problem? 1. 2. 3. What is the expected output? What do you see instead? What version of the product are you using? On what operating system? Please provide any additional information below.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=38

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

From [email protected] on October 19, 2009 22:16:22

Both JavaLogFactory & Log4JLogFactory needlessly cast
ESAPI.securityConfiguration() to DefaultSecurityConfiguration making other
implementations of SecurityConfiguration cause ClassCastExceptions. What version of the product are you using? On what operating system? trunk revision 700 Please provide any additional information below. Trivial patch attached...

Attachment: trunk-logfactory-config-cast.patch

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=40

From [email protected] on April 07, 2008 13:14:16

What steps will reproduce the problem? 1. Brought up Project under Eclipse 3.3 using Java 1.6
2. Added "test" directory as a source directory.
3. Added VM argument
-Dorg.owasp.esapi.resources="/owasp/test/testresources"
4. The UserTest unit tests report an error:
org.owasp.esapi.errors.AuthenticationCredentialsException: Invalid
account name
at org.owasp.esapi.Authenticator.verifyAccountNameStrength
(Authenticator.java:653)
at org.owasp.esapi.User.(User.java:190)
at org.owasp.esapi.Authenticator.createUser
(Authenticator.java:237)
(the rest deleted)... What is the expected output? What do you see instead? Expected a "passed" or "failed" What version of the product are you using? On what operating system? Product Version: ESAPI v1.1.1 Complete JAR file
OS: Windows XP
Java: 1.6 update 5

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=1

From [email protected] on September 03, 2009 05:23:19

What steps will reproduce the problem? Run ESAPI without the necessary properties set in ESAPI.properties:

1. Install JCE (Java Cryptography Extension)
2. Comment out property 'Encryptor.MasterKey'
3. invoke ESAPI.encryptor().encrypt(regularString); What is the expected output? What do you see instead? I see:
   looong stacktrace, including these lines:
   WARNING: [Anonymous:null@unknown -> /DefaultName/IntrusionDetector] Must
   install unlimited strength crypto extension from Sun
   org.owasp.esapi.errors.EncryptionException: Encryption failure What version of the product are you using? On what operating system? Using trunk on Ubuntu 9.04 Please provide any additional information below. I believed that my problems were rooted in not being able to install JCE
   properly; this was wrong; the problem was missing properties and poor error
   handling in DefaultSecurityConfiguration.

• DefaultSecurityConfiguration: report missing properties
• Improve logging in JavaEncryption (and generally)

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=31

From chrisisbeef on July 24, 2009 03:50:59

Rather than force uses of the RI to have their login page be located at
/WEB-INF/login.jsp we should allow configuration of where the users should
be forwarded in the event that a forward or redirect needs to occur to log
the user in.

We should be able to add a line to the ESAPI.properties file which allows
the user to specify where login requests should be sent.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=20

From [email protected] on August 28, 2009 16:43:02

Given a style tag containing:

body {
font-family: "Arial Unicode MS" , Arial , sans-serif;
}

It seems to convert it into:

body {
font-family: Arial Unicode MS , Arial , sans-serif;
}

However, I'm not sure whether browsers will interpret the second the same
as the first.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=29

From planetlevel on December 19, 2008 21:30:06

What steps will reproduce the problem? > > This is the code that we were using:

public static String javaScriptEncode(String str){
    DefaultEncoder encoder = new DefaultEncoder();
    return encoder.encodeForJavaScript(str);
}

When two threads attept to instantiate the DefaultEncoder object at
the same
time, one thread seems to wait indefinately, consuming all server
CPU. I am
not sure exactly where this happens in the OWASP code, but moving
the
instantiation of the DefaultEncoder to the class level seems to fix
this
issue. Please note that this was consuming CPU for other
applications on
the same hardware we are on.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=7

From [email protected] on August 04, 2009 11:11:31

In AuthenticatorTest.java there is this test:
try {
instance.verifyPasswordStrength("password", "password123");
fail();
}
catch ...

The test passes, indicating that verifyPasswordStrength raised an exception
about the password quality, but only because it is too similar to the
previous password (the first param). Passing in an empty string instead of
"password" will cause the test to fail, because in the default
implementation, "password123" will have a "strength" of 22. 11 chars * 2
charsets = strength of 22, which is > than the 16 limit. Can't we come up
with a better metric? A couple suggestions:

1. Make a verifyPasswordStrength(String) method that will only check the
   new password. Also, make generateStrongPassword call verifyPasswordStrength
   before returning output.
2. Add into the API doc that it is a good idea that the implementation
   compare the password to a dictionary list, and that the default
   implementation does not do this.
3. Can we change the "strength" algorithm to something a bit better? How
   about number of bits of entropy? First, check what charsets are being used.
   Add up the length of the charactersets in use, yielding the length of the
   whole charset of the password, N. The entropy per symbol is then log(N)
   base 2, and multiplied by the length of the password will give its entropy
   in bits.

This metric is less valid for human-generated passwords. An alternative is
to up the strength limit. What version of the product are you using? On what operating system? SVN revision 574 .

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=26

From [email protected] on November 19, 2008 16:24:03

What steps will reproduce the problem? When submitting a username and password pair over a SSL link established
with a self-signed certificate to Webgoat application running on the
localhost, the ESAPI validated the password submitted but aborted the login
process with exceptions.

The exceptions were AccessControlException and AuthenticationException with
a message “Received non-SSL request”. The exception occurred in ESAPI
component IntrusionDetector. What is the expected output? What do you see instead? the request was submitted over SSL link, and password has been validated.
So, authentication success should be expected instead of an "Non-SSL
request" exception. What version of the product are you using? On what operating system? ESAPI 1.3
Webgoat 5.2 developer edition
JDK 1.6
WinXP Professional, SP2 Please provide any additional information below. - Please see attachment for detailed audit log

Attachment: Bugs in ESAPI Authenticator.doc

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=5

From [email protected] on July 27, 2009 13:35:29

Something happened when copying/pasting the URLs for this doc, as they are
off-by-one and wrong.

These are what the URLs should be, in epydoc format. You'll have to convert
them to HTML.

• U{HTTP/1.1 Cache-Control
  "no-cache"< http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1> }
• U{HTTP/1.1 Cache-Control
  "no-store"< http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.2> }
• U{HTTP/1.0 Pragma
  "no-cache"< http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32> }
• U{HTTP/1.0
  Expires< http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21> }
• U{IE 6 Caching Issues< http://support.microsoft.com/kb/937479> }
• U{Microsoft directly violates specification for pragma:
  no-cache< http://support.microsoft.com/kb/234067> }
• U{Firefox
  browser.cache.disk_cache_ssl< https://developer.mozilla.org/en/Mozilla_Networking_Preferences#Cache> } What version of the product are you using? On what operating system? Latest SVN.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=22

Skipping this issue number to maintain synchronization with Google Code issue IDs.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=236

From [email protected] on August 06, 2009 15:33:16

What steps will reproduce the problem? You have a ARM set up like this:
direct1 <=> "AAAA"

You do this:
newSet = new Set()
newSet.add(newDirect)
newSet.add(direct1)
ARM.update(newSet)

update() clears the old mappings, but tries to preserve them if the same
direct objects are referenced in the new set. Here's how this could go awry:

• update() clears both maps
• update() can't find newDirect in the old mapping, so it calls
  getUniqueRandomReference(), which randomly returns "AAAA". It checks that
  "AAAA" is not in the current mapping, and it's not (It was just cleared).
• update() sets the mapping newDirect <=> "AAAA"
• update() then looks at direct1, sees that it is in the old mapping, and
  sets it in the new mapping direct1 <=> "AAAA", corrupting the indirect to
  direct mapping which is now "AAAA" -> direct1

How to fix it:

• Change getUniqueRandomReference to take in a list of invalid indirect
  keys and ensure the generated one is not in that list
• Preserve the old indirect to direct map in update()
• Pass in the keys of the old indirect to direct map to
  getUniqueRandomReference What version of the product are you using? On what operating system? SVN revision 574 .

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=27

From [email protected] on June 25, 2009 07:14:48

Latest ESAPI downloaded 25 June 2009 from http://owasp-esapi-java.googlecode.com/files/owasp-esapi-java-src-1.4.zip The verifyPasswordStrength calculates number of character sets using binary
searches like this:
Arrays.binarySearch(DefaultEncoder.CHAR_LOWERS, newPassword.charAt(i)) > 0

However, if newPassword.charAt(i) = 'a', the result of the binary search
will be 0 and the greater than comparison will return false.

Tests should be greater than or equal like this:
Arrays.binarySearch(DefaultEncoder.CHAR_LOWERS, newPassword.charAt(i)) >= 0

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=17

From [email protected] on July 08, 2009 10:37:09

In DefaultValidator.java, inside getValidFileName(), there is this call on
line 420.

throw new ValidationException( context + ": Invalid file name", "Invalid
directory name does not match the canonical path: context=" + .... What is the expected output? What do you see instead? It should say "Invalid file name" instead of "Invalid directory name" in
the logged message. What version of the product are you using? On what operating system? Latest SVN.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=19

From [email protected] on December 22, 2008 05:35:46

What steps will reproduce the problem? 1. Download ESAPI from SVN via ECLIPSE, with maven installed, java 1.5
2. Check error panel for message like "Severity and Description Path
Resource Location Creation Time Id
Required library cannot denote external folder: 'C:\Documents and
Settings\jmanico.m2\repository' for project 'ESAPI' ESAPI Build path
1229941691954 114109" What is the expected output? What do you see instead? I would expect everything to just magically work =) Please use labels and text to provide additional information. war build eclipse maven java 1.5 tomcat 5

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=8

From [email protected] on May 21, 2009 12:51:27

What steps will reproduce the problem? 1. Call the DefaultEncoder constructor with List of Codecs as parameter and
pass a list containing a customized JavaScriptCodec that implements Codec
interface
2. Then call the encodeForJavascript method and pass a string.
3. The encoding performed on the string is the default encoding and not the
intended custom encoding as per the codec object passed in the codecs list
that is passed to the constructor What is the expected output? What do you see instead? The encoding should be done as per the customized encodeCharacter method
but it is done using the default encodeCharacter method (belonging to the
org.owasp.esapi.codecs.JavaScriptCodec class) What version of the product are you using? On what operating system? Using owasp-esapi-full-java-1.4.jar, Windows XP. Please provide any additional information below. I saw the DefaultEncoder code and in the DefaultEncoder(List list) at line
70, I see that codecs member is being updated but then the private Codec
variables are not being updated with the ones that are contained the codec
list.
Fix in my opinion:
I think the codec list should be looped through and based on the codec
objects contained, the corresponding private codec memebers should be
updated. For eg: If the codecs list passed has a JavaScriptCodec object,
the private memeber javaScriptCodec should be updated with the object in
the codecs list so that eventually, its encodeCharacter will be called
instead of the method from the default value (to the
org.owasp.esapi.codecs.JavaScriptCodec class)

Attachment: DefaultEncoder.java

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=16

From chrisisbeef on October 14, 2009 15:18:40

Greetings,

I was wondering about the current state of the ESAPI JSP tags. I'm
looking to use them from JSP documents (jspx) and have had some issues.

Specifically, the TLD in the 1.4 release incorrectly sets the URI to be
" http://struts.apache.org/tags-html ". Is there a URI that this should
be changed to instead? I patched it with the URL for the wiki page and
was able to get it working. The tld is not included in the final JAR so
you have to add a taglib declaration to the deployment descriptor and
include the TLD explicitly.

I'm not seeing a TLD in the 2.0 stuff at all.

On another note, I'm interested in getting involved some in the
project. I'm not very knowledgeable about JSP but I can figure it out
if that would be desired. Other than that, where would a good place to
start be? Getting units working? CPD/FindBugs/PMD fixes?

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=34

From [email protected] on October 15, 2009 14:16:42

Refactor JSP tag handlers to have duplicated functionality in a common base
class. What version of the product are you using? On what operating system? Patch is vs. trunk revision 688 Please provide any additional information below. * Refactor common encode tag code to BaseEncodeTag
* change tags to extend BaseEncodeTag
* replace tag's implementation of doAfterBody with implementation
of BaseCodeTag's abstract encode method.
* bump tag's serialVersionUIDs again as the superclass has changed.
* add javadoc comments

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=35

From [email protected] on April 07, 2008 13:54:54

What steps will reproduce the problem? 1. Windows XP Professional
2. Java 1.6 update 5
3. Eclipse 3.3
4. run JUnit "ALLTests" What is the expected output? What do you see instead? ExecutorTest.java gets an assertion failure due to an incorrect exception
thrown by Executor.executeSystemCommand. This method compares the
canonical path to the path supplied to the executable. It uses an "equals"
operation when an "equalsIgnoreCase" will produce the required results.

Canonical Path: C:\WINDOWS\system32\cmd.exe
Executable Path: C:\Windows\System32\cmd.exe
The following code is then executed: throw new ExecutorException
("Execution failure", "Invalid path to executable file: " + executable);

What version of the product are you using? ESAPI v1.1.1 Complete JAR file

On what operating system? Windows XP professional
Java 1.6 update 5 Please provide any additional information below.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=3

Skipping this issue number to maintain synchronization with Google Code issue IDs.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=225

Skipping this issue number to maintain synchronization with Google Code issue IDs.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=308

From [email protected] on February 24, 2009 06:33:52

I use Eclipse with Tomcat 5.5 and JRE 1.4.2 for a simple demo project.

owasp-esapi-full-java-1.4.jar is in my lib-folder AND added to the J2EE
Module Dependencies.

Used several methods to add the properties file to my VM arguments.

I continually get the following Exception report on a simple jsp file:

org.apache.jasper.JasperException: org/owasp/validator/html/PolicyException

I suspect there should be a "esapi" in the object path, but owasp is
immediately followed by validator. Since there is no documentation of
installation or troubleshooting the installation is seek for help here.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=12

From [email protected] on April 07, 2008 13:38:04

What steps will reproduce the problem? 1. Run JUnit tests with ESAPI

I just want to confirm that this is the intended behavior of this release.
There is Antisamy code commented out in the method.

Product version: ESAPI v1.1.1 Complete JAR file

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=2

From [email protected] on October 07, 2009 04:11:56

I am using the EncodeForHTMLTag and the EncodeForHTMLAttributeTag and have
the following change-request:

Both tags add a newline after encoding the content. This leads to
unnecessarly long HTML-pages which sometimes produce rendering problems in
some browsers. Here is an example of the html-output:

Replacing
out.println( e.encodeForHTML(content) );
with
out.print( e.encodeForHTML(content) );
would solve the problem.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=32

From [email protected] on December 28, 2008 02:36:23

What steps will reproduce the problem? 1. make any logger.info call, note it does not appear in log files
2. try any logger.error call, and note that is does appear in log files 3. What is the expected output? What do you see instead? Please use labels and text to provide additional information.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=9

From [email protected] on May 14, 2009 11:11:05

We are getting the following error on chain.doFilter in the filter class
after we use the SafeRequest and SafeResponse with jdk1.6

ERROR [com.pgi.web.filter.SecureHttpFilter] java.lang.ClassCastException:
org.owasp.esapi.filters.SafeRequest cannot be cast to
javax.servlet.ServletRequestWrapper

The following line of code is used in the filter class:-

HttpServletRequest hrequest = (HttpServletRequest) request;
HttpServletResponse hresponse = (HttpServletResponse) response;
ESAPI.httpUtilities().setCurrentHTTP(hrequest, hresponse);

                        chain.doFilter(ESAPI.httpUtilities().getCurrentRequest(),

ESAPI.httpUtilities().getCurrentResponse());

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=15

From [email protected] on July 31, 2009 15:46:21

The unit tests packaged with ESAPI should only test the interface and not
contain code that is specific to the default implementations. This means
two things in particular:

1. All types should be from the API interfaces
2. Methods called on instances being tested should only reflect those in
   the API

Specific tests that call methods not in the API:

• AuthenticatorTest.testSaveUsers

... more to come.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=25

From [email protected] on July 24, 2009 05:41:04

The "" and" %" characters are escaped but http://mirror.yandex.ru/mirrors/ftp.mysql.com/doc/refman/5.0/en/string-syntax.html specifies that these characters have specific behaviours :"If you use “%”
or “_” outside of pattern-matching contexts, they evaluate to the strings
“%” and “”, not to “%” and “_”. "

Example : if we have a table FOO with a row with field VALUE_FOO='TEST_1',
the SQL command to retrieve this row : SELECT * FROM FOO WHERE
VALUE_FOO=encodeForSQL('TEST_1') will become : SELECT * FROM

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=21

From [email protected] on October 20, 2009 13:38:42

What steps will reproduce the problem? 1. checkout current trunk ( revision 701 )
2. mvn -Dtest=SecurityConfigurationTest test What is the expected output? What do you see instead? Tests should pass. One test errors. What version of the product are you using? On what operating system? trunk revision 701 .
x86_64-unknown-linux-gnu/Debian Sid/Sun hotspot jvm 1.60 16 Please provide any additional information below. The test that is failing is testGetResourceFile(). This test is as follows:
ESAPI.securityConfiguration().getResourceFile(null);
The current implementation of getResourceFile(String) in
DefaultSecurityConfiguration passes this null directly to new File()
causing a NullPointerException (NPE).

Looking at the end of the method, null is supposed to be returned if the
file is not found. The attached patch also returns null for a null filename
allowing the test to pass. The patch also updates the java doc to describe
returning null when the file is not found.

It's interesting to note that getResourceStream(String) would exhibit the
same behavior except it catches all Exceptions (including the NPE) and
tries the class loader instead.

Attachment: trunk-secconftest-fix.patch

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=42

From [email protected] on October 08, 2009 17:24:30

What steps will reproduce the problem? 1. Trail logs during server starup
2. Watch ESAPI log all property values 3. What is the expected output? What do you see instead? I expect the security property file values to not be logged. What version of the product are you using? On what operating system? All. Please provide any additional information below. The users is right and we are going to fix this soon.
Jeff proposes we add a flag to turn off logging display, so we can leave it
on during development. Turn this off by default.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=33

From [email protected] on November 19, 2008 05:57:59

The implementation of
DefaultHttpUtilities.decryptStateFromCookie(HttpServletRequest) throws a
NullPointerException.

If the request does not contain cookies with name "state" then the line:

• String encrypted = c.getValue();
  will throw a NullPointerException as there is no value for c. What version of the product are you using? On what operating system? 1.4, java 5 Please provide any additional information below. A (temporary) workaround could be to do a check for cookies with name
  "state" before calling the decryptStateFromCookie method. This would mean,
  however, that the calling party should know how the cookies are stored in
  the request. This is not desirable.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=4

Skipping this issue number to maintain synchronization with Google Code issue IDs.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=197

From [email protected] on January 15, 2009 11:07:19

The default ESAPI.properties has some validation patterns that only allow
one character. :

Validator.HTTPServerName=^[a-zA-Z0-9_.-]$
Validator.HTTPContextPath=^[a-zA-Z0-9.-]$
Validator.HTTPPath=^[a-zA-Z0-9.-]$
Validator.HTTPQueryString=^[a-zA-Z0-9()-=_.?;,+/:&_ ]$
Validator.HTTPURI=^[a-zA-Z0-9()-=_.?;,+/:&_ ]$

We needed to add a quantifier to each defined character class to support
more characters.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=11

Skipping this issue number to maintain synchronization with Google Code issue IDs.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=271

From [email protected] on March 12, 2009 11:15:22

What steps will reproduce the problem? 1. Passing AntiSamy.scan an input large then 20,000 bytes What is the expected output? What do you see instead? Processed HTML. What version of the product are you using? On what operating system? 1.2 on Solaris Please provide any additional information below. Stack Trace:
[exec] Caused by: org.owasp.validator.html.ScanException: The input
was too large. The specified input was 24,771 bytes and the maximum is
20,000 bytes.
[exec] at
org.owasp.validator.html.scan.AntiSamyDOMScanner.scan(Unknown Source)
[exec] at org.owasp.validator.html.AntiSamy.scan(Unknown Source)

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=13

From [email protected] on April 13, 2009 07:52:48

What steps will reproduce the problem? 1. ESAPI.httpUtilities().setCurrentHTTP(request, response);

HttpServletRequest req =
(HttpServletRequest)ESAPI.httpUtilities().getCurrentRequest();

req.getParameterValues(name));

What I get is

java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to
[Ljava.lang.String;
org.owasp.esapi.filters.SafeRequest.getParameterValues(Unknown Source)

ESAPI 1.4 on Mac OS X 10.5.6

I get this error when I use bind method in Spring Framework

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=14

From [email protected] on October 20, 2009 15:42:38

What steps will reproduce the problem? 1.checkout source
2.mvn -Dtest=CodecTest test What is the expected output? What do you see instead? CodecTests should pass
All 4 CodecTests fail What version of the product are you using? On what operating system? trunk revision 701 x86_64-unknown-linux-gnu/Debian Sid/Sun hotspot 1.6.0 Please provide any additional information below. All of these tests were failing testing the Oracle codec. They were testing
back slash escaping in the same way that the mysql "Standard" tests were.
From what I can tell from the Oracle codec, the oracle documentation that
it points to and the like, this type of escaping is not supported by
oracle. Instead it uses the doubled single quote to escape a single quote.
This is the same way that the mysql "ANSI" version does so I'm guessing
that the "Standard" mysql got copied to test oracle instead of the "ANSI"
causing the issue.

Attached is a patch that changes the oracle tests to test for oracle
escaping behavior.

This patch also breaks out the different tests into separate tests. This is
in accordance with my understanding of unit test best practice of just
testing one thing at a time. It also allows other codecs to be tested even
when earlier ones fail (the unix and windows codecs were never tested
because the oracle ones failed). Additionally this makes it clear that just
the oracle codec is failing and not the entire codec subsystem.

Attachment: trunk-codectest-fix.patch

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=43

From [email protected] on December 08, 2008 18:10:47

The Javadocs link on the ESAPI home page is broken.
Here's the URL: http://owasp-esapi-java.googlecode.com/svn/trunk/doc/index.html

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=6

From [email protected] on January 15, 2009 10:59:24

What steps will reproduce the problem? 1. Perform an http request with an parameter value that does not match
whitelist What is the expected output? What do you see instead? The call to isValidHTTPRequest is returning true even though the request is
not valid. What version of the product are you using? On what operating system? Latest SVN Please provide any additional information below. isValidHTTPRequest is validating the input it gets from the SafeRequest.get
methods. The SafeRequest methods are sanitizing the output before
isValidHTTPRequest attempts to validate. In this case, the filter doesn't
catch the bad input and the request is processed normally.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=10

From [email protected] on October 15, 2009 16:54:07

I feel stupid about missing this. The tld specifies that
encodeForJavaScript and encodeForHTMLAttribute use the EncodeForHTMLTag
class instead of the EncodeForJavaScriptHTMLTag and
EncodeForHTMLAttributeTag classes respectively.

I checked the tld from 1.4 and the issue exists there as well

The attached patch fixes the issue. Note that it assumes that the esapi.tld
has been moved to src/main/resources/META-INF ( issue 35 ). The patch is
against trunk revision 688 + issue 35 's change.

I've tested the patch in tomcat 6...

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=37

From [email protected] on July 28, 2009 13:03:38

Lines 174-179 in DefaultHttpUtilities:
if ( ESAPI.securityConfiguration().getForceHttpOnlyCookies() ) {
String header = createCookieHeader(cookieName, cookieValue, maxAge,
domain, path, secure);
addHeader(response, "Set-Cookie", header);
} else {
response.addCookie(cookie);
}

The createCookieHeader method does the right thing, adding the secure flag
if the config says it should and adding the httponly flag if the config
says it should. But when not forcing httponly in the config, the above code
calls response.addCoookie, never checking the config to see if it should
force the secure flag and never modifying the cookie. What version of the product are you using? On what operating system? SVN revision 574 in trunk.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=23

From [email protected] on July 01, 2009 11:40:31

In esapi.reference.validation, StringValidationRule.java:

Lines 99-102:

// check length
if (canonical.length() < minLength) {
throw new ValidationException( context + ": Invalid input. The maximum
length of " + maxLength + " characters was exceeded.", "Input exceeds
maximum allowed length of " + maxLength + " by " +
(canonical.length()-maxLength) + " characters: context=" + context + ",
type=" + getTypeName() + "), input=" + input, context );
}

The error message is incorrect. It should say something like: "The minimum
number of characters (" + minLength + ") was not met." What version of the product are you using? On what operating system? Latest SVN of ESAPI.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=18