在最近对 Web 应用程序的渗透测试中,发现的问题之一是“备份文件”。这是一个 javascript 文件,在上传filename.js1
更新版本时重命名为filename.js
。
“备份文件”位于禁止列出的目录中,并且不会在应用程序的任何地方引用或使用。
他们是怎么找到这个文件的?
在最近对 Web 应用程序的渗透测试中,发现的问题之一是“备份文件”。这是一个 javascript 文件,在上传filename.js1
更新版本时重命名为filename.js
。
“备份文件”位于禁止列出的目录中,并且不会在应用程序的任何地方引用或使用。
他们是怎么找到这个文件的?
许多自动扫描程序通过“蛮力”搜索文件来绕过被禁止的目录列表。这意味着他们将检查名称与确实存在的文件相似的其他文件(即filename.js1
,以及根本没有引用的文件(aka secret.txt
)。如果您碰巧有一个文件,其名称在 bruteforced 列表中并且是在可访问的目录中,无论是否启用“目录列表”,都会找到它
值得指出的是,黑客也会做同样的事情,所以这是一个真正的问题。通常,如果某些内容位于可公开访问的目录中,那么您应该假设它会被找到。因此,如果您不希望它公开,那么您需要将其保留在公共目录之外 - 禁用目录列表提供的安全性非常低。
最后,这似乎不是一个大问题(而且可能不是),但是将 javascript 文件的备份保留在公共目录中实际上通常是一个坏主意。当涉及到 XSS 时,如果攻击者能够利用托管在同一域上的 javascript 文件,他们通常会获得最大的成功。这是因为这样做提供了绕过 CSP 或其他安全“防火墙”的机会。结果,如果一个较旧的 javascript 文件碰巧有一个安全漏洞,该漏洞已在更高版本中修复,并且攻击者找到了强制用户浏览器加载旧 javascript 文件的方法,他们可能会链接到一个更具破坏性的脆弱性。这似乎有些牵强,但是将许多小漏洞链接成一个更大的漏洞就是发生了多少最严重的违规行为。
tl/dr:如果某些内容由您的网站托管,但没有理由存在,那么这是一种责任。带着偏见杀了它。
有许多工具可用于暴力破解文件名。其中一些人比其他人更聪明。
例如,“哑”工具可能只有一个单词列表,其中包含文件和目录的可能名称,例如
/admin/
wp-admin.php
login.php
更智能的工具可能会查看它已经知道的文件(例如,通过爬取应用程序)并尝试找到名称相似的文件。在您的情况下,有一个名为 的文件filename.js
,因此应用程序可能试图破坏该名称,正如 TripeHound 在评论中指出的那样:
filename.js1
filename.js.bak
filename.bak.js
.filename.js
人们可能会认为未引用的文件是“安全的”,因为它不是应用程序的一部分。但是,该文件仍然可以访问,并且根据文件的内容,这可能允许攻击者执行各种操作:
一般来说,最好避免在您的 webroot 中包含未引用的文件。顾名思义,它们不被应用程序使用,因此只是问题的根源。
这里真正的问题是您的部署/生产环境无法通过自动化的源代码控制和部署系统进行控制(因此是可复制的)。
这意味着,如果您在系统中发现一些新文件,您不知道这是由 root 工具包丢弃的某种后门,还是您的同事留下的一些无害的重命名文件。
通常,最佳安全实践是只在服务器上放置由克隆某种构建工件的自动化脚本放置的文件,并让该自动化过程也删除不应该再存在的文件。然后,您可以对“生产中的文件是否与构建系统所说的一样?”进行审计。
如果您认为“糟糕的部署实践不可能对我的业务造成威胁生命的问题”,那么我邀请您使用谷歌搜索“Knight Capital Group”。
与攻击者相同的方式:通过猜测。
这就是为什么你有渗透测试器:测试你可能没有想到的东西。
从您的应用程序中删除备份文件,使其无法访问。