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.

2 items found
Weaknesses
Abstract
The program accesses a variable in an ambiguous way, which can leave it open to attack.
Explanation
The HttpRequest class provides programmatic access to variables from the QueryString, Form, Cookies or ServerVariables collections in the form of an array access (e.g. Request["myParam"]). When more than one variable exists with the same name, the .NET framework returns the value of the variable that appears first when the collections are searched in the following order: QueryString, Form, Cookies then ServerVariables. Since QueryString comes first in the search order, it is possible for QueryString parameters to supersede values from forms, cookies, and server variables. Similarly, form values can supersede variables in the Cookies and ServerVariables collections and variables from the Cookies collection can supersede those from ServerVariables.
Example 1: Imagine a banking application temporarily stores a user's email address in a cookie and reads this value when it wants to contact the user. The following code reads the cookie value and sends an account balance to the specified email address.

...
String toAddress = Request["email"]; //Expects cookie value
Double balance = GetBalance(userID);
SendAccountBalance(toAddress, balance);
...

Assume the code in Example 1 is executed when visiting http://www.example.com/GetBalance.aspx. If an attacker can cause an authenticated user to click a link that requests http://www.example.com/GetBalance.aspx?email=evil%40evil.com, an email with the user's account balance will be sent to evil@evil.com.
References
[1] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310
[2] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[3] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[4] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[5] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[9] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[10] 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
[11] 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
[12] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II
desc.semantic.dotnet.value_shadowing
Abstract
The program accesses a server variable in an ambiguous way, which can leave it open to attack.
Explanation
The HttpRequest class provides programmatic access to variables from the QueryString, Form, Cookies or ServerVariables collections in the form of an array access (e.g. Request["myParam"]). When more than one variable exists with the same name, the .NET framework returns the value of the variable that appears first when the collections are searched in the following order: QueryString, Form, Cookies then ServerVariables. Since QueryString comes first in the search order, it is possible for QueryString parameters to supersede values from forms, cookies, and server variables. Similarly, form values can supersede variables in the Cookies and ServerVariables collections and variables from the Cookies collection can supersede those from ServerVariables.
Example 1: The following code checks the HTTP Referer header server variable to see if the request came from www.example.com before serving content.

...
if (Request["HTTP_REFERER"].StartsWith("http://www.example.com"))
ServeContent();
else
Response.Redirect("http://www.example.com/");
...


Assume the code in Example 1 is executed when visiting http://www.example.com/ProtectedImages.aspx. If an attacker makes a direct request to the URL, the appropriate referer header will not be set and the request will fail. However, if the attacker submits an artificial HTTP_REFERER parameter with the necessary value, such as http://www.example.com/ProtectedImages.aspx?HTTP_REFERER=http%3a%2f%2fwww.example.com, then the lookup will return the value from QueryString instead of ServerVariables and the check will succeed.
References
[1] Microsoft IIS Server Variables
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[5] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[10] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[11] 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
[12] 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
[13] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II
desc.semantic.dotnet.value_shadowing_server_variable