我最近正在研讨Java文件传输，碰到了一些风趣的问题。这些问题是我在看到一篇博客中的几个示例代码中发现的。这篇文章描述了用Java履行SCP指令的体系，运用的是盛行的 *** ch库。当我通读整个代码之后，我很快就发现了他们代码中的一些问题。
  // exec 'scp -f rfile' remotely
        String command = "scp -f " + from;
        Channel channel = session.openChannel("exec");
        ((ChannelExec) channel).setCommand(command);
 
        // get I/O streams for remote scp
        OutputStream out = channel.getOutputStream();
        InputStream in = channel.getInputStream();
 
        channel.connect();
假如你之前看到过怎么安全的将参数传递为指令行，那你就会知道示例代码中的这种传递 *** 是不安全的。第二行增加恣意字符串到指令结束，而没有进行任何方式的整理，这种场景毫无疑问是会导致sql注入的。
布景信息
在深化发掘这个缝隙之前，有一些重要的布景信息咱们需求了解一下：
这条指令在服务端运转。SCP客户端是经过SSH登录到长途服务器（上面代码中有履行通道）来在服务器端履行SCP指令的。
由于运转在服务端，我并没有找到Java中好用的库来转义指令。我查了许多材料，大部分都是引荐运用Java的Process或许runtime类，但是这些只适用于本地运转的进程，在服务端是无法运转的。
发现1
在上面的示例代码中，指令应该是像下面这样的：
scp -f /some/user/provided/path
不过，由于途径在任何地方都没有进行转义或约束，所以途径也能够很轻易地被修改为下面这样：
# path = '/; touch /tmp/foo'
scp -f /; touch /tmp/foo
这样一来，就会先履行scp -f指令，然后再履行touch /tmp/foo指令。进一步研讨之后，我发现这段代码是直接从 *** ch的源码中复制粘贴过来的。这就标明这段示例代码也存在相同的缝隙。我向这个项意图保护者陈述了这个问题，我想他们要么修正这个问题，要么可能不理睬我，不过状况并不是这样的。
发现2
在我陈述了 *** ch中这个缝隙的第二天，我收到了一个回复。当我在研讨我的开始陈述时，该项意图保护者注意到OpenSSH的SCP指令和Rsync也存在相同的问题。比方履行如下指令：
scp /tmp/foo user@remotehost:/tmp/bar;touch /tmp/foo
这将会在长途服务器中履行touch /tmp/foo指令，即便参数在客户端履行了正确的转义也没用。这是由于在应用程序层面对此进行转义并不会导致在长途运转也进行转义。关于上面的比方，长途主机上的服务器会履行scp -f /tmp/bar; touch /tmp/foo指令。
Rsync的问题也相似，在向他们陈述了这个缝隙之后，他们向我介绍了一个标志（-s/–protect-args），这个标志能避免缝隙运用。
发现3
环绕这个问题，我跟OpenSSH的保护人员进行了沟通交流，他们说了几个要害点：
· 这个问题众所周知，但没有得到注重，也没有杰出的文档记载。
· SCP这个协议现已“完全被玩坏了”。
· 根据SFTP作为替代品的SCP2，从未施行。
· 更改此问题就会损坏兼容性。
· 由于支撑多种shell，他们以为在这种状况下，转义shell参数是不可能的。
作为一名很多运用SCP指令的开发者，得知SCP指令是无法修正的让我感觉到十分惊奇。我觉得他们有必要供给关于此问题的官方文档，并告知用户更好的挑选（比方SFTP或许Rsync），由于我看到的库和代码片段中没有考虑到这一点。
总结
关于个人运用，Rsync和SCP都没问题，不过关于任何运用不信赖来历或许用户供给的途径/文件名时，切记要运用STFP或许运用rsync -s。除非途径在作为指令行参数再次转义前得到充沛的转义，不然不要信赖任何来自非信赖用户输入的SCP指令。