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

18

Привет, я получаю нарушение, как показано ниже:

  

Уязвимость вредоносного кода. Может отображаться внутреннее представление   возвращение ссылки на изменяемый объект

в моем коде я написал вот так

public String[] chkBox() {
    return chkBox;
}

Как мы можем его решить.

    
задан jayavardhan 21.01.2012 в 07:13
источник

2 ответа

32

Как указано в сообщении об ошибке, вы возвращаете внутреннее состояние (chkBox - скорее всего - часть внутреннего состояния объекта, даже если вы не показываете его определение)

Это может вызвать проблемы, если вы - например - do

String[] box = obj.chkBox();
box[0] = null;

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

То, что вы, скорее всего, захотите сделать, чтобы исправить это, - это простой

return (String[])chkBox.clone();

, который возвращает копию массива вместо фактического массива.

    
ответ дан Joachim Isaksson 21.01.2012 в 07:31
источник
  • в вышеприведенном решении, мы создадим новый объект String [] каждый раз, когда получим доступ к нему через clone (). Мне просто нужно сравнить (а не создавать новый объект), у кого-нибудь есть лучшее решение? –  Raj Trivedi 30.06.2015 в 14:30
  • Я не понимаю, как это полезно, кроме как победить Findbugs. Скопированный массив все еще имеет ссылки на строки, которые содержат состояние obj. –  David 29.02.2016 в 15:05
  • @David Строки доступны только для чтения, поэтому они не могут мутировать. –  Joachim Isaksson 29.02.2016 в 15:06
  • Кроме того, если chkBox был getChkBox, я ожидал бы получить ссылку на базовый объект. Тогда геттеру нужно будет вернуть ссылку на абстрактный класс, не так ли? –  David 29.02.2016 в 15:06
  • Это имеет смысл Йоахим, спасибо. Я рассматриваю эту проблему правильно на этой второй. У меня есть класс, который написал кто-то другой, который возвращает DomainSpecificClass []. Clone () в getters. –  David 29.02.2016 в 15:08
9

Предположим следующее:

  1. Ваш класс делает что-то, что имеет значение с точки зрения безопасности или конфиденциальности, и что состояние chkbox каким-то образом используется в классах для реализации его механизмов конфиденциальности / безопасности.

  2. Метод chkBox() может быть вызван некоторым кодом, которому не доверяют.

Теперь рассмотрим этот код:

// ... in an untrusted method ...

Foo foo = ... 
String[] mwahaha = foo.chkBox();
mwahaha[0] = "Gotcha!"; // ... this changes the effective state of 'Foo'

Вернув ссылку на фактический массив, который представляет chkbox , вы разрешаете код, внешний для класса Foo , для доступа и изменения его состояния.

Это плохо с точки зрения дизайна (это называется «негерметичной абстракцией»). Однако, если этот класс используется в контексте, где также может быть ненадежный код, это (метод chkBox() ) является дырой безопасности потенциал . Это сообщение о нарушении.

(Конечно, проверка кода не имеет возможности узнать, действительно ли этот конкретный класс действительно критически важна. Это вам нужно понять. То, что он на самом деле говорит вам, это «Привет Посмотрите здесь! Это подозрительно! )

Исправление зависит от того, критичен ли этот код (или даже вся библиотека или приложение) критически важна ... или код критически важны для некоторых будущих развертываний. Если это ложная тревога, вы можете просто подавить нарушение; т. е. отметьте его так, чтобы контрольная сумма была проигнорирована. Если это реальная проблема (или может стать реальной проблемой), то либо верните копию массива:

    return (String[]) chkBox.clone();

Но ясно, что при клонировании массива каждый раз вы вызываете chkBox . Кроме того, вы можете изменить метод chkBox , чтобы вернуть выбранный элемент массива:

    public String chkBox(int i) {
       return chkBox[i];
    }

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

    
ответ дан Stephen C 21.01.2012 в 08:16
источник
  • Я все еще удивляюсь, почему сонар сообщает об этой проблеме только для массивов, а не, например, для списков или какой-либо другой изменяемой структуры данных. Есть ли еще больше, возможно, из-за того, как массивы хранятся в памяти? –  tobias_k 13.10.2014 в 16:59
  • «Есть ли еще больше, возможно, из-за того, как массивы хранятся в памяти?» - Насколько мне известно, нет. –  Stephen C 14.10.2014 в 00:29
  • Реальное различие заключается в том, что с помощью массива невозможно запретить кому-либо ссылку на массив ссылаться на содержимое. С типами объектов доступ к нему опосредуется API-интерфейсом (если API правильно выбран), что затрудняет различие между безопасными и небезопасными способами использования. (Если контролер ошибок «воскликнул волка» слишком часто, он не будет использоваться.) –  Stephen C 14.10.2014 в 00:32