¿Las clases internas de Java representan un riesgo de seguridad?

Question

Recientemente, el equipo de seguridad de mi proyecto publicó un documento de pautas de código seguro, diseñado para ser utilizado como parte de las revisiones de nuestro código. Lo primero que me llamó la atención fue un artículo que decía "No use clases internas". Pensé que esto parecía una declaración muy arriesgada y arrolladora. Las clases internas son buenas si se usan correctamente ¿cierto ?, pero hice un poco de búsqueda en Google y encontré this, aquí citado para mayor comodidad.

Regla 5: No utilice clases internas

Algunos libros de lenguaje Java dicen que clases internas sólo se puede acceder por las clases externas que les rodean. Esto no es verdad. El código de bytes Java tiene sin concepto de clases internas, por lo que las clases internas son traducidas por el compilador en las clases ordinarias que pasan a ser accesibles a cualquier código en el mismo paquete . Y la Regla 4 dice que no se debe depender de en el alcance del paquete para la protección.

Pero espera, empeora. Una clase interna obtiene acceso a los campos de la clase externa , incluso si estos campos se declaran privados. Y la clase interna se traduce en una clase separada . Para permitir este acceso de clase por separado a los campos de la clase externa, el compilador cambia silenciosamente estos campos del ámbito del paquete privado al . Ya es suficientemente malo que la clase interna esté expuesta, pero es peor que el compilador que anula silenciosamente su decisión de hacer que algunos campos sean privados. No use las clases internas si puede evitarlo. (Irónicamente, el nuevo Java 2 directrices doPrivileged() uso de la API sugerimos que utilice una clase interna a escribir código privilegiado. Esa es una razón por la que no nos gusta la API doPrivileged()).

Mis preguntas son

1. ¿existe todavía este comportamiento en java 5/6?
2. ¿Es esto realmente un riesgo de seguridad, dado que cualquier clase, aparte de las clases externas e internas, que intentó acceder a los miembros privados de la clase externa no compilaría?
3. ¿Representa un riesgo de seguridad suficiente como para justificar la 'guía' 'No utilizar clases internas'?

Answer 1

Esta información es alrededor de una década a cabo de la fecha. El uso generalizado de clases internas anónimas con AccessController.doPrivileged debería ser una pista. (Si no te gusta la API, tenga en cuenta la proporción de try -. finally bloques que están incorrectamente faltan en el JDK)

La política es que hay dos clases pueden compartir el mismo paquete si están cargados por diferentes clases cargadores o tienen diferentes certificados. Para mayor protección, marque los paquetes como sellados en el manifiesto de sus jarras. Entonces, desde el punto de vista de la seguridad, la "Regla 4" es falsa y, por lo tanto, también esta regla.

En cualquier caso, al elaborar las políticas de seguridad, debe comprender aquello contra lo que está protegiendo.Este tipo de políticas son para manejar el código móvil (código que se mueve) que puede tener diferentes niveles de confianza. A menos que esté manejando un código móvil, o su código vaya a una biblioteca a la que pueda ser necesario, no tiene mucho sentido este tipo de precauciones. Sin embargo, casi siempre es una buena idea utilizar un estilo de programación robusto, por ejemplo copiar y validar argumentos y devolver valores.

Answer 2

1. Sí, este comportamiento todavía existe.
2. Es un riesgo de seguridad porque la clase de delincuentes podría diseñarse con algo más que el javac estándar.
3. Depende de cuán paranoico sea :) Si no permite que se ejecuten clases extraterrestres en su JVM, no veo el problema. Y si lo haces, tienes problemas más grandes (cajas de arena y todo)
4. Sé que solo tienes 3 preguntas, pero al igual que otras personas aquí, creo que es una restricción estúpida.

Answer 3

La idea de este tipo de seguridad en el código es algo tonto. Si desea seguridad a nivel de código, use una herramienta de ofuscación. Como dijo @skaffman en los comentarios anteriores, "la visibilidad del código nunca ha sido una característica de seguridad. Incluso se puede acceder a los miembros privados mediante la reflexión".

Si está distribuyendo su código compilado y no lo ofusca, usar una clase interna es su última preocupación si le preocupa que las personas jueguen con sus partes privadas.

Si está alojando su código, ¿por qué le preocupa que alguien hurgue en sus clases internas?

Si va a vincular un código de terceros en el que no confía y no puede verificar en el tiempo de ejecución, sandbox.

como he dicho anteriormente, si esto es realmente una política en su empresa, por favor informar de inmediato a su empresa a thedailywtf.com

Answer 4

Debe tener en cuenta qué tipo de seguridad que su aplicación tiene que ofrecer. Una aplicación con una arquitectura segura no se ejecutará en estos problemas nombrados.

Si hay algo que un usuario no puede hacer con su código, debe separar esta funcionalidad y ejecutarla en un servidor (donde el usuario no tiene acceso a los archivos de clase).

Recuerde que siempre puede descompilar los archivos de la clase java. Y no confíe en la "seguridad por oscuridad". Incluso el código ofuscado se puede analizar, comprender y modificar.

