Commons BeanUtilsMost Java developers are used to creating Java classes that conform to the JavaBeans naming patterns for property getters and setters. It is natural to then access these methods directly, using calls to the corresponding getXxx and setXxx methods. However, there are some occasions where dynamic access to Java object properties (without compiled-in knowledge of the property getter and setter methods to be called) is needed. Example use cases include:
The Java language provides Reflection and Introspection APIs (see the java.lang.reflect and java.beans packages in the JDK Javadocs). However, these APIs can be quite complex to understand and utilize. The BeanUtils component provides easy-to-use wrappers around these capabilities. BeanUtils Core And ModulesThe 1.7.x and 1.8.x releases of BeanUtils have distributed three jars:
Version 1.9.0 reverts this split for reasons outlined at BEANUTILS-379. There is now only one jar for the BeanUtils library. Bean CollectionsBean collections is a library combining BeanUtils with Commons Collections to provide services for collections of beans. One class (BeanComparator) was previously released, the rest are new. This new distribution strategy should allow this sub-component to evolve naturally without the concerns about size and scope that might otherwise happen. Bean Collections has an additional dependency on Commons Collections. Releases1.9.x releases
The latest BeanUtils release is available to download
here. Severity. Medium Vendor. The Apache Software Foundation Versions Affected. All versions commons-beanutils-1.9.3 and before. Description. A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the class property of Java objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows class level property access by default, thus protecting against CVE-2014-0114. Mitigation. Upgrade to commons-beanutils-1.9.4 Credit. This was discovered by Melloware (https://melloware.com/). Example. /** * Example displaying the new default behaviour such that * it is not possible to access class level properties utilizing the * BeanUtilsBean, which in turn utilizes the PropertyUtilsBean. */ public void testSuppressClassPropertyByDefault() throws Exception { final BeanUtilsBean bub = new BeanUtilsBean(); final AlphaBean bean = new AlphaBean(); try { bub.getProperty(bean, "class"); fail("Could access class property!"); } catch (final NoSuchMethodException ex) { // ok } } /** * Example showing how by which one would use to revert to the * behaviour prior to the 1.9.4 release where class level properties were accessible by * the BeanUtilsBean and the PropertyUtilsBean. */ public void testAllowAccessToClassProperty() throws Exception { final BeanUtilsBean bub = new BeanUtilsBean(); bub.getPropertyUtils().removeBeanIntrospector(SuppressPropertiesBeanIntrospector.SUPPRESS_CLASS); final AlphaBean bean = new AlphaBean(); String result = bub.getProperty(bean, "class"); assertEquals("Class property should have been accessed", "class org.apache.commons.beanutils2.AlphaBean", result); } BeanUtils 1.9.x releases are binary compatible (with a minor exception described in the release notes) with version 1.8.3 and require a minimum of JDK 1.5. The latest BeanUtils release is available to download here.
1.8.x releasesBeanUtils 1.8.x releases are binary compatible with version 1.7.0 and require a minimum of JDK 1.3.
1.7.0BeanUtils 1.7.0 is a service release which removes the dependency upon a specific commons-collection library version. It may be safely used together with either the 2.x or 3.x series of commons-collections releases. It also introduces a number of important enhancements. It is backward compatible with the 1.6 release. This important service release is intended to help downstream applications solve dependency issues. The dependency on commons collections (which has become problematic now that there are two incompatible series of commons collections releases) has been factored into a separate optional sub-component plus a small number of stable and mature org.apache.commons.collections packaged classes (which are distributed with the BeanUtils core). This arrangement means that the BeanUtils core sub-component (which is the primary dependency for most downsteam applications) can now be safely included on the same classpath as commons collections 2.x, 3.x or indeed neither. The distribution now contains alternative jar sets. The all-in-one jar contains all classes. The modular jar set consists of a core jar dependent only on commons logging and an optional bean collections jar (containing classes that provide easy and efficient ways to manage collections of beans) which depends on commons collections 3. Older Releases (Not Mirrored)
SupportThe commons mailing lists act as the main support forum. The user list is suitable for most library usage queries. The dev list is intended for the development discussion. Please remember that the lists are shared between all commons components, so prefix your email by [beanutils]. Issues may be reported via ASF JIRA. |