Yesterday

• 39 hours ago

  r923 (Changes so that the testUnicodeString() test case will be sk...) committed by kevin.w.wall   -   Changes so that the testUnicodeString() test case will be skipped if unicodeStr and altString are not equal at runtime. (They should be.) This is meant to deal with the Windows-1252 vs. UTF-8 encoding issue on Windows OS. Also changed testOverwrite() so it did not depend on both unicodeStr and altString. Now only uses unicodeStr.

  Changes so that the testUnicodeString() test case will be skipped if unicodeStr and altString are not equal at runtime. (They should be.) This is meant to deal with the Windows-1252 vs. UTF-8 encoding issue on Windows OS. Also changed testOverwrite() so it did not depend on both unicodeStr and altString. Now only uses unicodeStr.

Last 7 days

• Dec 29, 2009

  r922 (Fix ValidatorTest on windows. Two fixes here: one to get the...) committed by schal...@darkmist.net   -   Fix ValidatorTest on windows. Two fixes here: one to get the sysroot location from the env instead of assuming and the other to canonicalize paths even when they're coming from system properties.

  Fix ValidatorTest on windows. Two fixes here: one to get the sysroot location from the env instead of assuming and the other to canonicalize paths even when they're coming from system properties.
• Dec 29, 2009

  r921 (Fix ExecutorTests on windows. Mostly these were issues with ...) committed by schal...@darkmist.net   -   Fix ExecutorTests on windows. Mostly these were issues with assumptions about where the windows directory is located and it's case.

  Fix ExecutorTests on windows. Mostly these were issues with assumptions about where the windows directory is located and it's case.
• Dec 28, 2009

  issue 84 (javadoc correction for PreparedString) reported by david.sklarew   -   What steps will reproduce the problem? 1. View JavaDoc for org.owasp.esapi.PreparedString What is the expected output? As per OracleCodec javadoc, oracle parameters should be single quoted: PreparedString query = new PreparedString( "SELECT * FROM users WHERE name='?' AND password='?'", new OracleCodec() ); What do you see instead? PreparedString query = new PreparedString( "SELECT * FROM users WHERE name=? AND password=?", new OracleCodec() );

  What steps will reproduce the problem? 1. View JavaDoc for org.owasp.esapi.PreparedString What is the expected output? As per OracleCodec javadoc, oracle parameters should be single quoted: PreparedString query = new PreparedString( "SELECT * FROM users WHERE name='?' AND password='?'", new OracleCodec() ); What do you see instead? PreparedString query = new PreparedString( "SELECT * FROM users WHERE name=? AND password=?", new OracleCodec() );

Last 30 days

• Dec 23, 2009

  r920 (gone) committed by manico.james   -   gone

  gone
• Dec 23, 2009

  r919 (Moved here for now.) committed by manico.james   -   Moved here for now.

  Moved here for now.
• Dec 22, 2009

  issue 83 (Ditch DefaultCipherText and make CipherText a concrete class) reported by kevin.w.wall   -   As per email to ESAPI Developers list from Jeff Williams on 12.17.2009 (Message-ID <B9A412898630124ABE8350F4EBD32E840116BE4C@mymail.aspectsecurity.com>), change CipherText to a concrete class and remove the org.owasp.esapi.reference.DefaultCipherText class. In addition, implement custom serialization that is independent of Java so that other ESAPI language implementations can restore original plain text data from serialized CipherText objects. Lastly, also change JUnit tests as appropriate.

  As per email to ESAPI Developers list from Jeff Williams on 12.17.2009 (Message-ID <B9A412898630124ABE8350F4EBD32E840116BE4C@mymail.aspectsecurity.com>), change CipherText to a concrete class and remove the org.owasp.esapi.reference.DefaultCipherText class. In addition, implement custom serialization that is independent of Java so that other ESAPI language implementations can restore original plain text data from serialized CipherText objects. Lastly, also change JUnit tests as appropriate.
• Dec 22, 2009

  r918 (canonicalize functions no longer throw a EncodingException) committed by manico.james   -   canonicalize functions no longer throw a EncodingException

  canonicalize functions no longer throw a EncodingException
• Dec 21, 2009

  r917 (canonicalizing invalid input on return for several Validatio...) committed by manico.james   -   canonicalizing invalid input on return for several ValidationErrorList style getters.

  canonicalizing invalid input on return for several ValidationErrorList style getters.
• Dec 20, 2009

  r916 (fixing html decoder) committed by manico.james   -   fixing html decoder

  fixing html decoder
• Dec 18, 2009

  issue 82 (SafeString validation.properties error on parsing \.) commented on by caughron   -   Wow. Thanks for such a rapid response! Would like to re-test to confirm this fix works in local environment. Is there a jar with this change in it or what is the next planned jar release?

  Wow. Thanks for such a rapid response! Would like to re-test to confirm this fix works in local environment. Is there a jar with this change in it or what is the next planned jar release?
