文件路径名存在问题，可能是字符损坏 [英] Issue with filepath name, possible corrupt characters
问题描述
Perl和html，Linux上的CGI。
文件路径名的问题，在表单字段中传递给服务器上的CGI。
问题出在Linux文件路径，而不是PC端。
Perl and html, CGI on Linux. Issue with file path name, being passed in a form field, to a CGI on server. The issue is with the Linux file path, not the PC side.
我正在使用2个程序，
1）年前编写的程序，在perl程序中生成的动态html，并以表格形式呈现给用户。我通过插入所需的代码进行了修改，以允许用户从其PC中选择要放置在Linux机器上的文件。
I am using 2 programs, 1) program written years ago, dynamic html generated in a perl program, and presented to the user as a form. I modified by inserting the needed code to allow a the user to select a file from their PC, to be placed on the Linux machine.
因为该程序已经知道linux端所需的文件路径，所以我将此文件路径以隐藏的形式传递给程序2。
Because this program already knew the filepath, needed on the linux side, I pass this filepath in a hidden form field, to program 2.
2）Linux端的CGI程序，在发布（1）上的表单时运行。
2) CGI program on Linux side, to run when form on (1) is posted.
奇怪的问题。
我传递的文件路径有一个非常奇怪的问题。
我可以使用
Strange issue. The filepath that I pass, has a very strange issue. I can extract it using
my $filepath = $query->param("serverfpath");
以上内容确实用看起来完全正确的路径填充了$ filepath。
但是它失败了，并且不会以某种方式将我带到文件打开错误块，而是使对CGI脚本的调用产生了错误。
The above does populate $filepath with what looks like exactly the correct path.
But it fails, and not in a way that takes me to the file open error block, but such that the call to the CGI script gives an error.
但是，如果我使用完全相同的字符串填充$ filepath，则通过硬编码可以正常工作，并且我的文件成功上传。
However, if I populate $filepath with EXACTLY the same string, via hard coding it, it works, and my file successfully uploads.
例如：
$fpath1 = $query->param("serverfpath");
$fpath2 = "/opt/webhost/ims/DOCURVC/data"
比较$ fpath1和$ fpath2的值表明它们完全相等。
$ fpath1和$ fpath2的长度检查显示它们的长度完全相同。
A comparison of $fpath1 and $fpath2 reveals that they are exactly equal. A length check of $fpath1 and $fpath2 reveals that they are exactly the same length.
我尝试了多种清除$ fpath1中数据的方法。
我砍了。
我删除了所有非标准字符。
I have tried many methods of cleaning the data in $fpath1. I chomp it. I remove any non standard characters.
$fpath1 =~ s/[^A-Za-z0-9\-\.\/]//g;
这：
my $safe_filepath_characters = "a-zA-Z0-9_.-/";
$fpath1 =~ s/[^$safe_filepath_characters]//g;
但是无论我做什么，使用$ fpath1都会导致错误，而使用$ fpath2则可以。
But no matter what I do, using $fpath1 causes an error, using $fpath2 works.
$ fpath1中的数据可能有问题，这将导致它成功地与$ fpath2比较，但不相等，在视觉上看起来完全相等，显示为具有
What could be wrong with the data in the $fpath1, that would cause it to successfully compare to $fpath2, yet not be equal, visually look exactly equal, show as having the exact same length, but not work the same?
对于下面的文件打开块。
For the below file open block.
$upload_dir = $fpath1
导致CGI完全加载失败，就好像它找不到CGI（我知道有时是由于CGI脚本中的语法错误引起的。）
causes complete failure of CGI to load, as if it can not find the CGI (which I know is sometimes caused by syntax error in the CGI script).
$uplaod_dir = $fpath2
我成功上传了文件
$uplaod_dir = ""
对cgi的调用确实不会失败，如果期望的话，它将执行下面的else块。
The call to the cgi does not fail, it executes the else block of the below if, as expected.
这是文件打开块：
if (open ( UPLOADFILE, ">$upload_dir/$filename" ))
{
binmode UPLOADFILE;
while ( <$upload_filehandle> )
{
print UPLOADFILE;
}
close UPLOADFILE;
$msgstr="Done with Upload: upload_dir=$upload_dir filename=$filename";
}
else
{
$msgstr="ERROR opening for upload: upload_dir=$upload_dir filename=$filename";
}
我应该在$ fpath1上执行哪些其他测试，以找出原因？与硬编码的等效$ fpath2
What other tests should I be performing on $fpath1, to find out why it does not work the same as its hard-coded equivalent $fpath2
的工作方式不同我确实尝试过从$ fpath2到$ fpath1一次字符替换。
即使使用单个字符执行此操作，也会导致$ fpath1与$ fpath2出现相同的错误，尽管该字符看起来完全相同。
I did try character replacement, a single character at a time, from $fpath2 to $fpath1. Even doing this with a single character, caused $fpath1 to have the same error as $fpath2, although the character looked exactly the same.
推荐答案
您的CGI可能是在 -T （污点模式）开关（例如，＃！/ usr / bin / perl -T ）？如果是这样，则不允许将来自不受信任来源（例如用户输入，URI和表单字段）的任何值用于系统操作，例如 open ，直到使用正则表达式捕获将其取消污染为止。请注意，使用 s / // 对其进行原位修改将不会不会取消该值。
Is your CGI perhaps running perl with the -T (taint mode) switch (e.g., #!/usr/bin/perl -T)? If so, any value coming from untrusted sources (such as user input, URIs, and form fields) is not allowed to be used in system operations, such as open, until it has been untainted by using a regex capture. Note that using s/// to modify it in-place will not untaint the value.
$fpath1 =~ /^([A-Za-z0-9\-\.\/]*)$/;
$fpath1 = $1;
die "Illegal character in fpath1" unless defined $fpath1;
如果污染模式是您的问题，应该可以工作。
should work if taint mode is your issue.
这篇关于文件路径名存在问题，可能是字符损坏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
