这个Perl代码中的特定路径连接是否可以利用?

kno*_*orv 3 regex linux filesystems security perl

假设攻击者控制变量$untrusted_user_supplied_path.以下Perl代码是否可以利用?

my $untrusted_user_supplied_path = ...
if ($untrusted_user_supplied_path =~ /\.\./) {
  die("Tries to escape homedir.");
}
my $base_path = "/home/username/";
my $full_path = "${base_path}${untrusted_user_supplied_path}";
if (-e $full_path) {
  open(FILE, "<", $full_path) || die("File not accessible.");
  while (<FILE>) {
    # present the content to the user
  }
  close(FILE);
}
Run Code Online (Sandbox Code Playgroud)

如果攻击者可以选择一个值,$untrusted_user_supplied_path以便他/她可以读取驻留在不是$base_path(例如/etc/passwd)子目录的目录中的文件,那么代码被定义为可利用的?

您可以假设代码在Linux下运行.此外,您可以假设在向用户呈现文件的代码中没有引入其他缺陷.

请注意,问题是代码是否可利用,而不是如何使代码更安全.有许多方法可以使代码更安全(想想chroot等),但这超出了这个问题的范围.如果您认为代码是可利用的,请在您的答案中说明.当然,请提供支持论证.

Tho*_*mas 9

如果homedir内的符号链接存在于外面的某个地方,那么你仍然遇到麻烦.


bri*_*foy 9

你问的是你的代码是否可以利用.是.所有代码都可以利用.你可能不认为这是因为你认为你已经涵盖了你可以考虑的情况,但另一方通常会发现你没有想过的情况.但是,我总是说所有的枪都装满了.

安全不仅仅是代码.您必须考虑它运行它的环境,用户在运行代码之前还允许做什么,等等.

如果您真的担心此代码可能会发生什么,请创建风险矩阵.从您担心的部分开始,列出其所有假设.例如,在您的情况下,您可能会开始:

  • / home/username是我认为的目录(即不是挂载点,符号链接,假用户等)
  • 提供的路径是我期望的并且允许存在
  • 路径是常规文件(例如,不是特殊设备)
  • 路径具有特定的所有者,组或模式
  • 我正在运行perl我认为我(在查找可执行文件时没有路径攻击)
  • PERL5LIB,PERL5OPT或者-I没有前载模块加载路径(在查找模块时没有路径攻击)

等等等等.一旦您开发了所有假设,就可以通过锁定这些案例来确保它们有效.您还可以找到他们所有的假设,并锁定这些假设,依此类推.Perl的污点检查将有助于其中一些(我在Mastering Perl中更深入地讨论它).

成功的攻击往往是间接攻击.例如,我是一份工作的一部分,以确保一个非常富有和偏执银行的数据.我们完成了所有可以做的计算机工作,我的一位同事在闲聊中询问他们在安装服务器之前是如何完成任务的.他们说,"哦,数据是在某某桌子上的活页夹上".尽管我们所有的工作,他们的工资,以及每个人的时间和精力,内部任何想要数据的人都可以完全放弃它,无论我们对服务器做了什么.

既然您已经拥有了风险矩阵,那么您就开始建立风险承受能力.没有什么是完美的,你可以努力将宇宙锁定在一切之下.您不必完美,而是决定您愿意为代码的每个部分承担多大的风险.你弄清楚如果一部分受到损害可能会发生什么,以及花费多少(以美元,声誉,等等),并找出对你(或你的雇主)有多少工作价值.你做的工作足够低于你的风险承受能力.

问题是,即使是最好的人也会错过一些东西.安全方面的小裂缝可能看起来并不重要,但如果你把足够的东西放在一起,你最终可以将自己引导到一个可利用的局面.安全是全面的.