Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Edited by sciSpider Java v3.0 (sch jp)

...

APIs capable of bypassing SecurityManager's checks

java.lang.Class.newInstance

java.lang.Class.getClassLoader

java.lang.Class.getClasses

java.lang.Class.getField(s)

java.lang.Class.getMethod(s)

java.lang.Class.getConstructor(s)

java.lang.Class.getDeclaredClasses

java.lang.Class.getDeclaredField(s)

java.lang.Class.getDeclaredMethod(s)

java.lang.Class.getDeclaredConstructor(s)

java.lang.ClassLoader.getParent

java.lang.ClassLoader.getSystemClassLoader

java.lang.Thread.getContextClassLoader

...

Noncompliant Code Example

The createInstance method is the immediate caller of java.lang.Class.newInstance <TO BE CONFIRMED> in this non-compliant noncompliant example. The newInstance method is being invoked on the dateClass class object. The issue is that the untrustedCode method can trigger the instantiation of a new class even though it should not have the permission to do so. This behavior is not caught by the security manager.

Code Block
bgColor#FFcccc
import java.util.Date;

public class exception
{
    public static void untrustedCode()
    {
    	 Date now = new Date();
         Class<?> dateClass = now.getClass();
         createInstance(dateClass);
    }
    public static void createInstance(Class<?> dateClass)
    {
        try
        {   // Create another Date object using the Date Class
            Object o = dateClass.newInstance();
            if (o instanceof Date)
            {
                Date d = (Date)o;
                System.out.println("The time is: " + d.toString());
            }
        }
        catch (InstantiationException ie) { System.out.println(ie.toString()); }
        catch (IllegalAccessException lae) { System.out.println(iae.toString()); }    	
    }
}

Compliant Solution

Do not accept Class, ClassLoader or Thread instances from untrusted code. If inevitable, safely acquire these instances by ensuring they come from trusted sources. Additionally, make sure to discard tainted inputs from untrusted code. Likewise, objects returned by the affected methods should not be propagated back to the untrusted code.

Risk Assessment

TODO

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

SEC02-J

??

??

??

P??

L??

Automated Detection

TODO

References

Inside Java 2 Platform Security, 4.3.2 Class Loader Delegation Hierarchy
Sun Secure Coding Guidelines