-
Notifications
You must be signed in to change notification settings - Fork 364
/
esapi4java-core-2.2.1.1-release-notes.txt
237 lines (180 loc) · 14.3 KB
/
esapi4java-core-2.2.1.1-release-notes.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
Release notes for ESAPI 2.2.1.1
Release date: 2020-July-26
Project leaders:
-Kevin W. Wall <[email protected]>
-Matt Seil <[email protected]>
Previous release: ESAPI 2.2.1.0, 2020-July-12
Executive Summary: Important Things to Note for this Release
------------------------------------------------------------
This is a patch release to address GitHub issue #560. See that GitHub issue and
Also special props to Bill Sempf for stepping up and volunteering to prepare the initial cut of these release notes. Had he not done so, this release either would not have release notes or it would have been delayed another 6 months while I procrastinated further with various distractions. (Squirrel!)
=================================================================================================================
Basic ESAPI facts
-----------------
ESAPI 2.2.1.0 release:
211 Java source files
4309 JUnit tests in 134 Java source files
ESAPI 2.2.1.1 release:
211 Java source files
4312 JUnit tests in 134 Java source files
39 GitHub Issues closed in this release
Issue # GitHub Issue Title
----------------------------------------------------------------------------------------------
560 - Could not initialize class org.owasp.esapi.logging.java.JavaLogFactory (ESAPI 2.2.1.0)
561 - Update ESAPI-release-steps.odt to note how to do 'Release' on GitHub
564 - Create release notes for 2.2.1.1 patch release
-----------------------------------------------------------------------------
Changes Requiring Special Attention
-----------------------------------------------------------------------------
As of ESAPI 2.2.1.0 (the previous release), the new default ESAPI logger is JUL (java.util.logging packages) and we have deprecated the use of Log4J 1.x because we now support SLF4J and Log4J 1.x is way past its end-of-life. We did not want to make SLF4J the default logger (at least not yet) as we did not want to have the default ESAPI use require additional dependencies. However, SLF4J is likely to be the future choice, at least once we start on ESAPI 3.0. A special shout-out to Jeremiah Stacey for making this possible by re-factoring much of the ESAPI logger code. Note, the straw that broke the proverbial camel's back was the announcement of CVE-2019-17571 (rated Critical), for which there is no fix available and likely will never be.
However, if you try to juse the new ESAPI 2.2.1.0 logging you will notice that you need to change ESAPI.Logger and also possibly provide some other properties as well to get the logging behavior that you desire.
To use ESAPI logging in ESAPI 2.2.1.0 (and later), you will need to set the ESAPI.Logger property to
org.owasp.esapi.logging.java.JavaLogFactory - To use the new default, java.util.logging (JUL)
org.owasp.esapi.logging.log4j.Log4JLogFactory - To use the end-of-life Log4J 1.x logger
org.owasp.esapi.logging.slf4j.Slf4JLogFactory - To use the new (to release 2.2.0.0) SLF4J logger
In addition, if you wish to use JUL for logging, you *MUST* supply an "esapi-java-logging.properties" file in your classpath. This file is included in the 'esapi-2.2.1.1-configuration.jar' file provided under the 'Assets' section of the GitHub Release at
https://github.com/ESAPI/esapi-java-legacy/releases/esapi-2.2.1.1
Unfortunately, there was a logic error in the static initializer of JavaLogFactory (now fixed in this release) that caused a NullPointerException to be thrown so that the message about the missing "esapi-java-logging.properties" file was never seen.
If you are using JavaLogFactory, you will also want to ensure that you have the following ESAPI logging properties set:
# Set the application name if these logs are combined with other applications
Logger.ApplicationName=ExampleApplication
# If you use an HTML log viewer that does not properly HTML escape log data, you can set LogEncodingRequired to true
Logger.LogEncodingRequired=false
# Determines whether ESAPI should log the application name. This might be clutter in some single-server/single-app environments.
Logger.LogApplicationName=true
# Determines whether ESAPI should log the server IP and port. This might be clutter in some single-server environments.
Logger.LogServerIP=true
# LogFileName, the name of the logging file. Provide a full directory path (e.g., C:\\ESAPI\\ESAPI_logging_file) if you
# want to place it in a specific directory.
Logger.LogFileName=ESAPI_logging_file
# MaxLogFileSize, the max size (in bytes) of a single log file before it cuts over to a new one (default is 10,000,000)
Logger.MaxLogFileSize=10000000
# Determines whether ESAPI should log the user info.
Logger.UserInfo=true
# Determines whether ESAPI should log the session id and client IP.
Logger.ClientInfo=true
See GitHub issue #560 for additional details.
Related to that aforemented Log4J 1.x CVE and how it affects ESAPI, be sure to read
https://github.com/ESAPI/esapi-java-legacy/blob/develop/documentation/ESAPI-security-bulletin2.pdf
which describes CVE-2019-17571, a deserialization vulnerability in Log4J 1.2.17. ESAPI is *NOT* affected by this (even if you chose to use Log4J 1 as you default ESAPI logger). This security bulletin describes why this CVE is not exploitable as used by ESAPI.
Finally, while ESAPI still supports JDK 7 (even though that too is way past end-of-life), the next ESAPI release will move to JDK 8 as the minimal baseline. (We already use Java 8 for development but still to Java 7 source and runtime compatibility.)
-----------------------------------------------------------------------------
Known Issues / Problems
-----------------------------------------------------------------------------
If you use Java 7 (the minimal Java baseline supported by ESAPI) and try to run 'mvn test' there is one test that fails. This test passes with Java 8. The failing test is:
[ERROR] Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.203 s
<<< FAILURE! - in org.owasp.esapi.crypto.SecurityProviderLoaderTest
[ERROR] org.owasp.esapi.crypto.SecurityProviderLoaderTest.testWithBouncyCastle
Time elapsed: 0.116 s <<< FAILURE!
java.lang.AssertionError: Encryption w/ Bouncy Castle failed with
EncryptionException for preferred cipher transformation; exception was:
org.owasp.esapi.errors.EncryptionException: Encryption failure (unavailable
cipher requested)
at
org.owasp.esapi.crypto.SecurityProviderLoaderTest.testWithBouncyCastle(Security
ProviderLoaderTest.java:133)
I will spare you all the details and tell you that this has to do with Java 7 not being able to correctly parse the signed Bouncy Castle JCE provider jar. More details are available at:
https://www.bouncycastle.org/latest_releases.html
and
https://github.com/bcgit/bc-java/issues/477
I am sure that there are ways of making Bouncy Castle work with Java 7, but since ESAPI does not rely on Bouncy Castle (it can use any compliant JCE provider), this should not be a problem. (It works fine with the default SunJCE provider.) If it is important to get the BC provider working with the ESAPI Encryptor and Java 7, then open a GitHub issue and we will take a deeper look at it and see if we can suggest something.
Another problem is if you run 'mvn test' from the 'cmd' prompt (and possibly PowerShell as well), you will get intermittent failures (generally between 10-25% of the time) at arbitrary spots. If you run it again without any changes it will work fine without any failures. We have discovered that it doesn't seem to fail if you run the tests from an IDE like Eclipse or if you redirect both stdout and stderr to a file; e.g.,
C:\code\esapi-java-legacy> mvn test >testoutput.txt 2>&1
We do not know the reason for these failures, but only that we have observed them on Windows 10. If you see this error, please do NOT report it as a GitHub issue unless you know a fix for it.
-----------------------------------------------------------------------------
Other changes in this release, some of which not tracked via GitHub issues
-----------------------------------------------------------------------------
* Updates to README.md fileg
* Minor Javadoc fixes to org.owasp.esapi.Encoder
* Fixes / cleanup to 2.2.1.0 release notes (documentation/esapi4java-core-2.2.1.0-release-notes.txt)
-----------------------------------------------------------------------------
Developer Activity Report (Changes between release 2.2.1.0 and 2.2.1.1, i.e., between 2020-07-12 and 2020-07-26)
Generated manually (this time) -- all errors are the fault of kwwall and his inability to do simple arithmetic.
Developer Total Total Number # Merged
(GitHub ID) commits of Files Changed PRs
========================================================
jeremiahjstacey 5 5 1
kwwall 67 64 8
========================================================
Total: 21
-----------------------------------------------------------------------------
2 Closed PRs merged since 2.2.1.0 release (those rejected not listed)
======================================================================
PR# GitHub ID Description
----------------------------------------------------------------------
559 -- synk-bot -- Upgrade com.github.spotbugs:spotbugs-annotations from 4.0.4 to 4.0.5
562 -- jeremiahjstacey -- Issue #560 JUL fixes
CHANGELOG: Create your own. May I suggest:
git log --since=2020-07-13 --reverse --pretty=medium
which will show all the commits since just after the last (2.2.1.0) release.
-----------------------------------------------------------------------------
Direct and Transitive Runtime and Test Dependencies:
$ mvn dependency:tree
[INFO] Scanning for projects...
[INFO]
[INFO] -----------------------< org.owasp.esapi:esapi >------------------------
[INFO] Building ESAPI 2.2.1.1
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:3.1.2:tree (default-cli) @ esapi ---
[INFO] org.owasp.esapi:esapi:jar:2.2.1.1
[INFO] +- javax.servlet:javax.servlet-api:jar:3.0.1:provided
[INFO] +- javax.servlet.jsp:javax.servlet.jsp-api:jar:2.3.3:provided
[INFO] +- com.io7m.xom:xom:jar:1.2.10:compile
[INFO] +- commons-beanutils:commons-beanutils:jar:1.9.4:compile
[INFO] | +- commons-logging:commons-logging:jar:1.2:compile
[INFO] | \- commons-collections:commons-collections:jar:3.2.2:compile
[INFO] +- commons-configuration:commons-configuration:jar:1.10:compile
[INFO] +- commons-lang:commons-lang:jar:2.6:compile
[INFO] +- commons-fileupload:commons-fileupload:jar:1.3.3:compile
[INFO] +- log4j:log4j:jar:1.2.17:compile
[INFO] +- org.apache.commons:commons-collections4:jar:4.2:compile
[INFO] +- org.apache-extras.beanshell:bsh:jar:2.0b6:compile
[INFO] +- org.owasp.antisamy:antisamy:jar:1.5.10:compile
[INFO] | +- net.sourceforge.nekohtml:nekohtml:jar:1.9.22:compile
[INFO] | +- org.apache.httpcomponents:httpclient:jar:4.5.12:compile
[INFO] | | \- org.apache.httpcomponents:httpcore:jar:4.4.13:compile
[INFO] | \- commons-codec:commons-codec:jar:1.14:compile
[INFO] +- org.slf4j:slf4j-api:jar:1.7.30:compile
[INFO] +- commons-io:commons-io:jar:2.6:compile
[INFO] +- org.apache.xmlgraphics:batik-css:jar:1.13:compile
[INFO] | +- org.apache.xmlgraphics:batik-shared-resources:jar:1.13:compile
[INFO] | +- org.apache.xmlgraphics:batik-util:jar:1.13:compile
[INFO] | | +- org.apache.xmlgraphics:batik-constants:jar:1.13:compile
[INFO] | | \- org.apache.xmlgraphics:batik-i18n:jar:1.13:compile
[INFO] | +- org.apache.xmlgraphics:xmlgraphics-commons:jar:2.4:compile
[INFO] | \- xml-apis:xml-apis-ext:jar:1.3.04:compile
[INFO] +- xalan:xalan:jar:2.7.2:compile
[INFO] | \- xalan:serializer:jar:2.7.2:compile
[INFO] +- xerces:xercesImpl:jar:2.12.0:compile
[INFO] +- xml-apis:xml-apis:jar:1.4.01:compile
[INFO] +- com.github.spotbugs:spotbugs-annotations:jar:4.0.5:compile (optional)
[INFO] | \- com.google.code.findbugs:jsr305:jar:3.0.2:compile (optional)
[INFO] +- net.jcip:jcip-annotations:jar:1.0:compile (optional)
[INFO] +- junit:junit:jar:4.13:test
[INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] +- org.bouncycastle:bcprov-jdk15on:jar:1.65.01:test
[INFO] +- org.powermock:powermock-api-mockito2:jar:2.0.7:test
[INFO] | \- org.powermock:powermock-api-support:jar:2.0.7:test
[INFO] | \- org.powermock:powermock-core:jar:2.0.7:test
[INFO] +- org.javassist:javassist:jar:3.25.0-GA:test
[INFO] +- org.mockito:mockito-core:jar:2.28.2:test
[INFO] | +- net.bytebuddy:byte-buddy:jar:1.9.10:test
[INFO] | +- net.bytebuddy:byte-buddy-agent:jar:1.9.10:test
[INFO] | \- org.objenesis:objenesis:jar:2.6:test
[INFO] +- org.powermock:powermock-module-junit4:jar:2.0.7:test
[INFO] | \- org.powermock:powermock-module-junit4-common:jar:2.0.7:test
[INFO] +- org.powermock:powermock-reflect:jar:2.0.7:test
[INFO] +- org.openjdk.jmh:jmh-core:jar:1.23:test
[INFO] | +- net.sf.jopt-simple:jopt-simple:jar:4.6:test
[INFO] | \- org.apache.commons:commons-math3:jar:3.2:test
[INFO] \- org.openjdk.jmh:jmh-generator-annprocess:jar:1.23:test
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
-----------------------------------------------------------------------------
Acknowledgments:
elangoravi for bringing GitHub issue #560 to our attention. This is one where we thought the workaround instructions was harder than just trying to fix it and thus we were encouraged to release a patch.
A special thanks to the ESAPI community from the ESAPI project co-leaders:
Kevin W. Wall (kwwall) <== The irresponsible party for these release notes!
Matt Seil (xeno6696)