2.3.19

发布日期：2012-02-29

不要忘了安全相关的修复，它可能会影响到你的应用程序！

FTL部分的修改

注意：在 2.3.17 版引入的 ISO 8601 日期/时间格式内建函数的输出，有轻微的调整。从现在开始，时区偏移，用于显示而且不是 Z 时，通常包含了分钟。比如在模板输出中， 15:30:15+02 现在就变成 15:30:15+02:00 了。根据ISO 8601(那么ISO 8601 日期/时间格式的内容应该不会有问题)两种格式都是合法的，但是最后的格式使用了 XML Schema 日期/时间格式来编译，因此做了这个修改。
新的内建函数，用来转义JSON字符串：json_string。
Bug修复：如果在同一个模板之前没有正确的 # 标记，错误的 # 标记被打印成静态的文本，而不会引发解析错误。因为这个修复并不会100%的向后兼容，老版本中的行为会被保留下来，除非你将 incompatible_enhancements (也就是Configuration.setIncompatibleEnhancements(String)) 设置成 "2.3.19" 或更高版本。

Java部分的修改

注意：本次发布包含两个重要的安全修复，很明显，这些安全问题会导致一些应用程序被利用。 FreeMarker不能在所有的配置中解决这个问题，所以请阅读下面的细节而不仅仅是升级FreeMarker！ 理论上，这些修改并不是100%向后兼容的，但是破坏任何东西也是不可能的。这两个修改是：
- The character with character code 0 (\u0000) is not allowed in template paths anymore. When a path contains it, FreeMarker behaves as if the template was not found.
  
  This is to fix the security problem where a template path like "secret.txt\u0000.ftl" is used to bypass extension filtering in an application. FreeMarker itself doesn't care about the extension, but some applications decide based on the extension if they will delegate a path to FreeMarker. When they do with such a path, the C/C++ implementation behind the storage mechanism may sees the path as "secret.txt" as the 0 terminates the string in C/C++, and thus load a non-FTL file as a template, returning the file contents to the attacker.
  
  Note that some HTTP servers, notably Tomcat and the Apache HTTP Server blocks URL-s where the URL contains 0 (%00) outside the query string, thus this wasn't exploitable there through such Web URL-s. Some other HTTP servers however, like Jetty, doesn't block such URL-s.
- ClassTemplateLoader, when it's created with base path "/" (like with new ClassTemplateLoader(someClass, "/")), will not allow template paths that contain colon earlier than any /, and will act like if the template was not found in such case.
  
  This is to fix the security problem where a template path like "file:/etc/secret" or "http://example.com/malware.ftl" is interpreted as a full URL by a java.net.URLClassLoader in the class-loader hierarchy, and thus allow loading files from these URL-s as templates. This is a quirk (or bug) of java.net.URLClassLoader, thus this problem only exists on systems that use such class-loaders.
  
  Beware, some frameworks use their own TemplateLoader implementations, and if those are vulnerable, they will remain so after updating FreeMarker too! Note that this exploit only works if the class-loader hierarchy contains an URLClassLoader and the class-loader is used to load templates without adding any prefix before the template path (other than "/").
These security issues mostly only affect applications where the user (the visitor) can supply arbitrary template paths to the application. This is not the case with properly built MVC applications, as there only the MVC Controller can be addressed directly, and it's the Controller that specifies the template paths. But legacy MVC applications based on JSP Model-2 often expose the MVC Views as public URL-s ending with .ftl, thus allowing the user to give arbitrary paths to FreeMarker. Such applications should be secured with a security-constratint in web.xml as shown in the related Manual section. This should be done regardless of the current security fixes.

In general, you should not allow users to specify arbitrary template paths, or if you do allow that, you should be extra careful with the TemplateLoader used.
Configuration has new methods: removeTemplateFromCache(...). This will remove the given template for the given locale from the cache, so it will be re-loaded regardless of the template update delay when it's next time requested.
BeansWrapper ignores setter methods from now when introspecting classes. They weren't used anyway, so they unnecessarily caused "java.beans.IntrospectionException: type mismatch between read and write methods" errors.
TemplateClassResolver.SAFER_RESOLVER now disallows creating freemarker.template.utility.JythonRuntime and freemarker.template.utility.Execute. This change affects the behavior of the new built-in if FreeMarker was configured to use SAFER_RESOLVER, which is not the default until 2.4 and is hence improbable.
Bug fixed: Calling varargs methods now indeed works. (Earlier it only worked for overloaded methods.)
Bug fixed [1837697] [2831150] [3039096] [3165425]: Jython support now works with Jython 2.2 and 2.5.
Bug fixed [3325103]: TemplateException-s and ParseException-s are now serializable.

Previous Next