Java Security   «Prev  Next»

Validation of Input and Mutable Objects

Input-validation

In this module and the next, I will be covering the topics (at a very high level that are about ensuring data integrity. ) These topics include
  1. validation of imports
  2. Reduce use of, and limit access to mutable objects
  3. Securing confidential information
  4. Preventing injections and inclusion
If you are short on time, I would recommend understanding the problem which the guidelines are trying to solve, and try to remember as many of the guideline names as you can and how they relates to the particular problem.
An exam question may present you with the guideline that exists, but is not related to the particular problem the question is referencing.

Validation of Input and Mutable Objects

The URL below contains the Security Coding Guidelines from Oracle. Security Coding Guidelines
Let us start with validation of inputs. The goal here is to make sure that any inputs to the system will not have unintended consequences, especially inputs from an untrusted source, and therefore should be validated against known malicious techniques as described by these guidelines.

Guideline 1: Validation Inputs

Important Points: Maliciously crafted inputs are the cause of many problems:
  1. These can originate as method arguments or external streams.
  2. Examples include:
    1. Overflow of Integer values
    2. Directory traversal attacks by including 
      ../security/
      slash sequences and filenames
    3. Input from untrusted sources must be validated before use
    4. Input validation must occur after any defensive copying of an input

Guideline 2: Validate output from untrusted objects as input.

Important Points: In general method arguments should be validated but not return values.
  1. In the case of an upcall (invoking a method of higher level code) the return value should be validated.
  2. Especially vulnerable are calling methods on ClassLoaders
    1. An attacker might be able to control ClassLoader instances that get passed as arguments
    2. Multiple invocations of ClassLoader.loadClass() are not guaranteed to return the same Class instance or definition.

Guideline 3: Define wrappers around native methods

Important Points: Java code is subject to runtime checks for type, array bounds in library usage. Native code generally is not
  1. Java code is effectively immune to traditional buffer overflow attacks, well native methods are not.
  2. Do not declare a native method public.
  3. Declare a native method private and expose functionality through public Java based wrapper method.