3 elementos encontrados
Debilidades
Abstract
Esta función infringe el contrato que debe comparar su parámetro con null.
Explanation
El estándar de Java exige que las implementaciones de Object.equals(), Comparable.compareTo() y Comparator.compare() devuelvan un valor especificado si sus parámetros son null. De no cumplir el contrato se daría lugar a un comportamiento inesperado.

Ejemplo 1: La implementación siguiente del método equals() no compara su parámetro con null.


public boolean equals(Object object)
{
return (toString().equals(object.toString()));
}
References
[1] MET10-J. Follow the general contract when implementing the compareTo() method CERT
[2] MET08-J. Preserve the equality contract when overriding the equals() method CERT
[3] Standards Mapping - Common Weakness Enumeration CWE ID 398
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
desc.controlflow.java.missing_check_for_null_parameter
Abstract
El programa accede a una variable de forma ambigua, lo que puede dejarlo abierto a ataques.
Explanation
La clase HttpRequest proporciona acceso programático a las variables procedentes de las colecciones QueryString, Form, Cookies o ServerVariables en la forma de un acceso de matriz (p. ej. Request["myParam"]). Cuando existe más de una variable con el mismo nombre, .NET Framework devuelve el valor de la variable que aparece primero cuando se buscan las colecciones en el siguiente orden: QueryString, Form, Cookies y ServerVariables. Como QueryString está primero en el orden de búsqueda, los parámetros QueryString pueden sustituir los valores de variables de servidor, cookies y formularios. Del mismo modo, los valores de formularios pueden reemplazar las variables de las colecciones Cookies y ServerVariables, y las variables de la colección Cookies pueden reemplazar las de ServerVariables.
Ejemplo 1: imaginemos que una aplicación bancaria almacena de forma temporal la dirección de correo electrónico de un usuario en una cookie y que lee este valor cuando quiere ponerse en contacto con el usuario en cuestión. El siguiente código lee el valor de la cookie y envía un balance de cuentas a la dirección de correo electrónico especificada.

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

Supongamos que el código en el Example 1 se ejecuta al visitar http://www.example.com/GetBalance.aspx. Si un atacante puede hacer que un usuario autenticado haga clic en un enlace que solicite http://www.example.com/GetBalance.aspx?email=evil%40evil.com, se enviará un mensaje de correo electrónico con el balance de cuentas del usuario a 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
El programa accede a una variable del servidor de forma ambigua, lo que puede dejarlo abierto a ataques.
Explanation
La clase HttpRequest proporciona acceso programático a las variables procedentes de las colecciones QueryString, Form, Cookies o ServerVariables en la forma de un acceso de matriz (p. ej. Request["myParam"]). Cuando existe más de una variable con el mismo nombre, .NET Framework devuelve el valor de la variable que aparece primero cuando se buscan las colecciones en el siguiente orden: QueryString, Form, Cookies y ServerVariables. Como QueryString está primero en el orden de búsqueda, los parámetros QueryString pueden sustituir los valores de variables de servidor, cookies y formularios. Del mismo modo, los valores de formularios pueden reemplazar las variables de las colecciones Cookies y ServerVariables, y las variables de la colección Cookies pueden reemplazar las de ServerVariables.
Ejemplo 1: el siguiente código comprueba la variable del servidor del encabezado de referencia HTTP para ver si la solicitud proviene de www.example.com antes de proporcionar contenido.

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


Supongamos que el código en el Example 1 se ejecuta al visitar http://www.example.com/ProtectedImages.aspx. Si un atacante realiza una solicitud directa a la URL, no se establecerá el encabezado de referencia correspondiente y la solicitud no se cumplirá. No obstante, si el atacante envía un parámetro HTTP_REFERER artificial con el valor requerido, como http://www.example.com/ProtectedImages.aspx?HTTP_REFERER=http%3a%2f%2fwww.example.com, la búsqueda devolverá el valor de QueryString en lugar de ServerVariables y se realizará la comprobación.
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