Fortify不信任Java系统属性

我正在尝试使用

ProcessBuilder

派生一个进程：

String classpath = System.getProperty("java.class.path");
String[] javaCmd = {"java", "-cp", classpath, ...};

ProcessBuilder builder = new ProcessBuilder();
// ...
builder.command(javaCmd)
// ...

Fortify报告了一个命令注入漏洞，因为

javaCmd

是“由不受信任的数据构建的”。Fortify是正确的，因为系统属性是可变的：

System.setProperty（）

，这使得在运行系统命令时使用它们很危险

我没有找到

System.getProperty（“java.class.path”）

的替代方案，我想知道是否有人有想法

---

谢谢

整个命令是一个巨大的步行漏洞。或者不是。安全不是黑白的。它是灰色的。这段代码不是完全白色的，但它是浅灰色的（也就是说：它为攻击者提供了一些路由，但这些路由在正确配置的系统上通常不可用，并且“进入”的几种方式通常被视为提供了更可怕和直接的路由，这使得开放的攻击表面大多没有意义）

TL；DR：警告太愚蠢了，请告诉fortify忽略此警告，另外，您的安全流程可能需要更新。此外，此代码很可能不会真正执行您想要的操作。不幸的是，没有一种简单的方法可以编写出你想要的代码；为带来坏消息而道歉

更详细地说：

特别是，“我将通过不完全遵循一般分析来处理每一个强化警告，而只是通过编写我能想到的最接近的东西来消除它”，这是一个很好的、很好的方式，可以认为您已经编写了安全代码，但实际上并没有这样做

你必须理解fortify的意图。然后，您必须弄清楚攻击面实际上是什么，或者不接受它（因此更改/删除公开它的所有代码），或者接受它，并记录该攻击面是无关的。在这种情况下，第二个选项（接受它、记录它，然后继续）对于几乎所有可以想象的场景来说都是正确的选择

在此特定实例中，您编写的代码有两个不同的攻击面：

磁盘访问会导致被破坏 您正在运行

java

。就这样。相对路径。您不知道将运行什么java，而且您肯定无法保证它与您当前的JVM来自同一个java。它很可能是恶意脚本。这需要攻击者找到一种方法将该脚本放入路径上的文件夹中。对于非root用户，

通常位于路径上，并且首先位于路径上，因此，如果这是例如服务器和攻击者可以设法使服务器将文件保存在其自己的目录中，boom。好了。您的服务器现在已受损

防御没有警告这是错误的；一般来说，相对路径只是一个坏主意，如果不是出于安全原因，那么是出于稳定性原因：这在很多服务器上都不起作用。不幸的是，基本上不可能以独立于平台和部署的方式从第一个JVM可靠地调用第二个JVM。这就是为什么真正的解决方案通常是直接避免它，或者设置显式的OS绑定脚本来解决这个问题（然后使用绝对路径运行脚本）

损害系统属性 是的，如果sonme攻击者成功诱使您的JVM运行

System.setProperty（“java.class.path”）

，则它们可能会危害您的机器但这完全是荒谬的。你应该马上忘记这个攻击面，因为它是零长度的

运行

System.setProperty（untrustedUserInput，someOtherUntrustedUserInput）的可能性有多大？继续，搜索您的代码库。是。。不太可能在那里。某些攻击者可能会强制您的服务器运行所需的任何字节码（这需要一个公开的安全漏洞，例如存在缓冲区溢出的PNG解析器或其他漏洞；这意味着要么是一个0天的攻击者，要么是你确保及时修补服务器的进程被破坏，在这种情况下，你会遇到更大的问题）。如果攻击者能够做到这一点，他们可以设置属性，是的

他们也可以直接上
ProcessBuilder
任何需要的地方，因此，这一点完全没有意义。你将注意力集中在巨山旁边的岩石上，并将其定为陆地上的最高点

因此，总结一下：在本例中，强化警告是愚蠢的，应该完全忽略。但是，这段代码肯定会打开一些攻击面；但不是特别大的攻击面。特别是，如果没有人可以登录到此框或写入运行此JVM进程目录的用户（他们当然不应该这样做，或者编辑路径！）-你很好。如果不是这样，你就有更大的问题

这就是安全工作原理：你写下这些东西，并在整个过程中不断检查（不仅仅是代码、文档、检查，每两年对系统操作人员进行一次访谈，检查他们是否阅读了文档并遵守了指令）.你不能关闭每一个攻击面。你只能让他们意识到并确保他们不会被滥用

我不认为有一种创造性的方法可以让fortify闭嘴（也许通过反射调用processbuilder，fortify可能无法解决），但它所做的只是降低安全性。这里唯一正确的解决方案是完全放弃fortify（这可能有点激烈），或者如何使用它：将它找到的地方作为一个非详尽的代码列表进行分析。而不是“这是一个我需要修复的东西列表，然后我的代码是安全的”。这种分析应该足够了，因此，粘贴适当的注释或注释，或者以任何方式进行强化你已经手动接受了这个，它不应该再告诉你了

真正的解决办法
<