Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Security manager checks are not conducted in case of native method invocations. Additionally, as demonstrated in the noncompliant code example, it is easy to overlook proper input validation before the call. The doOperation method invokes the nativeOperation native method but fails to provide adequate validation. Also, the access specifier of the native method is public which raises risks associated with untrusted callers to provide adequate validation. (Note that native methods may even increase susceptibility to non-Java specific vulnerabilities, such as buffer overflows. )

Code Block
bgColor#FFcccc
public final class NativeMethod {

  // private native method
  privatepublic native void nativeOperation(byte[] data, int offset, int len);

  // wrapper method that does not perform any security checks or input validation
  public void doOperation(byte[] data, int offset, int len) {
    nativeOperation(data, offset, len);
  }
  
  static {
    System.loadLibrary("NativeMethodLib"); //load native library in static initializer of class
  }
}

...

This compliant solution makes the actual native method private and defines a public wrapper that calls securityManagerCheck() which in turn performs routine permission checks to determine if the succeeding operations can continue. This is followed by input range checking and creation of a copy of the mutable input array, data. Finally the nativeOperation method is called with sanitized inputs. Ensure that the validation checks produce outputs that are coherent with the input requirements of the native implementations/libraries.

...