wlchou/owasp-esapi-java

Automatically exported from code.google.com/p/owasp-esapi-java

owasp-esapi-java's Issues

Strengthen symmetric encryption in OWASP ESAPI

1) Provide alternative to the ECB cipher mode that version 1.4 required you
to use because it did not support IV. Default is now CBC cipher mode with
random IV.
2) Provide mechanism to use alternate secret encryption key rather than
requiring the use of the single secret key specified by Encryptor.MasterKey.
3) Allow encrypted messages to be checked for authenticity by including an
HMAC-SHA1 using a derived key.
4) Uniformly ensure that "UTF-8" encoding is being used throughout so that
encryption / decryption will work correctly across platforms with different
native encodings.

NOTE: This work is already completed. This issue is simply for tracking
purposes to assist with the release notes for 2.0.

Original issue reported on code.google.com by [email protected] on 6 Nov 2009 at 10:28

Authenticator.verifyPasswordStrength thinks "password123" is a good password

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 reported on code.google.com by [email protected] on 4 Aug 2009 at 3:11

ESAPI.validator().isValidHTTPRequest always returns true from ESAPIFilter.doFilter

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 reported on code.google.com by [email protected] on 15 Jan 2009 at 3:59

1.4 -> 2.0 migration issues with SafeRequest/Response

Due to release and testing cycles, I am using the latest stable release as
of a couple weeks ago, which is 1.4.  Even if the 2.0 changes are
backported, that doesn’t solve the problem of timelines or the removal of
classes.  The issue here is breaking existing implementations.  Kevin made
the following suggestion for 2.0 which makes some sense

In the case of SafeRequest and SafeResponse if it's simply a case of them
being renamed to SecurityWrapperRequest and SecurityWrapperResponse
respectively we can just do something like this:

                /** Old class name for {@code SecurityWrapperRequest}.
                 * @see SecurityWrapperRequest
                 * @deprecated This class will be removed in release 2.1.
             *             Use {@code SecurityWrapperRequest} instead.
                 */

                public class SafeRequest extends SecurityWrapperRequest {
                  ... declare / implement whatever public CTORs you
previously had ...
                }

and ditto for SafeResponse. Then people's old code should still work. Come
release 2.1 (or 3.0 or whatever), remove this.

Original issue reported on code.google.com by [email protected] on 5 Nov 2009 at 10:47

JSP TagLibrary additional tags and EL functions:W

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 reported on code.google.com by [email protected] on 17 Oct 2009 at 4:53

ESAPI property file values are being logged

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 reported on code.google.com by [email protected] on 8 Oct 2009 at 9:24

Missing property notifications

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 reported on code.google.com by [email protected] on 3 Sep 2009 at 9:23

defect: tld for JavaScript & HTMLAttribute encoding references wrong code

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 reported on code.google.com by [email protected] on 15 Oct 2009 at 8:54

ExecutorTest on linux fails

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\\System3
2\\runas.exe
When the ExecutorTest tries to run /bin/sh it fails as this is not in the
list of approved executables.

2. 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.

3. Executor.WorkingDirectory=C:\\Windows\\Temp
As this is unusable as a working directory on most unix/linux systems, this
test fails.

4. 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

Original issue reported on code.google.com by [email protected] on 20 Oct 2009 at 3:10

Attachments:

• trunk-executortest-fix.patch

Some default ESAPI.properties Validator patterns only allow one character

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 reported on code.google.com by [email protected] on 15 Jan 2009 at 4:07

suspicion of double encoding in referrer field - prob. false alarm

What steps will reproduce the problem?
1.Create a HTTP Request where the referrer field holds a URL with an
ampersand (&) for parameters.
2.
3.

What is the expected output? What do you see instead?
referrer field with amperstand should be legit.
Instead, ESAPI finds it as a double encoding hacking attach.

What version of the product are you using? On what operating system?
1.4 on Unix

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 25 Oct 2009 at 1:10

Refactor jsp tag handlers to remove duplicated functionality

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 reported on code.google.com by [email protected] on 15 Oct 2009 at 6:16

JavaEncryptor.seal/unseal does not escape data, unseal method not in unit tests

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 reported on code.google.com by [email protected] on 7 Aug 2009 at 6:23

org.owasp.esapi.reference.ValidatorTest issues

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 reported on code.google.com by [email protected] on 19 Oct 2009 at 9:16

esapi.tld

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 reported on code.google.com by chrisisbeef on 14 Oct 2009 at 7:18

SecurityConfigurationTest failure

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.

Original issue reported on code.google.com by [email protected] on 20 Oct 2009 at 5:38

Attachments:

• trunk-secconftest-fix.patch

DefaultHttpUtilities.getParameter gets headers, not parameters

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 reported on code.google.com by [email protected] on 28 Jul 2009 at 8:55

context path validation error

In the Validator properties in 2.0rc2 (no property is provided in 1.4) the
context path is validated as ^[a-zA-Z0-9.\\-_]*$.   At least on weblogic &
jboss, I get / as the leading character when calling this method.  Should
this be changed to ^/?[a-zA-Z0-9.\\-_]*$ in the reference implementation? 
Is there an appserver that doesn’t return a leading slash?

Original issue reported on code.google.com by [email protected] on 5 Nov 2009 at 9:57

RandomAccessReferenceMap.update() can randomly corrupt the map

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 reported on code.google.com by [email protected] on 6 Aug 2009 at 7:33

ESAPI authentication bug

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

Original issue reported on code.google.com by [email protected] on 19 Nov 2008 at 9:24

Attachments:

