用户备份文件的目录位于他们可以访问和上传的目录中。
如果他们得到正确的命名方案并导致系统故意使系统尝试恢复最后5个左右的备份，他们可能会使用绝对路径gzip文件（例如{）将他们想要的文件放到服务器上。 {1}}或者可能是这种情况。
我可以执行哪些检查以防止在BASH中以编程方式发生这种情况
以下命令是root运行的命令（它由root运行，因为我使用webmin）：
../../../../../etc/passwd
tar zxf /home/$USER/site/backups/$BACKUP_FILE -C /home/$USER/site/data/将是其尝试恢复的备份的名称
编辑1：
这是我到目前为止所提出的。我相信这种方式可以改进很多：
$BACKUP_FILE我想知道如果不允许CONTENTS=$(tar -ztvf /home/$USER/site/backups/$BACKUP_FILE | cut -c49-200)
for FILE in $CONTENTS; do
if [[ $FILE =~ \.\. ]] || [[ $FILE =~ ^\/ ]]; then
echo "Illegal characters in contents"
exit 1
fi
done
tar zxf /home/$USER/site/backups/$BACKUP_FILE -C /home/$USER/site/data/
exit 0
开始而不允许/就足够了吗？ ..
答案 0 :(得分：2)
通常tar个实现会删除前导/并且不会使用..提取文件，因此您需要检查的是tar联机帮助页和不使用-P switch。
另一件事tar应该保护你免受符号链接攻击：用户创建文件$HOME/foo/passwd，将其备份，删除它，而是将$HOME/foo符号链接到/etc ，然后恢复备份。签署存档对此没有帮助，尽管使用用户权限运行会。
答案 1 :(得分：1)
尝试使用su：
将每个备份恢复为备份所有者su $username -c tar xzvf ...
（在某些情况下，您可能还需要-l选项。）
确保您真正了解以root身份运行的程序要求。您正在运行的进程不需要任何其他权限，除了对一个目录的读访问权限以及对另一个目录的写访问权限，因此即使用户帐户权限也是一种过度杀戮，甚至不提及root。这只是在惹麻烦。
答案 2 :(得分：0)
我假设备份是由脚本生成的，而不是用户生成的。 （提取任意用户创建的tar文件从来都不是一个好主意。）
如果您的备份必须存储在用户可写入的目录中，我建议您对每个备份文件进行数字签名，以便验证其完整性。然后，您可以在使用tar文件进行恢复之前验证它是否合法。
使用GPG的示例：
gpg --armor --detach-sign backup_username_110217.tar.gz
这会创建一个签名文件backup_username_110217.tar.gz.asc，可用于验证文件：
gpg --verify backup_username_110217.tar.gz.asc backup_username_110217.tar.gz
请注意，要在脚本中运行它，您需要创建没有密码的密钥。否则，您必须将密码作为纯文本存储在脚本中，这是一个可怕的想法。