• Dec 17, 2009

  r915 (added html entity decode) committed by manico.james   -   added html entity decode

  added html entity decode
• Dec 17, 2009

  issue 82 (SafeString validation.properties error on parsing \.) Labels changed by chrisisbeef   -  

  Labels: Milestone-Release2.0

  Labels: Milestone-Release2.0
• Dec 17, 2009

  issue 82 (SafeString validation.properties error on parsing \.) changed by chrisisbeef   -   This issue was closed by revision r914.

  Status: Fixed

  This issue was closed by revision r914.

  Status: Fixed
• Dec 17, 2009

  r914 (Fixes Issue 82 Corrected the regex for SafeString and adde...) committed by chrisisbeef   -   Fixes Issue 82 Corrected the regex for SafeString and added new test for regression

  Fixes Issue 82 Corrected the regex for SafeString and added new test for regression
• Dec 17, 2009

  issue 82 (SafeString validation.properties error on parsing \.) Owner changed by chrisisbeef   -  

  Owner: chrisisbeef

  Owner: chrisisbeef
• Dec 17, 2009

  issue 82 (SafeString validation.properties error on parsing \.) Status changed by chrisisbeef   -   This is due to not accounting for spaces in the SafeString regex. Using the regex ^[.\\p{Alnum}\\p{Space}]{0,1024}$ resolves the issue. Also condensing into \p{Alnum} requires a single CharClass lookup where \p{L}\p{N} requires 2. Committing the fix to trunk for ESAPI4J 2.0

  Status: Accepted

  This is due to not accounting for spaces in the SafeString regex. Using the regex ^[.\\p{Alnum}\\p{Space}]{0,1024}$ resolves the issue. Also condensing into \p{Alnum} requires a single CharClass lookup where \p{L}\p{N} requires 2. Committing the fix to trunk for ESAPI4J 2.0

  Status: Accepted
• Dec 17, 2009

  issue 81 (Code review request for CryptoHelper.computeDerivedKeys()) commented on by chrisisbeef   -   I think this all seem ok. I am by no means a cryptographer, but the code itself seems safe and correct.

  I think this all seem ok. I am by no means a cryptographer, but the code itself seems safe and correct.
• Dec 17, 2009

  issue 82 (SafeString validation.properties error on parsing \.) reported by caughron   -   GetInputValidation takes regular expression called SafeString. Throws exception in parsing a simple regex. Regular expression in the .properties file (validation.properties) contains "\." What steps will reproduce the problem? 1. create a new dynamic web project in eclipse, create new java file with main(..) method 2. importcommons-fileupload-1.2.jar, commons-logging.jar, ESAPI-2.0-rc2.jar, log4j-1.2.15.jar in WEB-INF/lib 3. Add following code in main method try { Validator instESAPI = ESAPI.validator(); instESAPI.getValidInput("address","55 main st. pasadena ak", "SafeString", 512, false); } catch (ValidationException ve) { ve.printStackTrace(); } catch (IntrusionException ie) { ie.printStackTrace(); } catch (Exception e) { e.printStackTrace(); } 4. run as Java application What is the expected output? What do you see instead? Expected out: no error is expected What do I see instead: Following error org.owasp.esapi.errors.ValidationException: address: Invalid input. Please conform to regex ^[p{L}p{N}.]{0,1024}$ with a maximum length of 512 What version of the product are you using? On what operating system? Windows XP SP3 operating system, JDK 1.5, I tried both ESAPI-2.0-rc2.jar and ESAPI-2.0-rc4.jar, same error.

  GetInputValidation takes regular expression called SafeString. Throws exception in parsing a simple regex. Regular expression in the .properties file (validation.properties) contains "\." What steps will reproduce the problem? 1. create a new dynamic web project in eclipse, create new java file with main(..) method 2. importcommons-fileupload-1.2.jar, commons-logging.jar, ESAPI-2.0-rc2.jar, log4j-1.2.15.jar in WEB-INF/lib 3. Add following code in main method try { Validator instESAPI = ESAPI.validator(); instESAPI.getValidInput("address","55 main st. pasadena ak", "SafeString", 512, false); } catch (ValidationException ve) { ve.printStackTrace(); } catch (IntrusionException ie) { ie.printStackTrace(); } catch (Exception e) { e.printStackTrace(); } 4. run as Java application What is the expected output? What do you see instead? Expected out: no error is expected What do I see instead: Following error org.owasp.esapi.errors.ValidationException: address: Invalid input. Please conform to regex ^[p{L}p{N}.]{0,1024}$ with a maximum length of 512 What version of the product are you using? On what operating system? Windows XP SP3 operating system, JDK 1.5, I tried both ESAPI-2.0-rc2.jar and ESAPI-2.0-rc4.jar, same error.
