强化路径操作错误 [英] Fortify Path Manipulation error

问题描述

Fority Scan 报告了以下代码段中的路径操纵"安全问题

Fority Scan reported "Path Manipulation" security issues in following snippet

String filePath = getFilePath(fileLocation, fileName);
final File file = new File(filePath);
LOGGER.info("Saving report at : " + filePath);
BufferedWriter fileWriter = new BufferedWriter(new FileWriter(file));
fileWriter.write(fileContent);

所以我正在检查 fileLocation 中列入黑名单的字符并抛出异常，但 Fortify 仍在抛出异常.

so i am checking for blacklisted characters in fileLocation and throwing exception, still the Fortify is throwing the exception.

try {
    String filePath = getFilePath(fileLocation, fileName);
    if (isSecurePath(filePath)) {
      final File file = new File(filePath);
      LOGGER.info("Saving report at : " + filePath);
      BufferedWriter  fileWriter = new BufferedWriter(new FileWriter(file));
      fileWriter.write(fileContent);
    } else {
      throw new Exception("Security Issue. File Path has blacklisted characters");
    }

} catch (final Exception e) {
    LOGGER.error("Unable to prepare mail attachment : ", e);
    message = "Mail cannot be send, Unable to prepare mail attachment";
}


private boolean isSecurePath(String filePath) {
    String[] blackListChars = {".."};
    return (StringUtils.indexOfAny(filePath, blackListChars)< 0);
}

我应该忽略扫描报告还是对此的正确解决方法是什么?

should i ignore the scan report or what would be the correct fix for this?

推荐答案

首先，SCA 是一个静态分析工具，因此无法检查您的自定义验证以确定它是否正常工作，因为这是一个动态工具，例如正如 WebInspect 设计的那样.

Firstly SCA is a static analysis tool, so can't check your custom validation to determine whether it works correctly or not, as this is something a dynamic tool such as WebInspect is designed to do.

其次，黑名单是保护任何事物的一种糟糕方式，白名单是更安全的方法，并且您提到将黑名单验证到标准输出的事实会引诱攻击者.这是因为您必须考虑每一种可能的攻击方式，包括可能尚未发现的方式，因此很容易在软件发布之前就过时了.

Secondly, blacklisting is a poor way of securing anything, whitelisting is the far more secure method and the fact you're mentioning blacklisting validation to stdout would entice an attacker. This is because you have to account for every single possible way of being attacked, including ways that may not have been discovered yet, so could easily become out of date before the software is even released.

第三，这绝对不足以阻止路径操作，因为您只考虑了寻找相对路径，更具体地说是当前目录上方的相对路径的人.

Thirdly, this definitely wouldn't suffice against stopping path manipulation since you're only accounting for people looking for relative paths and more specifically relative paths above the current directory.

您无法检测是否有人指定了完整路径，或者是否有人进入了一个目录，该目录是指向单独目录的符号链接，以及其他几种可能的替代攻击.

There's no way you have of detecting if somebody specifies a full path, or if somebody goes to a directory that's a symbolic link to a separate directory altogether, along with a couple of other possible alternative attacks.

理想情况下，您应该遵循 SCA 显示的建议，并拥有非常具体的允许路径 &文件名.如果这是不可能的，请使用白名单技术指定唯一允许的字符，然后进行验证以指定它不是例如 SMB 共享或指定的完整路径.如果它没有根据用户应该指定的规范进行验证，则拒绝它.

Ideally you should follow the recommendations shown by SCA and have a very specific allowed paths & filenames. Where this isn't possible, use a whitelisting technique to specify the only characters that are allowed, and then validate to specify that it's not for example a SMB share or a full path specified. If it doesn't validate according to the specification of what users should be specifying, reject it.

这样做会解决问题本身，但 SCA 可能仍会在结果中显示问题(同样是由于静态分析与动态分析之间的差异).这可以通过对其进行审核或为验证问题的函数创建自定义清理规则来解决.

Doing this will get rid of the issue itself, but SCA will likely still show the issue in the results (again due to the differences between static vs dynamic analysis). This can be worked around by auditing it as such or creating a custom cleanse rule for the function that validates the issue.

这篇关于强化路径操作错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！