2

我要求允许用户将 JavaScript 块粘贴到我们的服务器中，并将其添加到此用户网页的 head 下（用户域将是 customName.oursite.com）。此类功能的安全后果是什么？

4

6 回答 6

2

好的，我会举例说明，因为其他人都解释过。我对此也有第一手经验，实际上只是为了好玩和练习：

  • 可以创建一个脚本，使页面看起来像您网站的登录页面并记录登录。人们会在不知不觉中使用该欺诈页面（带有一些社交工程）登录并立即登录！用户名和密码。

  • 可以在用户不知情的情况下进行操作和记账。假设我在我的个人资料页面上植入了恶意代码，该代码加载了一个带有http://example.com/account.php. 如果用户使用脚本访问页面，iframe 将与帐户页面一起加载。由于用户已登录，因此将显示他的信息。然后脚本可以抓取 iframe（因为它是同一个域），并通过 GET 请求（序列化 URL）将其转发到黑客的服务器。

  • 一个人可以种植饼干并跟踪你。当不知情的用户访问恶意页面时，脚本可以读取所有 cookie，并将其转发到黑客的服务器。由于 cookie 几乎用于所有事情（从保存会话到存储购物车信息），因此您已经暴露了。

  • 使用“访问过的链接是紫色的”技术可以知道您访问过哪些网站。该脚本可以在 DOM 上生成一个链接列表，检查其中哪些是紫色的，然后将该“紫色列表”转发给黑客。

  • 使用用户的凭据植入垃圾邮件脚本。假设恶意代码扫描您网站上的其余页面以查找 Facebook 类似按钮，然后单击它们或启动类似的 GET/POST - 在他们不知情的情况下。最后，用户不会知道他们喜欢了一百万页。

  • 还有更多……想推荐几个可能的吗？

简而言之，让用户发布任意脚本，尤其是在共享空间中，是……无法形容的邪恶。

如果您正在运行网络托管服务，则每个用户都应该有自己的“空间”，与其他用户分开，并与主站点分开。这就是为什么在免费托管中，用户拥有自己的子域，或者在付费托管中，用户拥有自己的域。用户可以对自己的空间做任何他们想做的事，而不会损害主机或它下面的其他用户。

* 有一些例外。由于用户可以自由对他们的空间做任何事情，他们可以将他们的空间变成一个完全恶意的站点。尽管如此，其他用户仍应行使基本的站点安全性。就算是在另外一个空间，也有很多方法可以进入，或者做一些阴险的事情。

于 2012-05-11T17:05:08.430 回答
2

你让他们做任何他们可以用 Javascript 做的事情，包括像 XSS 攻击和 CSRF 攻击这样的攻击。他们可能会窃取会话、重定向到恶意站点、窃取 cookie 信息，甚至锁定用户的浏览器。从本质上讲，存在许多安全后果，您还将增加您的责任。用户可能会将不良行为与您的网站联系起来，并且可能没有意识到包含恶意 Javascript 的是您的客户。

于 2012-05-11T16:56:17.950 回答
1

跨站脚本攻击是一个大问题

于 2012-05-11T16:55:35.010 回答
1

XSS 是最大的问题。这可能允许访问 cookie、页面、提供提升的权限或重定向到恶意页面，这可能导致病毒在用户机器甚至服务器上传播。

于 2012-05-11T16:57:05.780 回答
1

从两个角度考虑：首先，用户几乎已经可以通过书签和浏览器的开发工具 javascript 控制台做到这一点。因此，您的服务器应该已经针对恶意客户端进行了强化。请记住，虽然用户可以使用浏览器访问您的站点，但攻击者可以使用任意 HTTP 或 TCP 消息进行攻击，而您必须处理这些问题。因此，从一开始，您就应该设计您的服务器，以将客户端视为最好的不受信任和最坏的敌对。

现在具体来说，网站很少允许这种事情，因为正如您正确想象的那样，它确实使事情变得更加棘手。但是，许多应用程序需要这种类型的解决方案。所以请记住，您从服务器发出的数据可能会被不受信任、损坏、泄漏（在隐私方面）或其他不安全的用户编写的 javascript 访问。不要相信您的 javascript 可以在浏览器中进行任何授权过滤。所有离开服务器的数据都必须经过适当的授权过滤，并且永远不要假设您的服务器会收到有效/授权的请求。

于 2012-05-11T16:59:23.863 回答
-1

我认为关键问题是 JavaScript 在哪里执行？如果它在仅对用户可见的页面上运行，则只有该用户会受到脚本的影响。例如，如果它在评论板上运行，那么其他用户可能会受到脚本的影响。例如，该脚本可能会向恶意服务器发出一个 http 请求，并将 cookie 与请求一起传递。

于 2012-05-11T17:22:30.893 回答