• Dec 17, 2009

  issue 81 (Code review request for CryptoHelper.computeDerivedKeys()) reported by kevin.w.wall   -   The method of computing derived keys for encryption and authenticity (via an HMac) is critical to the use of ESAPI. Once the algorithm is released as part of the formal 2.0 ESAPI release it will be extremely difficult to for use to change it without causing it to fail to decrypt previously encrypted data. Hence this is one method that we had better get right. Please review the computeDerivedKeys() method ASAP both for correctness and for those of you with a deep understanding of cryptography, for a secure implementation. Note that cryptographer David Wagner suggested the general approach of using an HMacSHA1 the way it is being used here. I simply extended it to repeat the calculation until I had a key that was sufficiently long. (I did not want to assume that the JDK had a HMacSHA256 or HMacSHA512 available.) The code is in org.owasp.esapi.util.CryptoHelper. Lines 72-172 in the last revision I saw. NOTE: There is *nothing* there in the Branch Path. This is on the SVN trunk. However, this interface insists that 'Branch Path' must be beneath '/branches'. You will really find the code at '/trunk/src/main/java/org/owasp/esapi/util/CryptoHelper.java'.

  The method of computing derived keys for encryption and authenticity (via an HMac) is critical to the use of ESAPI. Once the algorithm is released as part of the formal 2.0 ESAPI release it will be extremely difficult to for use to change it without causing it to fail to decrypt previously encrypted data. Hence this is one method that we had better get right. Please review the computeDerivedKeys() method ASAP both for correctness and for those of you with a deep understanding of cryptography, for a secure implementation. Note that cryptographer David Wagner suggested the general approach of using an HMacSHA1 the way it is being used here. I simply extended it to repeat the calculation until I had a key that was sufficiently long. (I did not want to assume that the JDK had a HMacSHA256 or HMacSHA512 available.) The code is in org.owasp.esapi.util.CryptoHelper. Lines 72-172 in the last revision I saw. NOTE: There is *nothing* there in the Branch Path. This is on the SVN trunk. However, this interface insists that 'Branch Path' must be beneath '/branches'. You will really find the code at '/trunk/src/main/java/org/owasp/esapi/util/CryptoHelper.java'.
