MALICIOUS_CODE EI_EXPOSE_REP Средний

Я запускаю 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 и установить дату из этого?

Вальтер

Ответ 1

Я думаю, что ключевым моментом является if:

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

Иными словами, , если вам нужен неизменяемый объект (т.е. у вас не был метод setBirthdate()), ваш код будет неправильным, потому что кто-то может написать:

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

Итак, вы, вероятно, захотите вместо этого:

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Прекрасно работайте!