Java Reflection Abuse

Description

See CWE-470
Despite what you might assume, Java allows you to access private variables in other classes via its Reflection API. In untrusted API situations (e.g. plug-in architectures), this can lead to malicious libraries accessing and tampering with sensitive data.

Use the Java Security Manager to limit privileged API situations. While this feature is turned off by default, it’s actually critical for deploying a Java application securely (e.g. in a servlet container) where an utrusted API situation is in effect.

The ColdFusion database access APIs has had this vulnerability (CVE-2004-2331)
In 2012 and 2013, Java has had some severe vulnerabilities where the security manager was bypassed. In particular, CVE-2013-0422, CVE-2012-4681, and CVE-2012-3174 are all related to bugs in the Reflection API that bypasses the security manager and allows this abuse. In particular, bug 894172 at Red Hat is instructive, as well as two fixes at OpenJDK: ecc14534318c and d9969a953f69.

Many Java servers utilize a strict, security policy (e.g. Tomcat), however, many default installations of such servers do not force you to set up your security policy with the Java virtual machine.
The Java security manager blocks all kinds of other sensitive actions, such as System.exit(1);, file system access, or using reflection to instantiate singletons.
The Deployment & Distribution lecture covers more details on the Java Security Manager

  cd java-reflection-abuse
  make
  make safe