MALICIOUS_CODE EI_EXPOSE_REP Medium

Question

Ejecuto findbugs contra todo mi código y solo abordo las cosas más importantes. Finalmente obtuve las mejores cosas resueltas y ahora estoy viendo los detalles. Tengo una entidad sencilla, por ejemplo un usuario:

public class User implements Serializable 
{ 
    protected Date birthDate; 

    public Date getBirthDate() 
    {return(birthDate);} 

    public void setBirthDate(final Date birthDate) 
    {this.birthDate = birthDate;} 
} 

Esta clase es incompleta, así que no me arpa en ello falta el material estándar serialVersionUID y otra, sólo estoy preocupado por el agujero de seguridad birthDate.

Ahora, de acuerdo con el informe de findbugs, dado que estoy devolviendo una referencia a un objeto mutable, ese es un posible riesgo de seguridad. Sin embargo, en la práctica, ¿cuánto importa eso realmente?

http://findbugs.sourceforge.net/bugDescriptions.html#EI_EXPOSE_REP

supongo que todavía no veo realmente cuál es el problema aquí en este caso. ¿Debo pasar un long y establecer la fecha a partir de eso?

Walter

Answer 1

Creo que la clave aquí es la si:

Si las instancias se accede por código no confiable, y cambios sin marcar para el objeto mutable comprometerían la seguridad u otras propiedades importantes que, tendrá que hacer algo diferente.

En otras palabras, si que quería un objeto inmutable (es decir, que no tenían un método setBirthdate()), su código sea incorrecto, porque alguien podría escribir:

Date date = user.getBirthDate(); 
date.setMonth(1); // mutated! 

Por lo que probablemente querría lo siguiente en su lugar:

public Date getBirthDate() 
{return new Date(birthDate.getTime());} // essentially a clone 

Answer 2

Bueno, yo diría que todo depende. Existen otros motivos no relacionados con la seguridad para devolver objetos inmutables, ya que también pueden provocar errores difíciles de encontrar en el código si el objeto se utiliza incorrectamente.

¿Se puede acceder a la clase por código y/o datos que no son de confianza? Si es así, debe tener una idea clara de dónde radica la responsabilidad en su aplicación con respecto a la validación de la información.

Además, ¿cuál es la naturaleza de la aplicación? Si es, por ejemplo, un servicio de red accesible externamente, la entrada debería considerarse potencialmente potencialmente maliciosa. Sin embargo, si se trata de una aplicación ejecutada localmente sin privilegios que recibe información de una fuente confiable, entonces probablemente no tenga que preocuparse.

Answer 3

Sí, realmente no lo llamaría un problema de 'seguridad' como tal ... Quiero decir, ¿qué atacante exactamente va a escribir código malicioso contra sus objetos? El problema real sería que es muy probable que usted tropiece accidentalmente al llamar al getBirthDate y luego modificar el resultado.

Por esta razón, es común tener sus objetos mutables de getter get como Date para regresar, cuando los está utilizando como tipos de valor.

(También podría argumentar que Java Date no debería haberse hecho mutable, pero no se puede hacer mucho al respecto ahora.)

Answer 4

Agregando a la buena respuesta de Matt Solnit, me he enfrentado el mismo problema al configurar un atributo, así que hizo lo mismo: bien

public void setDataEmissaoNota (Date dataEmissaoNota) 
{ 
    this.dataEmissaoNota = new Date(dataEmissaoNota.getTime()); 
} 

de trabajo!