【问题标题】:Scripts folder a vulnerability?Scripts 文件夹存在漏洞?
【发布时间】:2012-02-22 21:05:17
【问题描述】:

在我的 .NET Web 应用程序中,我通常有一个 Scripts 文件夹,其中包含我所有的 JavaScript 文件——这些天主要是 jQuery,偶尔还有一些 JavaScript 库。

我正在通过一个名为 Nexpose 的扫描程序对我的一个网站进行漏洞扫描,它告诉我 Scripts 文件夹对全世界开放 - 这意味着未经身份验证的用户可以下载该文件夹中包含的 JavaScript 文件,这是一个严重的漏洞。根据 Nexpose 的说法,应该将 Scripts 文件夹限制为只允许经过身份验证的用户访问它。这引出了我的第一个问题。

如何将 Scripts 文件夹限制为仅经过身份验证的用户? 我尝试将 web.config 文件放入 Scripts 文件夹并以这种方式拒绝所有未经身份验证的用户访问,但没有成功.我自己能够确定这一点,但转到我网站的登录页面,但没有登录,然后输入https://mywebsite/scripts/menubar.js,果然它允许我下载 menubar.js 文件。

第二个问题 - 为什么这被认为是一个漏洞?我试图通过这里的可能性来推理我的方式,但我根本没有想出很多。这仅仅是因为 Joe l33t h4x0r 可以找出我正在使用的各种库然后可能使用已知的漏洞来对付它们吗?

更新

绝大多数答案似乎是,绝不应该仅仅因为可以在客户端的浏览器上打开和读取 .js 文件而存在漏洞。唯一可能存在的漏洞是,如果开发人员以某种不安全的方式使用 .js 文件(我不是)。

【问题讨论】:

    标签: javascript jquery asp.net security


    【解决方案1】:

    从逻辑上讲,您不希望实际上禁止访问实际文件,因为这样您就无法在网页中使用它们。网络服务器不区分在呈现网页过程中请求文件的浏览器与仅手动下载文件的浏览器。

    因此,您的第一个问题的答案是:您不能也不想这样做。如果您不希望用户访问,请将其从 web 文件夹中取出。如果需要它来呈现您的网站,那么您希望任何人都可以访问它,以便您的网站能够正确呈现。

    至于为什么它被认为是一个漏洞,谁说它是?我现在可以去提取 Facebook 使用的任何 JavaScript。或者,更重要的是,我可以访问美国银行或大通的网站并开始查看他们的 JavaScript。如果我有帐户,我什至可以查看用户登录后使用的 JavaScript。

    您可能需要担心的唯一一件事就是您始终需要担心的同一件事:暴露不应该暴露的细节。我不知道你为什么会这样做,但是例如,将数据库密码放在 JavaScript 文件中显然不是一个好主意。除此之外,没有什么可担心的。

    【讨论】:

    • 同意。 Nexpose 几乎不是此类事务的最终权威。
    • 这不一定是真的,最后一篇关于没什么好担心的。如果您的网络服务器对该目录具有写入权限,并且我让它编写 Woot4Moo 的自定义 Javascript 文件,那么没有人会高兴,或者更重要的是,任何我可以欺骗服务器写入的文件。
    • 这就是问题所在 - Nexpose 告诉我这是一个漏洞。人们会认为漏洞扫描工具会知道某些东西是否真的是漏洞。但是我意识到情况可能并非如此(这意味着它可能不是漏洞),并认为我会在 stackoverflow 上发布关于它的好消息。
    • 你所说的不应该打折扣,所以不要误会我的意思,但实际上你必须工作才能使你的服务器变得不安全。每个文件将默认仅为创建者写入权限,并且网络服务器始终默认为拥有自己的隔离用户和组。您必须授予全局写入权限,以管理员/root 身份运行服务器,并禁用多种其他安全措施,然后才能真正解决此类漏洞。虽然你是对的,但我今晚不会为此失眠。
    • @Woot4Moo - 如果 Scripts 文件夹对每个人都有写权限,那么我确实有一个很大的问题。但它没有......或者它不应该。这让我连想都不敢想。
    【解决方案2】:

    在大多数情况下,这不是漏洞。考虑所有具有匿名流量和/或很容易成为经过身份验证的用户的大型公共站点(Google、eBay、Amazon 等)。这些站点也有一些最复杂的脚本。

    需要注意的更微妙的事情是您确实想要保护的其他文件。例如,如果用户必须先登录您的网站并购买文档、视频、图像等,然后才能查看它,那么它当然不应该位于可公开访问的文件夹中。

    【讨论】:

    • 感谢您的帮助。不,我这里没有这样的事情。它只是一个包含 .js 文件的文件夹;但是,您在这里给了我一些新的思考。
    【解决方案3】:

    是的。您应该让大部分处理在服务器端完成,因为大多数(如果不是全部)客户端脚本都可以编辑,等等。大多数网站都使用 Javascript,因此简单地使用它并不危险,您只需要小心使用它。

    另外,回答您的第一个问题,如果未经身份验证的用户也需要它们,请不要保护它们。

    【讨论】:

      【解决方案4】:

      听起来有些安全套件的扳机手指很痒。我能看到的唯一两个问题是,如果有人选择指向 your jQuery 或 your -在此处插入库名称,您最终可能会将您的服务器作为 CDN 借出 -或者(现在这是一个真正的安全风险)如果您还提供任何可能构成潜在威胁的动态 .js 文件。我唯一能想到的另一件事是,如果您将“自定义”应用程序 js 与所有库混合在一起,有人可能会发现您的端点(Web 服务等)并尝试查看它们是否安全...... 但仅此而已!仅此而已...(除非您做了一些非常愚蠢的事情,例如硬编码密码之类的东西...大声笑)

      【讨论】:

        【解决方案5】:

        所以攻击不是人们可以编辑脚本,攻击是让 Web 服务器任意写入目录。您需要做的是确保它们是只读文件。 chmod 400 或 windows 读取。在深度防御 (DiD) 方面,您要确保 Web 服务器是无法登录系统的非特权用户。进一步需要发生的是,无论您在客户端做什么,您都在服务器上进行所有数据清理,因为您无法控制客户端。通常,这涉及确保在提供服务之前清理来自网络和数据库的所有数据。我最喜欢做的事情之一是将任意 javascript 插入数据库并观察它在 UI 中执行的操作,因为开发团队认为一切都会好起来的,因为他们已经清理过一次。

        如果有必要,我可以提供有关保护系统的更多详细信息。

        【讨论】:

          猜你喜欢
          • 2021-08-14
          • 1970-01-01
          • 2020-07-21
          • 1970-01-01
          • 2011-09-14
          • 2022-11-29
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多