4 items found
Weaknesses
Abstract
Configuring PHP to register all environment, GET, POST, cookie, and server variables globally can lead to unexpected behavior and leaves the door open for attackers.
Explanation
When enabled, the register_globals option causes PHP to register all EGPCS (Environment, GET, POST, Cookie, and Server) variables globally, where they can be accessed in any scope in any PHP program. This option encourages programmers to write programs that are more-or-less unaware of the origin of values they rely on, which can lead to unexpected behavior in benign environments and leaves the door open to attackers in malicious environments. In recognition the dangerous security implications of register_globals, the option was disabled by default in PHP 4.2.0 and was deprecated and removed in PHP 6.

Example 1: The following code is vulnerable to cross-site scripting. The programmer assumes the value of $username originates from the server-controlled session, but an attacker may supply a malicious value for $username as a request parameter instead. With register_globals enabled, this code will include a malicious value submitted by an attacker in the dynamic HTML content it generates.


<?php
if (isset($username)) {
echo "Hello <b>$username</b>";
} else {
echo "Hello <b>Guest</b><br />";
echo "Would you like to login?";

}
?>
References
[1] M. Achour et al. PHP Manual
[2] Standards Mapping - Common Weakness Enumeration CWE ID 473
[3] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[4] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[5] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[6] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[7] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[8] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[9] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.php.php_misconfiguration_register_globals
Abstract
The program invokes a function that can overwrite variables, which can open the door for attackers.
Explanation
Functions that can overwrite variables that are already initialized can allow an attacker to influence the execution of code that relies on the overwritten variables.
can overwrite variables.

Example 1: If an attacker supplies a malicious value for varName in the following segment of ColdFusion code, then the call to SetVariable() might overwrite any arbitrary variables, including #first#. In this case, if a malicious value that contains JavaScript overwrites #first#, then the program is vulnerable to cross-site scripting.


<cfset first = "User">
<cfscript>
SetVariable(url.varName, url.varValue);
</cfscript>
<cfoutput>
#first#
</cfoutput>
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 473
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[6] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[16] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II
desc.dataflow.cfml.possible_variable_overwrite
Abstract
The program invokes a function that can overwrite variables in the current scope, which can open the door for attackers.
Explanation
Functions that can overwrite variables that are already initialized in the current scope can allow an attacker to influence the execution of code that relies on the overwritten variables.
Example 1: If an attacker supplies a malicious value for str in the following segment of PHP code, then the call to parse_str() might overwrite any arbitrary variables in the current scope, including first. In this case, if a malicious value that contains JavaScript overwrites first, then the program is vulnerable to cross-site scripting.


<?php
$first="User";
...
$str = $_SERVER['QUERY_STRING'];
parse_str($str);
echo $first;
?>
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 473
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[12] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[15] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II
desc.dataflow.php.possible_variable_overwrite_current_scope
Abstract
The program invokes a function that can overwrite global variables, which can open the door for attackers.
Explanation
Functions that can overwrite global variables that are already initialized can allow an attacker to influence the execution of code that relies on the overwritten variables.
Example 1: If an attacker supplies a malicious value for str in the following segment of PHP code, then the call to mb_parse_str() might overwrite any arbitrary variables, including first. In this case, if a malicious value that contains JavaScript overwrites first, then the program is vulnerable to cross-site scripting.


<?php
$first="User";
...
$str = $_SERVER['QUERY_STRING'];
mb_parse_str($str);
echo $first;
?>
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 473
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[12] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[15] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II
desc.dataflow.php.possible_variable_overwrite_global