Answer 5

El código malintencionado puede usar el reflejo de java para acceder a cualquier información en la JVM a menos que haya un administrador de seguridad que lo prohíba, esto incluye el cambio de campos privados a público y mucho más.

Mi opinión personal es que las razones para no hacerlo, son abrumadas por las otras posibilidades, por lo que si lo necesita, tiene sentido, y es legible, use clases internas.

Answer 6

Tenga en cuenta que los inconvenientes mencionados no se aplican a static clases internas, ya que no tienen acceso implícito a su clase envolvente (u objeto realmente.)

Así que si esta regla va a ayudar en su empresa, podría ser una idea obtener clases internas estáticas excedidas ya que ofrecen una forma de encapsulación que es útil en muchos casos.

@ Tom, citando el Java language specification, "clases pueden ser miembros estática, en cuyo caso tienen ningún acceso a las variables de instancia de la clase que rodea"

Answer 7

¿Este comportamiento todavía existe en java 5/6?

Puede usar la herramienta javap para determinar qué exponen sus binarios y cómo.

package demo; 
public class SyntheticAccessors { 
    private boolean encapsulatedThing; 

    class Inner { 
    void doSomething() { 
     encapsulatedThing = true; 
    } 
    } 
} 

El código anterior (recopilada con Sun Java 6 javac) crea estos métodos en SyntheticAccessors.class:

Compiled from "SyntheticAccessors.java" 
public class demo.SyntheticAccessors extends java.lang.Object{ 
    public demo.SyntheticAccessors(); 
    static void access$0(demo.SyntheticAccessors, boolean); 
} 

Nota access$0 el nuevo método.

Answer 8

¿Este comportamiento todavía existe en java 5/6?

No exactamente como se describe; Nunca he visto un compilador donde esto era cierto:

Para permitir este acceso de clase separado a los campos de la clase externa, el compilador cambia silenciosamente estos campos del ámbito privado al del paquete.

En lugar de IIRC Sun Java 3/4 creó un acceso en lugar de modificar el campo.

Sun Java 6 (javac 1.6.0_16) crea un descriptor de acceso estática:

public class InnerExample { 
    private int field = 42; 

    private class InnerClass { 
     public int getField() { return field; }; 
    } 

    private InnerClass getInner() { 
     return new InnerClass(); 
    } 

    public static void main (String...args) { 
     System.out.println(new InnerExample().getInner().getField()); 
    } 
} 


$ javap -classpath bin -private InnerExample 
Compiled from "InnerExample.java" 
public class InnerExample extends java.lang.Object{ 
    private int field; 
    public InnerExample(); 
    private InnerExample$InnerClass getInner(); 
    public static void main(java.lang.String[]); 
    static int access$000(InnerExample); 
} 


$ javap -classpath bin -c -private InnerExample 
static int access$000(InnerExample); 
    Code: 
    0: aload_0 
    1: getfield #1; //Field field:I 
    4: ireturn 

¿Es esto realmente un riesgo de seguridad, dado que cualquier clase, con excepción de las clases externas e internas, que intentó acceder a los miembros privados de la clase externa ¿no com [p] ile?

Estoy especulando un poco aquí, pero si compila contra la clase no lo hace, pero si se agrega el access$000 entonces se puede compilar código que utiliza el descriptor de acceso.

import java.lang.reflect.*; 

public class InnerThief { 
    public static void main (String...args) throws Exception { 
     for (Method me : InnerExample.class.getDeclaredMethods()){ 
      System.out.println(me); 
      System.out.printf("%08x\n",me.getModifiers()); 
     } 

     System.out.println(InnerExample.access$000(new InnerExample())); 
    } 
} 

Lo interesante es que el descriptor de acceso sintetizado tiene banderas modificadoras 00001008 donde si se agrega un método estático nivel de paquete que tiene banderas 00000008. No hay nada en la segunda edición de la especificación de JVM para ese valor de indicador, pero parece evitar que javac vea el método.

Parece que hay alguna función de seguridad allí, pero no encuentro ninguna documentación sobre la misma.

(de ahí este blog en CW, en caso de que alguien sabe lo 0x1000 significa en un archivo de clase)

Answer 9

"¿Es esto realmente un riesgo de seguridad, dado que cualquier clase, con excepción de las clases externas e internas, que ¿Intentó acceder a la clase externa que los miembros privados no compilarían?"

Incluso si no se compilará en circunstancias normales, todavía se puede generar su propio código de bytes. Pero eso no es razón para evitar las clases internas. Todo lo que tendría que hacer es asumir todas sus clases internas son públicos.

Si realmente quiere ser capaz de ejecutar código no confiable, aprender cómo configurar sus propias cajas de arena y niveles de seguridad utilizando The Java Security Architecture, no es tan difícil. Pero sobre todo, se debe evitar la ejecución de código al azar en un entorno seguro.

Answer 10

disparate ! siga la misma lógica, tampoco escriba métodos públicos, ya que tienen acceso a campos privados, gush!