У меня возникла проблема с фиксацией проблемы с журнальной кузницей в Fortify. Проблема «записывает неутвержденный вход пользователя в журнал» поднимается из обоих вызовов журнала в методе getLongFromTimestamp().Не удается решить проблему с журналом Forge Fortify
public long getLongFromTimestamp(final String value) {
LOGGER.info("getLongFromTimestamp(" + cleanLogString(value) + ")");
long longVal = 0;
Date tempDate = null;
try {
tempDate = new SimpleDateFormat(FORMAT_YYYYMMDDHHMMSS, Locale.US).parse(value);
} catch (ParseException e) {
LOGGER.warn("Failed to convert to Date: " + cleanLogString(value) + " Exception: " + cleanLogString(e.getMessage()));
throw new Exception(e);
}
if (tempDate != null) {
longVal = tempDate.getTime();
}
return longVal;
}
private cleanLogString(String logString) {
String clean = logString.replaceAll("[^A-Za-z0-9]", "");
if(!logString.equals(clean)) {
clean += " (CLEANED)";
}
return clean;
}
Метод cleanLogString() закрепил другие вопросы журнала Ковка FORTIFY в моем проекте, однако это не оказывает никакого влияния на выше 2.
Любая помощь будет оценена!
ParseExceptions может содержать значение как часть строки, возвращаемой 'getMessage', поэтому я подозреваю, что вызов' cleanLogString' на значение, возвращаемое 'getMessage', исправит одну из проблем. Другая проблема возникает в вызове 'LOGGER.info'? –
@Neil Smithline благодарит за ответ, но добавление cleanLogString (e.getMessage()) не решило проблему для оператора LOGGER.warn(). Я добавил это изменение в вопрос, чтобы не вызвать какой-либо другой путаницы. И правильно, другая проблема связана с оператором LOGGER.info. –
Мое следующее предположение заключалось в том, что Fortify не признает функцию 'cleanLogString' как нечто, что санирует испорченные данные. Я не уверен, почему он узнает его в некоторых местах, но не в других. У вас есть собственное правило для этого где-то? –