无法解决 Log Forging Fortify 问题

Posted 2023-02-19

【中文标题】无法解决 Log Forging Fortify 问题

【英文标题】：Can't resolve Log Forging Fortify issue

【发布时间】：2015-08-12 18:42:19

【问题描述】：

我在解决 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 没有影响。

任何帮助将不胜感激！

【问题讨论】：

ParseExceptions 可以包含该值作为getMessage 返回的字符串的一部分，因此我怀疑在getMessage 返回的值上调用cleanLogString 将解决其中一个问题。另一个问题发生在LOGGER.info 电话上？

@Neil Smithline 感谢您的回复，但添加 cleanLogString(e.getMessage()) 并没有解决 LOGGER.warn() 语句的问题。我将此更改添加到问题中，以免引起任何其他混乱。没错，另一个问题是 LOGGER.info 语句。

我的下一个猜测是，Fortify 没有将 cleanLogString 函数识别为清理受污染数据的东西。我不确定为什么它会在某些地方识别它，但在其他地方却不能。你在某个地方有自定义规则吗？

@NeilSmithline，很遗憾我无法访问 Fortify 规则。我的领导告诉我，这些规则仍在制定中。一旦规则变得更加稳定，我将尝试进一步挖掘规则。谢谢你的想法。

Fortify 有误报，如果没有自定义规则，您将无法摆脱这些误报。你能把这些标记为不是问题然后忘记它们吗？

【参考方案1】：

使用reflect 或try-catch。 它很容易作弊强化。

【参考方案2】：

最初写这个问题时，我们的团队使用的是 log4j v1.2.8，但是我们注意到升级到 log4j v2.6.2 后所有的日志伪造问题都消失了。

升级 log4j 版本后，Fortify 日志伪造问题应该会消失。形成上述问题的 cleanLogString() 方法也是不必要的。例如：

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

【参考方案3】：

可以使用 fortify Java 注释告诉 Fortify 从清理函数返回的数据现在是安全的。

在查看我的日志伪造问题时，我收到了通过 Web API 输入的字符串，因此我的字符串上有 XSS 和 WEB 标志。我试图找到只会删除这些标志的注释，但找不到任何方法来删除 WEB 标志。我找到的唯一文档是Samples/advanced/javaAnnotation 目录。

由于我的清理方法确实清理了字符串，因此我选择删除所有标志。不过，这可能是个问题，因为它可能会隐藏侵犯隐私的行为。

@FortifyValidate("return")
private String sanitizeString(String taintedString) 
    return doSomethingWithTheString(taintedString);

【讨论】：

在哪个库@FortifyValidate注解可用？

它以 jar 的形式出现在 fortify 安装目录中。

【参考方案4】：

我知道我遇到过这样的情况，即我的应用程序的复杂性会阻止任何恶意输入按预期工作； 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)";
    

【讨论】：

嘿，感谢@DaveC 的回答，但不幸的是，我的小组正在使用 Artifactory 作为我们的 maven 依赖项，并且 ESAPI jar 未授权我们使用。如果我们能设法获得访问权限，我会告诉你它是如何工作的。