【问题标题】:Security Issues by calling require() with untrusted string (require.js)通过使用不受信任的字符串 (require.js) 调用 require() 来解决安全问题
【发布时间】:2015-02-21 16:19:24
【问题描述】:

我的浏览器应用程序使用 require.js。该应用程序在屏幕上显示许多不同的小部件之一。 URL 片段包含一个小部件的路径(一个 require.js 路径),然后调用 require 来动态加载它:

var moduleName = getUrlFragement('widget'); // accesses window.location
require(moduleName);

moduleName 是一个 untrusted 字符串。用户可以随意制作。

这有什么安全问题?

到目前为止,这是我自己的发现:

  • 攻击者无法从其他域加载任意 URL
  • 攻击者无法从同一域加载任意 URL
  • 攻击者可以强制加载我的应用程序定义的任何模块,这将运行该模块具有的任何初始化逻辑。 这是不允许的

有什么我错过的吗?

【问题讨论】:

  • 您能否要求/强制该模块仅位于服务器上的一个特定路径位置,其中只有您知道是安全的模块?因此,您允许最终用户仅指定基本文件名,而不是路径,并将“安全”路径附加到用户提供的名称。
  • 是的,执行一些约束很容易。我已经知道我不会允许用户加载任意模块。我想知道我的分析是否涵盖了所有安全问题。
  • 这里的挑战是你没有透露问题中更有趣的部分。如果用户可以在服务器上放置任何模块然后执行该模块,这意味着他们可以执行任何他们想要的代码。如果他们只能执行已经放置在机器上的模块,那么漏洞完全取决于他们可以访问的地方有哪些模块以及这些模块做了什么。如果他们只能执行一组受限的模块,那么它完全取决于那组受限的模块做什么。因此,漏洞取决于他们有权执行的模块。
  • 用户不能将模块放到服务器上。
  • 那么,为什么不允许用户仅指定文件名(无路径),然后在模块名称上放置路径,并确保只有安全模块位于该路径中?您必须拒绝任何指定路径字符的非法名称才能强制执行。

标签: javascript security requirejs


【解决方案1】:

没有。您已经完整准确地捕捉到了安全问题。

【讨论】:

    猜你喜欢
    • 2011-01-20
    • 1970-01-01
    • 2013-02-27
    • 2019-11-13
    • 2021-08-06
    • 2015-05-15
    • 2017-05-20
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多