External Initialization of Trusted Variables or Data Stores

Description

A product system should be reluctant to trust variables that have been initialized outside of its trust boundary, especially if they are initialized by users. The variables may have been initialized incorrectly. If an attacker can initialize the variable, then they can influence what the vulnerable system will do.

Demonstrations

The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.

Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.

Example One

In the Java example below, a system property controls the debug level of the application.

int debugLevel = Integer.getInteger("com.domain.application.debugLevel").intValue();

If an attacker is able to modify the system property, then it may be possible to coax the application into divulging sensitive information by virtue of the fact that additional debug information is printed/exposed as the debug level increases.

Example Two

This code checks the HTTP POST request for a debug switch, and enables a debug mode if the switch is set.

$debugEnabled = false;
if ($_POST["debug"] == "true"){
  $debugEnabled = true;
}
/.../

function login($username, $password){
  if($debugEnabled){
    echo 'Debug Activated';
    phpinfo();
    $isAdmin = True;
    return True;
  }
}

Any user can activate the debug mode, gaining administrator privileges. An attacker may also use the information printed by the phpinfo() function to further exploit the system. .

This example also exhibits Information Exposure Through Debug Information (CWE-215)

See Also