我无法在Fortify中修复Log Forging问题。问题是“将未经验证的用户输入写入日志”,这是来自getLongFromTimestamp()方法中的两个日志记录调用。
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()方法修复了我的项目中的其他Log Forging Fortify问题,但它对上面的2没有影响。
任何帮助将不胜感激!
答案 0 :(得分:2)
可以使用强化Java注释告诉Fortify从清理功能返回的数据现在是安全的。
在查看我的日志伪造问题时,我通过Web API获得了字符串,因此我的字符串上有标记XSS
和WEB
。我试图找到只删除这些标志的注释,但找不到任何方法来删除WEB
标志。我找到的唯一文档是Samples/advanced/javaAnnotation
目录。
由于我的卫生方法会清理字符串,因此我选择删除所有标记。这可能是个问题,因为它可能会隐藏隐私侵权行为。
@FortifyValidate("return")
private String sanitizeString(String taintedString) {
return doSomethingWithTheString(taintedString);
}
答案 1 :(得分:1)
最初编写这个问题时,我们的团队正在使用log4j v1.2.8,但是我们注意到升级到log4j v2.6.2后所有的日志伪造问题都消失了。
一旦log4j版本升级,Fortify日志锻造问题就会消失。形成上面问题的cleanLogString()方法也是不必要的。例如:
LOGGER.info("getLongFromTimestamp(" + value + ")");
答案 2 :(得分: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)";
}
}
答案 3 :(得分:-3)
使用reflect
或try-catch
。
它很容易作弊强化。