Kingdom: Input Validation and Representation
Input validation and representation problems ares caused by metacharacters, alternate encodings and numeric representations. Security problems result from trusting input. The issues include: "Buffer Overflows," "Cross-Site Scripting" attacks, "SQL Injection," and many others.
Setting Manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 15
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.5.4 Input and Output Architectural Requirements (L2 L3), 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 13.1.1 Generic Web Service Security Verification Requirements (L1 L2 L3), 14.4.2 HTTP Security Headers Requirements (L1 L2 L3), 14.4.4 HTTP Security Headers Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[23] 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
[24] 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
[25] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.dotnet.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following C code accepts a number as one of its command line parameters and sets it as the host ID of the current machine.
Although a process must be privileged to successfully invoke
In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following C code accepts a number as one of its command line parameters and sets it as the host ID of the current machine.
...
sethostid(argv[1]);
...
Although a process must be privileged to successfully invoke
sethostid()
, unprivileged users may be able to invoke the program. The code in this example allows user input to directly control the value of a system setting. If an attacker provides a malicious value for host ID, the attacker may misidentify the affected machine on the network or cause other unintended behavior.In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 15
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.5.4 Input and Output Architectural Requirements (L2 L3), 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 13.1.1 Generic Web Service Security Verification Requirements (L1 L2 L3), 14.4.2 HTTP Security Headers Requirements (L1 L2 L3), 14.4.4 HTTP Security Headers Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[23] 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
[24] 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
[25] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.cpp.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following COBOL code snippet reads values from the terminal and uses them to compute the options used to establish access to a queue object.
In this example, an attacker could supply an option that allows shared rather than exclusive access to the queue.
In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following COBOL code snippet reads values from the terminal and uses them to compute the options used to establish access to a queue object.
...
ACCEPT OPT1.
ACCEPT OPT2
COMPUTE OPTS = OPT1 + OPT2.
CALL 'MQOPEN' USING HCONN, OBJECTDESC, OPTS, HOBJ, COMPOCODE REASON.
...
In this example, an attacker could supply an option that allows shared rather than exclusive access to the queue.
In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 15
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.5.4 Input and Output Architectural Requirements (L2 L3), 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 13.1.1 Generic Web Service Security Verification Requirements (L1 L2 L3), 14.4.2 HTTP Security Headers Requirements (L1 L2 L3), 14.4.4 HTTP Security Headers Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[23] 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
[24] 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
[25] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.cobol.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following code reads a number from a web form and uses it to set the timeout value in an initialization file.
Because the value of
In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following code reads a number from a web form and uses it to set the timeout value in an initialization file.
...
<cfset code = SetProfileString(IniPath,
Section, "timeout", Form.newTimeout)>
...
Because the value of
Form.newTimeout
is used to specify a timeout, an attacker may be able to mount a denial of service (DoS) attack against the application by specifying a sufficiently large number. In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 15
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.5.4 Input and Output Architectural Requirements (L2 L3), 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 13.1.1 Generic Web Service Security Verification Requirements (L1 L2 L3), 14.4.2 HTTP Security Headers Requirements (L1 L2 L3), 14.4.4 HTTP Security Headers Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[23] 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
[24] 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
[25] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.cfml.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following code snippet sets an environment variable with user-controlled data.
In this example, an attacker could set any arbitrary environment variable and affect how other applications work.
In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always obvious, but do not underestimate the creativity of your attacker.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following code snippet sets an environment variable with user-controlled data.
...
catalog := request.Form.Get("catalog")
path := request.Form.Get("path")
os.Setenv(catalog, path)
...
In this example, an attacker could set any arbitrary environment variable and affect how other applications work.
In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always obvious, but do not underestimate the creativity of your attacker.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 15
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.5.4 Input and Output Architectural Requirements (L2 L3), 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 13.1.1 Generic Web Service Security Verification Requirements (L1 L2 L3), 14.4.2 HTTP Security Headers Requirements (L1 L2 L3), 14.4.4 HTTP Security Headers Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[23] 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
[24] 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
[25] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.golang.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following Java code snippet reads a string from an
In this example, an attacker could cause an error by providing a nonexistent catalog name or connect to an unauthorized portion of the database.
In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following Java code snippet reads a string from an
HttpServletRequest
and sets it as the active catalog for a database Connection
.
...
conn.setCatalog(request.getParamter("catalog"));
...
In this example, an attacker could cause an error by providing a nonexistent catalog name or connect to an unauthorized portion of the database.
In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 15
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.5.4 Input and Output Architectural Requirements (L2 L3), 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 13.1.1 Generic Web Service Security Verification Requirements (L1 L2 L3), 14.4.2 HTTP Security Headers Requirements (L1 L2 L3), 14.4.4 HTTP Security Headers Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[23] 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
[24] 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
[25] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following Node.js code snippet reads a string from an
In this example, an attacker could cause various different flags to be set on the VM, which may result in unpredictable behavior including crashing the program and potentially data loss.
In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following Node.js code snippet reads a string from an
http.IncomingMessage
request variable and uses it to set additional V8 commnd line flags.
var v8 = require('v8');
...
var flags = url.parse(request.url, true)['query']['flags'];
...
v8.setFlagsFromString(flags);
...
In this example, an attacker could cause various different flags to be set on the VM, which may result in unpredictable behavior including crashing the program and potentially data loss.
In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 15
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.5.4 Input and Output Architectural Requirements (L2 L3), 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 13.1.1 Generic Web Service Security Verification Requirements (L1 L2 L3), 14.4.2 HTTP Security Headers Requirements (L1 L2 L3), 14.4.4 HTTP Security Headers Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[23] 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
[24] 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
[25] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.javascript.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following PHP code snippet reads a parameter from an HTTP request and sets it as the active catalog for a database connection.
In this example, an attacker could cause an error by providing a nonexistent catalog name or connect to an unauthorized portion of the database.
In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following PHP code snippet reads a parameter from an HTTP request and sets it as the active catalog for a database connection.
<?php
...
$table_name=$_GET['catalog'];
$retrieved_array = pg_copy_to($db_connection, $table_name);
...
?>
In this example, an attacker could cause an error by providing a nonexistent catalog name or connect to an unauthorized portion of the database.
In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 15
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.5.4 Input and Output Architectural Requirements (L2 L3), 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 13.1.1 Generic Web Service Security Verification Requirements (L1 L2 L3), 14.4.2 HTTP Security Headers Requirements (L1 L2 L3), 14.4.4 HTTP Security Headers Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[23] 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
[24] 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
[25] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.php.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following code snippet sets an environment variable using user-controlled data.
In this example, an attacker could set any arbitrary environment variable and affect how other applications work.
In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following code snippet sets an environment variable using user-controlled data.
...
catalog = request.GET['catalog']
path = request.GET['path']
os.putenv(catalog, path)
...
In this example, an attacker could set any arbitrary environment variable and affect how other applications work.
In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 15
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.5.4 Input and Output Architectural Requirements (L2 L3), 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 13.1.1 Generic Web Service Security Verification Requirements (L1 L2 L3), 14.4.2 HTTP Security Headers Requirements (L1 L2 L3), 14.4.4 HTTP Security Headers Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[23] 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
[24] 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
[25] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.python.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following Scala code snippet reads a string from an Http Request and sets it as the active catalog for a database
In this example, an attacker could cause an error by providing a nonexistent catalog name or connect to an unauthorized portion of the database.
In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following Scala code snippet reads a string from an Http Request and sets it as the active catalog for a database
Connection
.
def connect(catalog: String) = Action { request =>
...
conn.setCatalog(catalog)
...
}
In this example, an attacker could cause an error by providing a nonexistent catalog name or connect to an unauthorized portion of the database.
In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 15
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.5.4 Input and Output Architectural Requirements (L2 L3), 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 13.1.1 Generic Web Service Security Verification Requirements (L1 L2 L3), 14.4.2 HTTP Security Headers Requirements (L1 L2 L3), 14.4.4 HTTP Security Headers Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[23] 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
[24] 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
[25] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.scala.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following code configures the SQL log handler and uses a value controllable by the user.
In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following code configures the SQL log handler and uses a value controllable by the user.
...
sqlite3(SQLITE_CONFIG_LOG, user_controllable);
...
In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 15
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.5.4 Input and Output Architectural Requirements (L2 L3), 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 13.1.1 Generic Web Service Security Verification Requirements (L1 L2 L3), 14.4.2 HTTP Security Headers Requirements (L1 L2 L3), 14.4.4 HTTP Security Headers Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[23] 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
[24] 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
[25] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.swift.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following VB code snippet reads a string from a
In this example, an attacker could cause an error by providing a nonexistent catalog name or connect to an unauthorized portion of the database.
In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
Example 1: The following VB code snippet reads a string from a
Request
object and sets it as the active catalog for a database Connection
.
...
Dim conn As ADODB.Connection
Set conn = New ADODB.Connection
Dim rsTables As ADODB.Recordset
Dim Catalog As New ADOX.Catalog
Set Catalog.ActiveConnection = conn
Catalog.Create Request.Form("catalog")
...
In this example, an attacker could cause an error by providing a nonexistent catalog name or connect to an unauthorized portion of the database.
In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 15
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.5.4 Input and Output Architectural Requirements (L2 L3), 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 13.1.1 Generic Web Service Security Verification Requirements (L1 L2 L3), 14.4.2 HTTP Security Headers Requirements (L1 L2 L3), 14.4.4 HTTP Security Headers Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[23] 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
[24] 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
[25] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.vb.setting_manipulation