MALICIOUS_CODE EI_EXPOSE_REP Средний - PullRequest
Новая
       8

MALICIOUS_CODE EI_EXPOSE_REP Средний

15 голосов
/ 14 ноября 2009

Я запускаю findbugs для всего своего кода и берусь только за самые лучшие вещи. Я наконец-то решил главные вещи и теперь смотрю на детали. У меня есть простая сущность, скажем, пользователь: 

public class User implements Serializable
{
    protected Date birthDate;

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

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

Этот класс неполный, поэтому не удивляйтесь, если пропустите serialVersionUID и другие стандартные вещи, я просто обеспокоен дырой в безопасности birthDate.

Теперь, согласно отчету findbugs, поскольку я возвращаю ссылку на изменяемый объект, это представляет потенциальную угрозу безопасности. На практике, насколько это действительно важно?

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

Полагаю, я до сих пор не понимаю, в чем здесь проблема. Должен ли я передать long и установить дату с этого?

Walter

Ответы [ 4 ]

34 голосов
/ 14 ноября 2009

Я думаю, что ключ здесь , если :

Если доступ к экземплярам осуществляется с помощью ненадежного кода, и непроверенные изменения изменяемого объекта могут поставить под угрозу безопасность или другие важные свойства, вам нужно будет сделать что-то другое.

Другими словами, если вы хотели неизменный объект (т. Е. У вас не было метода setBirthdate()), ваш код был бы неправильным, потому что кто-то мог написать: 

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

Так что вы, вероятно, захотите следующее: 

public Date getBirthDate()
{return new Date(birthDate.getTime());}  // essentially a clone
5 голосов
/ 14 ноября 2009

Да, я бы не стал называть это проблемой "безопасности" как таковой ... Я имею в виду, какой злоумышленник именно собирается писать вредоносный код против ваших объектов? Реальная проблема заключается в том, что вы, скорее всего, сами запутаетесь, случайно позвонив getBirthDate и изменив результат.

По этой причине обычным является использование в качестве получателя клонируемых изменяемых объектов типа Date для возврата, когда вы используете их в качестве типов значений.

(Вы также можете утверждать, что Java Date не должен был быть изменяемым, но сейчас с этим ничего не поделаешь.)

2 голосов
/ 06 августа 2015

Добавляя к хорошему ответу Мэтта Солнита, я столкнулся с той же проблемой при установке атрибута, поэтому я сделал то же самое: 

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

Работа в порядке!

2 голосов
/ 14 ноября 2009

Ну, я бы сказал, что все зависит. Существуют и другие не связанные с безопасностью причины возврата неизменяемых объектов, поскольку это может также привести к некоторым трудно обнаруживаемым ошибкам в вашем коде, если объект используется не по назначению.

Будет ли доступ к классу с помощью ненадежного кода и / или данных? Если это так, вам необходимо иметь четкое представление о том, в чем заключается ответственность вашего приложения в отношении проверки входных данных.

Кроме того, какова природа приложения? Если это, например, внешне доступная сетевая служба, тогда ввод почти наверняка будет считаться потенциально вредоносным. Однако если это приложение, запускаемое локально без привилегий, которое получает данные из надежного источника, то, вероятно, не стоит беспокоиться.

...