Reino: Encapsulation

La encapsulación consiste en crear límites fuertes. En un explorador web esto puede suponer la seguridad de que tu codificación móvil no se vea comprometido por otro código móvil. En el servidor puede significar la diferenciación entre los datos validados y los que no lo están, entre los datos de un usuario y los de otro, o entre los diferentes usuarios, los datos que pueden ver y los que no.

106 elementos encontrados
Debilidades
Abstract
El programa infringe los principio de codificación segura para código móvil devolviendo una variable de matriz private desde un método de acceso public.
Explanation
Devolver una variable de matriz private desde un método de acceso public permite que el código de llamada modifique el contenido de la matriz, dando a la matriz acceso public y contradiciendo las intenciones del programador que la hizo private.

Ejemplo 1: el siguiente código Applet de Java devuelve incorrectamente una matriz private desde un método de acceso public.


public final class urlTool extends Applet {
private URL[] urls;
public URL[] getURLs() {
return urls;
}
...
}


El código móvil, en este caso un Applet de Java, es el código que se transmite por una red y se ejecuta en un equipo remoto. Como los desarrolladores de código móvil tienen poco o ningún control sobre el entorno en el que su código se va a ejecutar, aparecen preocupaciones especiales en materia de seguridad. Una de las mayores amenazas del entorno proceden del riesgo de que el código móvil se ejecute a la par con otro código móvil, potencialmente malintencionado. Como todos los exploradores web más populares ejecutan código desde varios orígenes juntos en el mismo JVM, muchas de estas instrucciones de seguridad para el código móvil se centran en evitar la manipulación del estado y el comportamiento de sus objetos por parte de adversarios que tienen acceso a la misma máquina virtual en la que se ejecuta su programa.
References
[1] G. McGraw Securing Java. Chapter 7: Java Security Guidelines
[2] Standards Mapping - Common Weakness Enumeration CWE ID 495
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)
desc.structural.java.unsafe_mobile_code_access_violation
Abstract
Los Applets que realizan operaciones de base de datos JDBC en un entorno no confiable pueden comprometer las credenciales de la base de datos.
Explanation
De forma predeterminada, los Applets de Java tienen permitido abrir las conexiones de base de datos en el servidor desde donde se descargan. Esto es aceptable en entornos confiables; sin embargo, en los entornos no confiables los atacantes pueden usar el Applet para detectar credenciales de base de datos y finalmente obtener acceso a la base de datos directamente.
Ejemplo 1: el código siguiente muestra una contraseña de base de datos codificada de forma rígida que se está usando en un applet.

public class CustomerServiceApplet extends JApplet
{
public void paint(Graphics g)
{
...
conn = DriverManager.getConnection ("jdbc:mysql://db.example.com/customerDB", "csr", "p4ssw0rd");
...


Los usuarios de un Applet con credenciales JDBC codificadas de forma rígida pueden detectar fácilmente las credenciales, ya que el código de Applet se descarga en el cliente. Además, si la conexión de base de datos se realiza por un canal no cifrado, cualquiera que sea capaz de examinar el tráfico de red también puede obtener las credenciales. Finalmente, permitir a los usuarios conectarse directamente a una base de datos revela la presencia de un servidor de base de datos accesible públicamente, que permite a los atacantes centrarse en la base de datos para ataques de red directos.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 305
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[22] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)
desc.structural.java.unsafe_mobile_code_database_access
Abstract
El programa infringe los principios de codificación segura para código móvil usando una clase interna.
Explanation
Las clases internas introducen discretamente varios problemas de seguridad por la forma en que se traducen en código de bytes Java. En el código fuente Java, parece ser que una clase interna se puede declarar para que sea accesible solo para clase envolvente. Sin embargo, como el código de bytes de Java no tiene concepto de clase interna, el compilador debe transformar una declaración de clase interna en una clase del mismo nivel, con un nivel de acceso de package a la clase externa original. Es más, como una clase interna puede acceder a campos private en su clase envolvente, una vez que una clase interna se convierte en otra del mismo nivel en código de bytes, el compilador convierte los campos private a los que accede la clase interna en campos protected.

Ejemplo 1: el siguiente código Applet de Java utiliza incorrectamente una clase interna.


public final class urlTool extends Applet {
private final class urlHelper {
...
}
...
}


El código móvil, en este caso un Applet de Java, es el código que se transmite por una red y se ejecuta en un equipo remoto. Como los desarrolladores de código móvil tienen poco o ningún control sobre el entorno en el que su código se va a ejecutar, aparecen preocupaciones especiales en materia de seguridad. Una de las mayores amenazas del entorno proceden del riesgo de que el código móvil se ejecute a la par con otro código móvil, potencialmente malintencionado. Como todos los exploradores web más populares ejecutan código desde varios orígenes juntos en el mismo JVM, muchas de estas instrucciones de seguridad para el código móvil se centran en evitar la manipulación del estado y el comportamiento de sus objetos por parte de adversarios que tienen acceso a la misma máquina virtual en la que se ejecuta su programa.
References
[1] G. McGraw Securing Java. Chapter 7: Java Security Guidelines
[2] Standards Mapping - Common Weakness Enumeration CWE ID 492
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[12] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[15] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)
desc.structural.java.unsafe_mobile_code_inner_class
Abstract
El programa infringe los principios de codificación segura para código móvil declarando un método finalize() como public.
Explanation
Un programa nunca debería llamar la finalización de forma explícita, salvo llamar super.finalize() dentro de una implementación de finalize(). En situaciones de código móvil, la práctica errónea de recolección manual de elementos no utilizados puede convertirse en una amenaza para la seguridad si un atacante es capaz de invocar de forma malintencionada uno de sus métodos finalize() porque se ha declarado con acceso public. Si está utilizando finalize() tal cual se diseñó, no hay motivos para declarar finalize() con otro acceso que no sea protected.