• Dec 17, 2009

  issue 80 (Issue with owasp-esapi-java-src-1.3-update1.zip on JDK1.3) reported by imran.jmi   -   It is more like a request not complain please suggest your views on the below faced issue. What steps will reproduce the problem? 1.Platform JDK1.3 2. encodedParamValue = ESAPI.encoder().encodeForHTML( request.getParameter( paramName ) ); 3. Classpath contains owasp-esapi-java-1.3.jar owasp-esapi-lite-java-1.3.jar commons-io-1.3.2.jar commons-fileupload-1.2.jar 4. Have put resources folder in system property What is the expected output? What do you see instead? I expect following call should return encoded value ESAPI.encoder().encodeForHTML( request.getParameter( paramName ) ) I am seeing error logs as below **** Error Thu Dec 17 11:30:12 GMT 2009 1261049412147 /atg/dynamo/server/DrpServer Serving page: /compression.dyn java.lang.NoClassDefFoundError: java/util/regex/Pattern **** Error Thu Dec 17 11:30:12 GMT 2009 1261049412147 /atg/dynamo/server/DrpServer at org.owasp.esapi.reference.DefaultSecurityConfiguration.getValidationPattern(Unknown Source) **** Error Thu Dec 17 11:30:12 GMT 2009 1261049412147 /atg/dynamo/server/DrpServer at org.owasp.esapi.reference.DefaultSecurityConfiguration.loadConfiguration(Unknown Source) **** Error Thu Dec 17 11:30:12 GMT 2009 1261049412147 /atg/dynamo/server/DrpServer at org.owasp.esapi.reference.DefaultSecurityConfiguration.<init>(Unknown Source) **** Error Thu Dec 17 11:30:12 GMT 2009 1261049412147 /atg/dynamo/server/DrpServer at org.owasp.esapi.ESAPI.securityConfiguration(Unknown Source) **** Error Thu Dec 17 11:30:12 GMT 2009 1261049412147 /atg/dynamo/server/DrpServer at org.owasp.esapi.ESAPI.logFactory(Unknown Source) **** Error Thu Dec 17 11:30:12 GMT 2009 1261049412147 /atg/dynamo/server/DrpServer at org.owasp.esapi.ESAPI.getLogger(Unknown Source) **** Error Thu Dec 17 11:30:12 GMT 2009 1261049412147 /atg/dynamo/server/DrpServer at org.owasp.esapi.reference.DefaultEncoder.<init>(Unknown Source) **** Error Thu Dec 17 11:30:12 GMT 2009 1261049412147 /atg/dynamo/server/DrpServer at org.owasp.esapi.ESAPI.encoder(Unknown Source) What version of the product are you using? On what operating system? Using owasp-esapi-java-src-1.3-update1.zip. Please provide any additional information below.

  It is more like a request not complain please suggest your views on the below faced issue. What steps will reproduce the problem? 1.Platform JDK1.3 2. encodedParamValue = ESAPI.encoder().encodeForHTML( request.getParameter( paramName ) ); 3. Classpath contains owasp-esapi-java-1.3.jar owasp-esapi-lite-java-1.3.jar commons-io-1.3.2.jar commons-fileupload-1.2.jar 4. Have put resources folder in system property What is the expected output? What do you see instead? I expect following call should return encoded value ESAPI.encoder().encodeForHTML( request.getParameter( paramName ) ) I am seeing error logs as below **** Error Thu Dec 17 11:30:12 GMT 2009 1261049412147 /atg/dynamo/server/DrpServer Serving page: /compression.dyn java.lang.NoClassDefFoundError: java/util/regex/Pattern **** Error Thu Dec 17 11:30:12 GMT 2009 1261049412147 /atg/dynamo/server/DrpServer at org.owasp.esapi.reference.DefaultSecurityConfiguration.getValidationPattern(Unknown Source) **** Error Thu Dec 17 11:30:12 GMT 2009 1261049412147 /atg/dynamo/server/DrpServer at org.owasp.esapi.reference.DefaultSecurityConfiguration.loadConfiguration(Unknown Source) **** Error Thu Dec 17 11:30:12 GMT 2009 1261049412147 /atg/dynamo/server/DrpServer at org.owasp.esapi.reference.DefaultSecurityConfiguration.<init>(Unknown Source) **** Error Thu Dec 17 11:30:12 GMT 2009 1261049412147 /atg/dynamo/server/DrpServer at org.owasp.esapi.ESAPI.securityConfiguration(Unknown Source) **** Error Thu Dec 17 11:30:12 GMT 2009 1261049412147 /atg/dynamo/server/DrpServer at org.owasp.esapi.ESAPI.logFactory(Unknown Source) **** Error Thu Dec 17 11:30:12 GMT 2009 1261049412147 /atg/dynamo/server/DrpServer at org.owasp.esapi.ESAPI.getLogger(Unknown Source) **** Error Thu Dec 17 11:30:12 GMT 2009 1261049412147 /atg/dynamo/server/DrpServer at org.owasp.esapi.reference.DefaultEncoder.<init>(Unknown Source) **** Error Thu Dec 17 11:30:12 GMT 2009 1261049412147 /atg/dynamo/server/DrpServer at org.owasp.esapi.ESAPI.encoder(Unknown Source) What version of the product are you using? On what operating system? Using owasp-esapi-java-src-1.3-update1.zip. Please provide any additional information below.
• Dec 15, 2009

  issue 79 (ESAPI Logging : Need to clarify POST vs GET params better fo...) reported by manico.james   -   A post can contain both get params in the url, and post params in the post payload. We need to differentiate these better in the various ESAPI Loggers.

  A post can contain both get params in the url, and post params in the post payload. We need to differentiate these better in the various ESAPI Loggers.
• Dec 13, 2009

  r913 (CSSCodec: switch back to back slash self for printable asci...) committed by schal...@darkmist.net   -   CSSCodec: switch back to back slash self for printable ascii EncoderTest: fix tests that got messed up by back ports and such normalize still fails but this is known (issue 74) double encoding fails and needs checking

  CSSCodec: switch back to back slash self for printable ascii EncoderTest: fix tests that got messed up by back ports and such normalize still fails but this is known (issue 74) double encoding fails and needs checking
