2015-05-29 2 views
1

У меня возникла проблема с фиксацией проблемы с журнальной кузницей в 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.

Любая помощь будет оценена!

+0

ParseExceptions может содержать значение как часть строки, возвращаемой 'getMessage', поэтому я подозреваю, что вызов' cleanLogString' на значение, возвращаемое 'getMessage', исправит одну из проблем. Другая проблема возникает в вызове 'LOGGER.info'? –

+0

@Neil Smithline благодарит за ответ, но добавление cleanLogString (e.getMessage()) не решило проблему для оператора LOGGER.warn(). Я добавил это изменение в вопрос, чтобы не вызвать какой-либо другой путаницы. И правильно, другая проблема связана с оператором LOGGER.info. –

+0

Мое следующее предположение заключалось в том, что Fortify не признает функцию 'cleanLogString' как нечто, что санирует испорченные данные. Я не уверен, почему он узнает его в некоторых местах, но не в других. У вас есть собственное правило для этого где-то? –

ответ

0

Первоначально, когда этот вопрос был написан наша команда использует log4j v1.2.8, однако мы заметили, что все вопросы журнала ковки исчезли после обновления до log4j v2.6.2.

После обновления версии log4j проблемы с подделкой журнала Fortify должны исчезнуть. Метод cleanLogString() формирует вопрос, указанный выше, также не нужен. Например:

LOGGER.info("getLongFromTimestamp(" + value + ")"); 
0

Я знаю, что столкнулся с ситуациями, когда сложность моего приложения прекратила бы вредоносный ввод от работы по назначению; Fortify не считает это безопасным. Бьюсь об заклад, вы сталкиваетесь с тем же.

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

http://www.jtmelton.com/2010/09/21/preventing-log-forging-in-java/

// ensure no CRLF injection into logs for forging records 
String clean = message.replace('\n', '_').replace('\r', '_'); 
if (ESAPI.securityConfiguration().getLogEncodingRequired()) { 
    clean = ESAPI.encoder().encodeForHTML(message); 
    if (!message.equals(clean)) { 
     clean += " (Encoded)"; 
    } 
} 
+0

Эй, спасибо за ответ @DaveC, но, к сожалению, моя группа использует Artifactory для наших зависимостей maven, а банкомат ESAPI не разрешен для нашего использования. Я дам вам знать, как это работает, если мы сможем получить доступ. –

0

Можно использовать подкрепиться Java аннотаций сказать Укрепите, что возвращаемые данные из функции дезинфицирующей теперь безопасен.

При взгляде на мои проблемы с подделкой журнала у меня были строки, входящие в веб-API, и, таким образом, на моих строках были флаги XSS и WEB. Я попытался найти аннотации, которые только удалили бы эти флаги, но не смогли найти способ удалить флаг WEB. Единственная документация, которую я нашел, - это каталог Samples/advanced/javaAnnotation.

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

@FortifyValidate("return") 
private String sanitizeString(String taintedString) { 
    return doSomethingWithTheString(taintedString); 
} 
+1

В какой библиотеке имеется аннотация '' '@ FortifyValidate''? –

+0

Он поставляется в виде банки в каталоге установки fortify. –

-2

Использование reflect или try-catch. Его легко обмануть укреплять.

Смежные вопросы