Ejemplo 1: el siguiente código Applet de Java declara incorrectamente un método public finalize().


public final class urlTool extends Applet {
public void finalize() {
...
}
...
}


El código móvil, en este caso un Applet de Java, es el código que se transmite por una red y se ejecuta en un equipo remoto. Como los desarrolladores de código móvil tienen poco o ningún control sobre el entorno en el que su código se va a ejecutar, aparecen preocupaciones especiales en materia de seguridad. Una de las mayores amenazas del entorno proceden del riesgo de que el código móvil se ejecute a la par con otro código móvil, potencialmente malintencionado. Como todos los exploradores web más populares ejecutan código desde varios orígenes juntos en el mismo JVM, muchas de estas instrucciones de seguridad para el código móvil se centran en evitar la manipulación del estado y el comportamiento de sus objetos por parte de adversarios que tienen acceso a la misma máquina virtual en la que se ejecuta su programa.
References
[1] G. McGraw Securing Java. Chapter 7: Java Security Guidelines
[2] MET12-J. Do not use finalizers CERT
[3] Standards Mapping - Common Weakness Enumeration CWE ID 583
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)
desc.structural.java.unsafe_mobile_code_public_finalize_method
Abstract
El programa infringe los principios de codificación segura para código móvil declarando una matriz public, final y static.
Explanation
En la mayoría de los casos una matriz declarada public, final y static es un error. Como las matrices son objetos mutables, la restricción final requiere que el propio objeto de matriz se asigne una sola vez, pero no garantiza los valores de los elementos de matriz. Como la matriz es pública, un programa malintencionado podría cambiar los valores almacenados en ella. En la mayoría de los casos, la matriz debe hacerse private.

Ejemplo 1: el siguiente código Applet de Java declara incorrectamente una matriz public, final y static.


public final class urlTool extends Applet {
public final static URL[] urls;
...
}


El código móvil, en este caso un Applet de Java, es el código que se transmite por una red y se ejecuta en un equipo remoto. Como los desarrolladores de código móvil tienen poco o ningún control sobre el entorno en el que su código se va a ejecutar, aparecen preocupaciones especiales en materia de seguridad. Una de las mayores amenazas del entorno proceden del riesgo de que el código móvil se ejecute a la par con otro código móvil, potencialmente malintencionado. Como todos los exploradores web más populares ejecutan código desde varios orígenes juntos en el mismo JVM, muchas de estas instrucciones de seguridad para el código móvil se centran en evitar la manipulación del estado y el comportamiento de sus objetos por parte de adversarios que tienen acceso a la misma máquina virtual en la que se ejecuta su programa.
References
[1] G. McGraw Securing Java. Chapter 7: Java Security Guidelines
[2] Standards Mapping - Common Weakness Enumeration CWE ID 582
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[12] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[15] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)
desc.structural.java.unsafe_mobile_code_unsafe_array_declaration
Abstract
El programa infringe los principios de codificación segura para el código móvil declarando una variable de miembro public pero no final.
Explanation
Todas las variables de miembro public de un Applet y las clases usadas por un Applet se deben declarar final para impedir que un atacante manipule u obtenga acceso no autorizado al estado interno del Applet.

Ejemplo 1: el siguiente código Applet de Java declara incorrectamente una variable de miembro public pero no final.


public final class urlTool extends Applet {
public URL url;
...
}


El código móvil, en este caso un Applet de Java, es el código que se transmite por una red y se ejecuta en un equipo remoto. Como los desarrolladores de código móvil tienen poco o ningún control sobre el entorno en el que su código se va a ejecutar, aparecen preocupaciones especiales en materia de seguridad. Una de las mayores amenazas del entorno proceden del riesgo de que el código móvil se ejecute a la par con otro código móvil, potencialmente malintencionado. Como todos los exploradores web más populares ejecutan código desde varios orígenes juntos en el mismo JVM, muchas de estas instrucciones de seguridad para el código móvil se centran en evitar la manipulación del estado y el comportamiento de sus objetos por parte de adversarios que tienen acceso a la misma máquina virtual en la que se ejecuta su programa.
References
[1] G. McGraw Securing Java. Chapter 7: Java Security Guidelines
[2] MUTABLE-8: Define wrapper methods around modifiable internal state Oracle
[3] Standards Mapping - Common Weakness Enumeration CWE ID 493
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)
desc.structural.java.unsafe_mobile_code_unsafe_public_field