Отчеты о сканировании Fortify SCA Проблема создания журнала при чтении переменных среды

Я использовал System.getenv("envVariableName"), и у меня возникла проблема с ковкой журнала. Я даже пробовал кодировать возвращенную строку с помощью кодировщика ESAPI, но это не помогло.

Мой фрагмент кода:

String envValue = encode(System.getenv("envVariableName"));

String encode(String message) {
        if (message != null) {
            String clean = message.replace('\n', '_').replace('\r', '_');
            if (ESAPI.securityConfiguration().getLogEncodingRequired()) {
                clean = ESAPI.encoder().encodeForHTML(message);
                if (!message.equals(clean)) {
                    clean += " (Encoded)";
                }
            }
            return clean;
        }
        return message;
    }

Любые предложения относительно того, что мне не хватает, будут оценены.


logging environment-variables fortify esapi log-forging
person Aman Agarwal    schedule 26.04.2019    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Fortify (как минимум) распознал кодировщики ESAPI как удаляющие «веб-флаги» заражения, но я думаю, что это было только в контексте правил Fortify XSS. Я не думаю, что они сделали это в контексте создания журналов, хотя я почти уверен, что они признают ведение журнала ESAPI как обеспечивающее «безопасное ведение журнала».

Если я понимаю ваше желание здесь, вы не просто хотите пометить этот конкретный экземпляр как «Не проблема» и подавить его, но вместо этого вы хотите, чтобы он в первую очередь не распознавал этот шаблон как экземпляры подделки журналов. К сожалению, вы не можете изменить правила HP (теперь Microfocus) Fortify. (Их пакеты правил даже зашифрованы, поэтому, если не выполнять AWB под отладчиком, вы даже не можете просматривать их правила.) Если вы решите, что «переменные среды» являются «доверенными», я полагаю, вы могли бы настроить и применить AWB набор фильтров, который игнорирует экземпляры, в которых единственным флагом загрязнения на приемнике является «переменная среды». (Или примените его только к этой категории ковки журналов.)

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

Надеюсь, это поможет.

person Kevin W. Wall    schedule 05.05.2019

arrow_upward
0
arrow_downward

Строка, назначенная Fortify, действительно находится в String envValue = encode (System.getenv ("envVariableName")) ;?

Проблемы с подделкой журнала обычно возникают, когда вы записываете некоторую информацию в журнал из ненадежного источника: https://vulncat.fortify.com/en/detail?id=desc.dataflow.java.log_forging#C%23%2FVB.NET%2FASP.NET

person Raphael Hagi    schedule 26.04.2019
comment
Да, потому что Fortify сообщает о проблеме создания журнала даже в случае поступления данных в приложение из ненадежного источника; в этом случае значения считываются из переменных среды. Во всяком случае, я тоже сталкиваюсь с этой проблемой с журналами. Если у вас есть решение для этого, оно все равно будет полезно. - person Aman Agarwal; 27.04.2019
comment
Если вы действительно доверяете этому источнику, вы можете отметить это как ложное срабатывание. Но проверьте эту ветку: stackoverflow.com/ questions / 30537359 / - person Raphael Hagi; 29.04.2019

arrow_upward
0
arrow_downward

Вопрос: Если вы уже используете ESAPI, то почему бы просто не использовать ведение журнала ESAPI, поскольку оно обеспечивает «безопасное ведение журнала», как при защите от атак с подделкой журналов?

person Kevin W. Wall    schedule 29.04.2019
comment
Я не могу использовать ведение журнала EASPI по требованию. И, как я уже упоминал, я ищу решение, в котором Fortify мог бы видеть входные данные как надежные. У вас есть предложения по этому поводу? - person Aman Agarwal; 29.04.2019
comment
Отвечаю как новый ответ ниже, потому что мой ответ слишком длинный. - person Kevin W. Wall; 05.05.2019