StripFilter does not handle hash collisions

• Type: Bug
• Status: Closed
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 6.0.12 EE, 6.1.0 CE RC1, 6.1.0 CE GA1, 6.1.10 EE GA1, 6.2.0 CE M2
• Fix Version/s: 6.1.10 EE GA1, 6.1.20 EE GA2, 6.0.X EE, --Sprint 11/12, 6.2.0 CE M2
• Component/s: Operations, Operations > Caching > Replication Hook
• Labels:
  • QA-C
• Branch Version/s:
  6.1.x, 6.0.x
• Backported to Branch:
  Committed
• Caused by: Feature/improvement was not complete
• Where was the bug?:
  Java
• Added to Fix Pack:
  Added
• Similar Issues: Show 4 results ; ;

  LPS-5300	StripFilter doesn't handle optional attributes in <script> elements.
  LPS-24837	Resolve FinderCache cache key hash collision
  LPS-21001	StripFilter is not properly process <script> tags
  LPS-24287	CMISRepositoryUtil does not handle CmisPermissionDeniedException

The StripFilter maintains a cache for inlined javascript code and inlined css rules. The idea is to minify the code only once. The key of the cache ist calculated by simply using the hashCode method on the input string. This usage of the hashCode function is wrong, because no collision detection is possible.

Two totally different string values may have the same hashCode. This will result in a situation where the first value is replaced by the second one. If later the minified version of the first string is to be taken from the cache, the second value is retrieved.

There are even some algorithms to generate a string that for a given hash code value (see for example http://java-bytes.blogspot.com/2009/10/hashcode-of-string-in-java.html).

This bug is a very nasty one, because almost always things are running good. But in very rare situations the cache returns the wrong value. The following test code show an example:

		assertEquals("HashCode values must not be used as keys".hashCode(), "I<EZH@$YJVK[".hashCode());

As workaround you can disable the minifying of inlined javascript and css code by setting the property minifier.inline.content.cache.size to 0.