• Dec 13, 2009

  r912 (HashTrieTest#testValues() was throwing a ClassCastException ...) committed by schal...@darkmist.net   -   HashTrieTest#testValues() was throwing a ClassCastException in the sort. It turns out Boolean is not Comparable in 1.4 but is in 1.5. This has been changed to Integer in the 1.4 branch.

  HashTrieTest#testValues() was throwing a ClassCastException in the sort. It turns out Boolean is not Comparable in 1.4 but is in 1.5. This has been changed to Integer in the 1.4 branch.
• Dec 13, 2009

  issue 46 (context path validation error) commented on by schal...@darkmist.net   -   I haven't looked at the code to which you refer, but according to the spec the context path returned from getContextPath should start with a '/' but not end with one. The only exception to this is if the context is the default context in which it is just a empty string.

  I haven't looked at the code to which you refer, but according to the spec the context path returned from getContextPath should start with a '/' but not end with one. The only exception to this is if the context is the default context in which it is just a empty string.
• Dec 13, 2009

  issue 15 (ClassCastException org.owasp.esapi.filters.SafeRequest canno...) Status changed by schal...@darkmist.net   -   Should be fixed in revision 911. These two classes now extends HttpServlet{Request,Response}Wrapper which should hopefully make containers more happy. Be aware that these classes have been removed/renamed in 2.0.

  Status: Fixed

  Should be fixed in revision 911. These two classes now extends HttpServlet{Request,Response}Wrapper which should hopefully make containers more happy. Be aware that these classes have been removed/renamed in 2.0.

  Status: Fixed
• Dec 13, 2009

  r911 (Fix issue 15 by extending HttpServlet{Request,Response}Wrapp...) committed by schal...@darkmist.net   -   Fix issue 15 by extending HttpServlet{Request,Response}Wrapper instead of just implementing HttpServlet{Request,Response}. As this change only changes this classes super class (no longer java.lang.Object) and the interfaces are the same this shouldn't cause existing code issues. This does fix the problem where containers expect to be able to unwrap their original request in the wrapped one.

  Fix issue 15 by extending HttpServlet{Request,Response}Wrapper instead of just implementing HttpServlet{Request,Response}. As this change only changes this classes super class (no longer java.lang.Object) and the interfaces are the same this shouldn't cause existing code issues. This does fix the problem where containers expect to be able to unwrap their original request in the wrapped one.
• Dec 13, 2009

  issue 78 (1.4 JavaScript codec throws exception encoding 0x100) Status changed by schal...@darkmist.net   -   fixed in revision 910

  Status: Fixed

  fixed in revision 910

  Status: Fixed
• Dec 13, 2009

  issue 77 (CSSCodec in 1.4 encodes hex digits invalidily) Status changed by schal...@darkmist.net   -   fixed in revision 910

  Status: Fixed

  fixed in revision 910

  Status: Fixed
• Dec 13, 2009

  r910 (CSSCodec: fix issues with backslash self for hex digits (is...) committed by schal...@darkmist.net   -   CSSCodec: fix issues with backslash self for hex digits ( issue 77 ) split out tests from CodecTest add tests to verify lack of regression for issue 77 change to not encode alphanumerics HTMLEntityCodec: fix theta/thetasym issues with decoding by backporting 2.0 fix ( issue 45 ) JavaScriptCodec: fix corner case which would throw a IndexOutOfBoundsException ( issue 78 ) changed massive if (a) ret, if(b) ret, to switch statement PercentCodec: back port percent codec fixes for issue 75 CodecTest: back ported to 1.4 modify some tests to work with 1.4 as 1.4 encodes somethings differently I think that's all...

  CSSCodec: fix issues with backslash self for hex digits ( issue 77 ) split out tests from CodecTest add tests to verify lack of regression for issue 77 change to not encode alphanumerics HTMLEntityCodec: fix theta/thetasym issues with decoding by backporting 2.0 fix ( issue 45 ) JavaScriptCodec: fix corner case which would throw a IndexOutOfBoundsException ( issue 78 ) changed massive if (a) ret, if(b) ret, to switch statement PercentCodec: back port percent codec fixes for issue 75 CodecTest: back ported to 1.4 modify some tests to work with 1.4 as 1.4 encodes somethings differently I think that's all...
• Dec 13, 2009

  issue 78 (1.4 JavaScript codec throws exception encoding 0x100) reported by schal...@darkmist.net   -   What steps will reproduce the problem? 1. checkout 1.4 trunk pre 910 2. encoded 0x100 with JavScriptCodec What is the expected output? What do you see instead? "\u0100", IndexOutOfRangeException(-1) Please use labels and text to provide additional information. If statement is checking for <= 256 instead of < 256.

  What steps will reproduce the problem? 1. checkout 1.4 trunk pre 910 2. encoded 0x100 with JavScriptCodec What is the expected output? What do you see instead? "\u0100", IndexOutOfRangeException(-1) Please use labels and text to provide additional information. If statement is checking for <= 256 instead of < 256.
• Dec 13, 2009

  issue 77 (CSSCodec in 1.4 encodes hex digits invalidily) reported by schal...@darkmist.net   -   What steps will reproduce the problem? 1. checkout 1.4 previous to revision 910 2. encode 'a' via the CSSCodec What is the expected output? What do you see instead? 'a' should either be left unencoded or be encoded '\61 '. Please use labels and text to provide additional information. Hexadecimal digits, as well as \r\n\f, are specifically excluded from the slash self escape syntax in the CSS 2.1 spec (section 4.1.3). The slash self syntax for hexadecimal digits conflicts with hexadecimal character code escapes. As such '\a' (assuming the next char is not hex) will be interpreted as a \n which is not the expected behavior

  What steps will reproduce the problem? 1. checkout 1.4 previous to revision 910 2. encode 'a' via the CSSCodec What is the expected output? What do you see instead? 'a' should either be left unencoded or be encoded '\61 '. Please use labels and text to provide additional information. Hexadecimal digits, as well as \r\n\f, are specifically excluded from the slash self escape syntax in the CSS 2.1 spec (section 4.1.3). The slash self syntax for hexadecimal digits conflicts with hexadecimal character code escapes. As such '\a' (assuming the next char is not hex) will be interpreted as a \n which is not the expected behavior
• Dec 11, 2009

  issue 76 (Document base Swingset_with_tomcat_05b2/apache-tomcat-6.0.18...) reported by cleverson.sacramento   -   What steps will reproduce the problem? 1. Download Swingset from http://owasp-esapi-java-swingset.googlecode.com/files/Swingset_with_tomcat_05b2.zip 2. Following the tutorial described on http://www.owasp.org/index.php/ESAPI_Swingset, run Tomcat 6.0.18_start.bat What is the expected output? What do you see instead? Expected: Tomcat 6.0.18_start.bat I see: SEVERE: Error starting static Resources java.lang.IllegalArgumentException: Document base [...]/Swingset_with_tomcat_05b2/apache-tomcat-6.0.18/webapps/ESAPI_Swingset does not exist or is not a readable directory What version of the product are you using? On what operating system? Swingset_with_tomcat_05b2 on Ubuntu 8.04 (I translated the bat script to bash script and fix an absolute reference to C:\ in server.xml config file) Please provide any additional information below. The war file ESAPI_Swingset_05b2.war is absent on Swingset_with_tomcat_05b2/apache-tomcat-6.0.18/webapps/. I fixed it downloading the war file from http://owasp-esapi-java-swingset.googlecode.com/files/ESAPI_Swingset_05b2.war and put it on webapp folder. I attached the fixed bundle in this ticket.

  What steps will reproduce the problem? 1. Download Swingset from http://owasp-esapi-java-swingset.googlecode.com/files/Swingset_with_tomcat_05b2.zip 2. Following the tutorial described on http://www.owasp.org/index.php/ESAPI_Swingset, run Tomcat 6.0.18_start.bat What is the expected output? What do you see instead? Expected: Tomcat 6.0.18_start.bat I see: SEVERE: Error starting static Resources java.lang.IllegalArgumentException: Document base [...]/Swingset_with_tomcat_05b2/apache-tomcat-6.0.18/webapps/ESAPI_Swingset does not exist or is not a readable directory What version of the product are you using? On what operating system? Swingset_with_tomcat_05b2 on Ubuntu 8.04 (I translated the bat script to bash script and fix an absolute reference to C:\ in server.xml config file) Please provide any additional information below. The war file ESAPI_Swingset_05b2.war is absent on Swingset_with_tomcat_05b2/apache-tomcat-6.0.18/webapps/. I fixed it downloading the war file from http://owasp-esapi-java-swingset.googlecode.com/files/ESAPI_Swingset_05b2.war and put it on webapp folder. I attached the fixed bundle in this ticket.
• Dec 09, 2009

  issue 75 (Most codecs fail to encode characters above 0xFF) Status changed by schal...@darkmist.net   -   Fixed in revision 909

  Status: Fixed

  Fixed in revision 909

  Status: Fixed
• Dec 09, 2009

  r909 (Fix percent encoding issues with non-ascii characters. ) committed by schal...@darkmist.net   -   Fix percent encoding issues with non-ascii characters.

  Fix percent encoding issues with non-ascii characters.
• Dec 09, 2009

  r908 (Fix getHexForNonAlphanumeric(char), toOctal(char) and toHex(...) committed by schal...@darkmist.net   -   Fix getHexForNonAlphanumeric(char), toOctal(char) and toHex(char) in Codec to properly handle character values greater than 0xFF. Fix CSS tests for 0x100 in CodecTest. Note, the percent 0x100 tests still fail but that is a bit more complex to fix. Next on the list.

  Fix getHexForNonAlphanumeric(char), toOctal(char) and toHex(char) in Codec to properly handle character values greater than 0xFF. Fix CSS tests for 0x100 in CodecTest. Note, the percent 0x100 tests still fail but that is a bit more complex to fix. Next on the list.
• Dec 08, 2009

  r907 (More cleanup for Issue 66) committed by chrisisbeef   -   More cleanup for Issue 66

  More cleanup for Issue 66
• Dec 08, 2009

  r906 (Fixed broken test) committed by chrisisbeef   -   Fixed broken test

  Fixed broken test
• Dec 08, 2009

  issue 66 (Get rid of System.out's sprinkled in code) changed by chrisisbeef   -   This issue was closed by revision r905.

  Status: Fixed

  This issue was closed by revision r905.

  Status: Fixed
• Dec 08, 2009

  r905 (Fixes Issue 66 Removed System.out calls in code except wher...) committed by chrisisbeef   -   Fixes Issue 66 Removed System.out calls in code except where used in a Java process that can be launched from the command line.

  Fixes Issue 66 Removed System.out calls in code except where used in a Java process that can be launched from the command line.
• Dec 08, 2009

  issue 75 (Most codecs fail to encode characters above 0xFF) reported by schal...@darkmist.net   -   What steps will reproduce the problem? 1. encode a character above 0xFF What is the expected output? What do you see instead? The character should be encoded since it is not on the white list. Instead the character is not encoded at all. Please use labels and text to provide additional information. The following codecs are affected: CSSCodec HTMLEntityCodec JavaScriptCodec MySQLCodec (in standard mode as ANSI mode only escapes ') PercentCodec UnixCodec VBScriptCodec WindowsCodec This is caused by getHexForNonAlphanumeric returning null for any character above 0xFF which is identical to it's behavior for characters that should not be encoded.

  What steps will reproduce the problem? 1. encode a character above 0xFF What is the expected output? What do you see instead? The character should be encoded since it is not on the white list. Instead the character is not encoded at all. Please use labels and text to provide additional information. The following codecs are affected: CSSCodec HTMLEntityCodec JavaScriptCodec MySQLCodec (in standard mode as ANSI mode only escapes ') PercentCodec UnixCodec VBScriptCodec WindowsCodec This is caused by getHexForNonAlphanumeric returning null for any character above 0xFF which is identical to it's behavior for characters that should not be encoded.
• Dec 08, 2009

  r904 (Add minimal tests to check encoding of characters above 0xFF...) committed by schal...@darkmist.net   -   Add minimal tests to check encoding of characters above 0xFF. Note that these will cause unit test failures until they are fixed.

  Add minimal tests to check encoding of characters above 0xFF. Note that these will cause unit test failures until they are fixed.
• Dec 08, 2009

  issue 61 (java.lang.ExceptionInInitializerError in 2.0 version) commented on by chrisisbeef   -   Originally we included the "default" ESAPI.properties in the jar, but we removed it from the jar and instead included it in the distribution ZIP. @lakers8 (love the twitterification of the internet) - here are some links: http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/reference/DefaultSecurityConfiguration.html Also, the latest RC can be downloaded which includes documentation and installation instructions: http://code.google.com/p/owasp-esapi-java/downloads/list

  Originally we included the "default" ESAPI.properties in the jar, but we removed it from the jar and instead included it in the distribution ZIP. @lakers8 (love the twitterification of the internet) - here are some links: http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/reference/DefaultSecurityConfiguration.html Also, the latest RC can be downloaded which includes documentation and installation instructions: http://code.google.com/p/owasp-esapi-java/downloads/list
• Dec 08, 2009

  issue 61 (java.lang.ExceptionInInitializerError in 2.0 version) commented on by lakers8   -   Thanks for all the info guys. I agree with @planetlevel that it'd be convenient if ESAPI.properties can be bundled with jar. With that said, how/where do I include this properties file to run this successfully? I'd appreciate it if you can explain the steps. Also, what's the target date for final 2.0 release? Thank you again for all your help.

  Thanks for all the info guys. I agree with @planetlevel that it'd be convenient if ESAPI.properties can be bundled with jar. With that said, how/where do I include this properties file to run this successfully? I'd appreciate it if you can explain the steps. Also, what's the target date for final 2.0 release? Thank you again for all your help.
• Dec 08, 2009

  issue 74 (DefaultEncoder#normalize is broken) commented on by chrisisbeef   -   This needs to be fixed for 2.0-final While we officially support 1.5, since 1.5 has reached EOL it is pretty important that the ESAPI work with 1.6+

  This needs to be fixed for 2.0-final While we officially support 1.5, since 1.5 has reached EOL it is pretty important that the ESAPI work with 1.6+
• Dec 08, 2009

  issue 74 (DefaultEncoder#normalize is broken) Labels changed by chrisisbeef   -  

  Labels: Priority-High Milestone-Release2.0 OpSys-All Usability Component-Logic −Priority-Medium

  Labels: Priority-High Milestone-Release2.0 OpSys-All Usability Component-Logic −Priority-Medium
• Dec 08, 2009

  issue 61 (java.lang.ExceptionInInitializerError in 2.0 version) Labels changed by chrisisbeef   -   I think allowing the ESAPI to be used in an *un-initialized* state creates a couple of problems, namely a significant amount of "defensive-code" spread throughout the codebase to account for the ability of the ESAPI to be in an uninitialized state. I can definately look into the error messaging for this case. Changing the logger to be initialized in a static block with a try...catch... should allow us to alter the error messaging such that it will be clearer what the problem is. I am not sure if this will make it into the 2.0-final release at this point. This seems like a pretty low-priority issue compared to some of the other last minute things that need to be dealt with. This is also something that can be fixed as part of a minor or patch release. This should be scheduled for 2.0.2 or a later patch revision

  Labels: Priority-Low OpSys-All Component-Logic Usability −Priority-Medium

  I think allowing the ESAPI to be used in an *un-initialized* state creates a couple of problems, namely a significant amount of "defensive-code" spread throughout the codebase to account for the ability of the ESAPI to be in an uninitialized state. I can definately look into the error messaging for this case. Changing the logger to be initialized in a static block with a try...catch... should allow us to alter the error messaging such that it will be clearer what the problem is. I am not sure if this will make it into the 2.0-final release at this point. This seems like a pretty low-priority issue compared to some of the other last minute things that need to be dealt with. This is also something that can be fixed as part of a minor or patch release. This should be scheduled for 2.0.2 or a later patch revision

  Labels: Priority-Low OpSys-All Component-Logic Usability −Priority-Medium
• Dec 08, 2009

  r903 (Big nasty patch to back port the XMLEntityCodec to 1.4. This...) committed by schal...@darkmist.net   -   Big nasty patch to back port the XMLEntityCodec to 1.4. This includes most of the functionality needed for the HTMLCodec fix which is next. This includes codec.HashTrieTest, util.NullSafe and util.CollectionsUtil. Two new classes have been added: codec.AbstractCodec: This is a base abstract codec.Codec implementation to ease porting. In 1.4 Codec is a interface and in 2.0 it is a abstract class. Ports back to 1.4 ca use AbstractCodec as their base instead. util.PrimWrap: This is a simple class to wrap primitives in their java.lang classes. This is here to help back porting of auto boxing code from the 2.0 branch. By using this instead of new Character(), etc we can easily implement our own fly weight caching of these objects as 1.5 does in it's auto boxing if and when the overhead incurred in creating new objects each time becomes a issue.

  Big nasty patch to back port the XMLEntityCodec to 1.4. This includes most of the functionality needed for the HTMLCodec fix which is next. This includes codec.HashTrieTest, util.NullSafe and util.CollectionsUtil. Two new classes have been added: codec.AbstractCodec: This is a base abstract codec.Codec implementation to ease porting. In 1.4 Codec is a interface and in 2.0 it is a abstract class. Ports back to 1.4 ca use AbstractCodec as their base instead. util.PrimWrap: This is a simple class to wrap primitives in their java.lang classes. This is here to help back porting of auto boxing code from the 2.0 branch. By using this instead of new Character(), etc we can easily implement our own fly weight caching of these objects as 1.5 does in it's auto boxing if and when the overhead incurred in creating new objects each time becomes a issue.
• Dec 08, 2009

  issue 74 (DefaultEncoder#normalize is broken) reported by schal...@darkmist.net   -   What steps will reproduce the problem? 1. use normalize with accented characters What is the expected output? What do you see instead? Split out base and accent characters. Accented characters are probably removed. Please use labels and text to provide additional information. This is an issue currently in trunk and in the 1.4 branch (revision 902). The 1.4 branch used (until 902) sun.text.Normalizer which is proprietary. This does not work in current JDKs (1.6 tried). 1.6 added a java.text.Normalizer but this is not available in 1.4 or 1.5. To properly fix this I think we're going to have to implement our own until we only support 1.6 and latter which isn't going to happen soon;)

  What steps will reproduce the problem? 1. use normalize with accented characters What is the expected output? What do you see instead? Split out base and accent characters. Accented characters are probably removed. Please use labels and text to provide additional information. This is an issue currently in trunk and in the 1.4 branch (revision 902). The 1.4 branch used (until 902) sun.text.Normalizer which is proprietary. This does not work in current JDKs (1.6 tried). 1.6 added a java.text.Normalizer but this is not available in 1.4 or 1.5. To properly fix this I think we're going to have to implement our own until we only support 1.6 and latter which isn't going to happen soon;)
• Dec 08, 2009

  r902 (Remove use of sun proprietary normalize method. This breaks ...) committed by schal...@darkmist.net   -   Remove use of sun proprietary normalize method. This breaks this method's functionality which I do not like. However, this is what has been done in the 2.0 branch. There is code commented out in the 2.0 branch to use the new java.text.Normalize however that is only available in 1.6. To make matters worse, the interface to the sun proprietary version has changed and, as is, this will not compile with latter jdks (at least 1.6). I am adding a issue to document and remind us about this.

  Remove use of sun proprietary normalize method. This breaks this method's functionality which I do not like. However, this is what has been done in the 2.0 branch. There is code commented out in the 2.0 branch to use the new java.text.Normalize however that is only available in 1.6. To make matters worse, the interface to the sun proprietary version has changed and, as is, this will not compile with latter jdks (at least 1.6). I am adding a issue to document and remind us about this.