• [Bugs in ESAPI Authenticator.doc](https://storage.googleapis.com/google-code-attachments/owasp-esapi-java/issue-5/comment-0/Bugs in ESAPI Authenticator.doc)

ESAPIFilter in RI should allow login page destination to be configured

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 reported on code.google.com by chrisisbeef on 24 Jul 2009 at 7:50

Separate Crypto Related Properties into Separate File

It has been requested that the crypto properties be kept in a different
file for more separation and fine grained control of information.  

Original issue reported on code.google.com by [email protected] on 6 Nov 2009 at 7:56

getValidSafeHTML code is commented out - only throws an Exception

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 reported on code.google.com by [email protected] on 7 Apr 2008 at 5:38

Cannot get esapi to run on eclipse

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 reported on code.google.com by [email protected] on 24 Feb 2009 at 11:33

DefaultHttpUtilities.addCookie does not set secure flag when not using httponly

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 reported on code.google.com by [email protected] on 28 Jul 2009 at 5:03

Unit tests should test interface and only interface

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 reported on code.google.com by [email protected] on 31 Jul 2009 at 7:46

• Blocked on: #186

Bug on org.owasp.esapi.filters.SafeRequest method getParameterValues

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 reported on code.google.com by [email protected] on 13 Apr 2009 at 11:52

LogFactories cast to DefaultSecurityConfiguration

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...

Original issue reported on code.google.com by [email protected] on 20 Oct 2009 at 2:16

Attachments:

• trunk-logfactory-config-cast.patch

htmlCodec.decode is broken for all entities where entity.substr(0, x) exist

Test cases :

        assertEquals( "²", htmlCodec.decode("&sup2") );        
        assertEquals( "²", htmlCodec.decode("²") );

return ⊃2 instead of ².

It's because HTMLEntityCodec.getNamedEntity stop at the first entity found
so it will never return &sup2 or &sup3 because &sup exists, neither &piv
because &pi exists and may be other.

Attach is patch and test case added

Original issue reported on code.google.com by [email protected] on 30 Oct 2009 at 11:06

Attachments:

• Patch-owasep-esapi-HTMLEntityCodec.txt

esapi.tld not being included in jar

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 reported on code.google.com by [email protected] on 15 Oct 2009 at 8:27

ClassCastException org.owasp.esapi.filters.SafeRequest cannot be cast to javax.servlet.ServletRequestWrapper using jdk1.6

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 reported on code.google.com by [email protected] on 14 May 2009 at 3:11

CodecTest failures

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.

Original issue reported on code.google.com by [email protected] on 20 Oct 2009 at 7:42

Attachments:

• trunk-codectest-fix.patch

Strips quotes from font-family?

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 reported on code.google.com by [email protected] on 28 Aug 2009 at 8:43

Error building

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 reported on code.google.com by [email protected] on 22 Dec 2008 at 10:35

INFO logging is not working for the ESAPI reference implementation

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 reported on code.google.com by [email protected] on 28 Dec 2008 at 7:36

Change ESAPI.properties properties to disallow empty filenames and directory names

In the ESAPI.properties file there were two regular expressions used to
check for valid filenames and directory names. Specifically the properties
Validator.FileName and Validator.DirectoryName both allowed 0 length (i.e.,
empty) file and directory names.

This is to change the suffix on the regular expressions for these two
properties from '{0,255}' to '{1,255}' so that 0 length file names and
directory names will no longer be accepted as valid.

Original issue reported on code.google.com by [email protected] on 6 Nov 2009 at 10:50

Large Input Errors Out

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 reported on code.google.com by [email protected] on 12 Mar 2009 at 3:15

Executor.executeSystemCommand has an invalid path comparison and throws exception

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 reported on code.google.com by [email protected] on 7 Apr 2008 at 5:54

DefaultHttpUtilies implementation throw nullpointer

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 reported on code.google.com by [email protected] on 19 Nov 2008 at 10:57

Does not build with tests out of the box

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 reported on code.google.com by [email protected] on 3 Sep 2009 at 7:40

URLs in doc for HTTPUtilities.setNoCacheHeaders are wrong

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 reported on code.google.com by [email protected] on 27 Jul 2009 at 5:35

Broken Javadocs link

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 reported on code.google.com by [email protected] on 8 Dec 2008 at 11:10

Removing Newline in EncodeForHTMLTag and EncodeForHTMLAttributeTag

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:

</option>
          <option value="Personal &amp; Household Goods
">
                Privat &amp;amp&#59; Haushaltswaren

</option>
          <option value="Oil &amp; Gas
">
                &Ouml;l &amp;amp&#59; Gas

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

Original issue reported on code.google.com by [email protected] on 7 Oct 2009 at 8:11

Minor length-checking error message problem

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 reported on code.google.com by [email protected] on 1 Jul 2009 at 3:40

Unit test org.owasp.esapi.UserTest throws InvalidAccountName Exception

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.<init>(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 reported on code.google.com by [email protected] on 7 Apr 2008 at 5:14

MySQL CODEC : "_" character not handled properly ?

The "_" and" %" characters are escaped but
http://mirror.yandex.ru/mirrors/ftp.mysql.com/doc/refman/5.0/en/string-syntax.ht
ml
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 <table> WHERE
<field>='TEST\_1' which will not return the row. 

Original issue reported on code.google.com by [email protected] on 24 Jul 2009 at 9:41

Typo in DefaultValidator.getValidFileName

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 reported on code.google.com by [email protected] on 8 Jul 2009 at 2:37

FileBasedAuthenticator.verifyPasswordStrength does not calculate number of character sets correctly

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 reported on code.google.com by [email protected] on 25 Jun 2009 at 11:14

DefaultEncoder does not use custom codecs

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)

Original issue reported on code.google.com by [email protected] on 21 May 2009 at 4:51

• Merged into: #68

Attachments:

• DefaultEncoder.java

DefaultEncoder deadlock

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 reported on code.google.com by planetlevel on 20 Dec 2008 at 2:30