15

A product I'm helping to develop will basically work like this:

  • A Web publisher creates a new page on their site that includes a <script> from our server.
  • When a visitor reaches that new page, that <script> gathers the text content of the page and sends it to our server via a POST request (cross-domain, using a <form> inside of an <iframe>).
  • Our server processes the text content and returns a response (via JSONP) that includes an HTML fragment listing links to related content around the Web. This response is cached and served to subsequent visitors until we receive another POST request with text content from the same URL, at which point we regenerate a "fresh" response. These POSTs only happen when our cached TTL expires, at which point the server signifies that and prompts the <script> on the page to gather and POST the text content again.

The problem is that this system seems inherently insecure. In theory, anyone could spoof the HTTP POST request (including the referer header, so we couldn't just check for that) that sends a page's content to our server. This could include any text content, which we would then use to generate the related content links for that page.

The primary difficulty in making this secure is that our JavaScript is publicly visible. We can't use any kind of private key or other cryptic identifier or pattern because that won't be secret.

Ideally, we need a method that somehow verifies that a POST request corresponding to a particular Web page is authentic. We can't just scrape the Web page and compare the content with what's been POSTed, since the purpose of having JavaScript submit the content is that it may be behind a login system.

Any ideas? I hope I've explained the problem well enough. Thanks in advance for any suggestions.

4

10 回答 10

7

这没有确凿的证据。然而，在大枪不存在的地方，主要的烦恼可以。黑客喜欢挑战，但他们更喜欢简单的目标。足够烦人以至于他们放弃。

谷歌和其他公司通过广告词有效地做到了这一点。创建一个 api 令牌并让他们发送。对使用您的脚本的站点进行“验证”过程，要求此脚本的注册者允许在使用脚本之前对其站点进行概要分析。然后，您可以收集有关服务器的所有信息，如果服务器配置文件与记录的配置文件不匹配，则可以请求。

获取有关浏览器和客户端的所有信息并为其创建配置文件。如果有任何可能是浏览器欺骗，请放弃该请求。如果配置文件重复但 cookie 消失，则忽略输入。如果您在短时间内从令牌收到多个请求（即黑客尝试固有的快速页面刷新），请忽略该请求。

然后更进一步并 ping 实际域以验证它是否存在并且是授权域。即使页面在登录之后，域仍然会响应。这本身不会阻止黑客，但它是在服务器端完成的，因此是隐藏的。

此外，您可能会考虑分析页面的内容。如果专注于厨房用具的网站开始发回成人约会内容，请举起危险信号。

最后，当一个错误的请求出现并且您已将其分析为错误请求时，根据您知道的良好数据（该页面的 24 小时旧版本等）从对该页面的良好请求发送 JSONP . 不要告诉黑客你知道他们在那里。表现得好像一切都很好。他们需要很长时间才能弄清楚这一点！

这些想法都不能满足您的问题的确切需求，但希望它会激发您的一些阴险和创造性思维。

于 2011-10-27T22:40:20.747 回答
4

这个怎么样？-<script/>第三方网站包含的标签具有动态src属性。因此，它不是加载一些静态 Javascript 资源，而是来到您的服务器，生成一个唯一键作为网站的标识符，并将其发送回 JS 响应中。您将相同的密钥保存在用户会话或数据库中。这段JS代码创建并提交的表单也会提交这个关键参数。您的后端将拒绝任何与您的数据库/会话中的密钥不匹配的 POST 请求。

于 2011-11-09T08:05:33.523 回答
1

正如您所描述的，该系统的主要弱点是您“获得”了页面内容，为什么不自己去获取页面内容呢？

  1. Web 发布者在其站点上创建一个新页面，其中包含来自您服务器的脚本。
  2. 当访问者到达该新页面时，该脚本会向您的服务器发送一个获取请求。
  3. 你的服务器去获取页面的内容（可能通过使用引用头来确定请求的来源）。
  4. 您的服务器处理文本内容并返回一个响应（通过 JSONP），其中包括一个 HTML 片段，其中列出了指向 Web 相关内容的链接。此响应被缓存并从服务器端缓存/代理提供给后续访问者
  5. 当缓存版本的 TTL 过期时，代理会将请求转发到您的应用程序，整个循环从第 3 步重新开始。

这可以阻止恶意内容被“馈送”到您的服务器，并允许您提供某种形式的 API 密钥将请求和域或页面联系在一起（即 api 密钥 123 仅适用于 mydomain.com 上的引荐来源 - 其他任何内容显然都是欺骗的） . 由于缓存/代理，您的应用程序在某种程度上也受到了任何形式的 DOS 类型攻击的保护，因为每次缓存 TTL 过期时页面内容只处理一次（现在您可以通过扩展 TTL 来处理不断增加的负载，直到您可以带来额外的处理能力）。现在您的客户端脚本非常小而简单 - 不再需要抓取内容并发布它 - 只需发送一个 ajax 请求并可能填充几个参数（api key / page）。

于 2010-04-05T23:04:48.933 回答
1

在每个域的基础上为人员提供密钥。

让人们在请求中包含 [key string + request parameters] 的值。（哈希值应该在服务器上计算）

当他们向您发送请求时，您知道参数和密钥，就可以验证其有效性。

于 2010-04-02T18:53:02.353 回答
1

首先，我会按照其他人的建议验证域（可能还有“服务器配置文件”），并且显然非常严格地验证 POST 的内容（我希望你已经在这样做了）。

如果您使脚本文件的 URL 指向由服务器动态生成的内容，您还可以包含一个时间敏感的会话密钥，以便与 POST 一起发送。这不会完全挫败任何人，但是如果您能够使会话足够快地过期，那么利用起来将更加困难（如果我正确理解您的应用程序，会话应该只需要为用户持续足够长的时间加载页面后输入内容）。

输入此内容后，我意识到这基本上是avlesh 已经建议添加的到期时间。

于 2011-11-17T17:30:59.133 回答
0

网络发布者也可以在他们的服务器上放置一个代理页面吗？

然后通过代理加载脚本。然后你有很多可能性可以控制两台服务器之间的连接，添加加密等等。

什么是登录系统？使用 SSO 解决方案并保持脚本分开怎么样？

于 2010-04-05T17:39:04.263 回答
0

您可以对每个客户端 IP地址特定的密钥进行哈希处理，并使用帖子标头中的 IP 比较服务器上每个帖子的该值。这样做的好处是，如果有人欺骗了他们的 IP，响应仍将发送到被欺骗的 IP而不是攻击者的. 您可能已经知道这一点，但我也建议在您的哈希中添加盐。

使用欺骗性 IP 时，无法进行正确的 TCP 握手，因此攻击者的欺骗性帖子无法完成。

可能还有其他我不知道的安全问题，但我认为这可能是一种选择

于 2010-04-03T23:00:13.770 回答
0

如果您可以将服务器端代码添加到将数据推送到您的站点的站点，您可以使用 MAC 来至少防止未登录的用户发送任何内容。

如果只允许任何人使用该页面，那么我想不出一种在不刮掉网页的情况下确认数据的防水方式。您可以通过推荐人检查等使发送任意内容变得更加困难，但并非 100% 不可能。

于 2010-04-01T16:45:03.880 回答
0

您可以抓取该站点，如果您收到包含您的脚本的代码 200 响应，只需使用该抓取。如果不是，您可以从“客户端代理”解析信息，这样问题就出在您无法抓取的网站上。

为了在这些情况下提高安全性，您可以让多个用户发送页面并过滤掉任何在最少数量的响应中不存在的信息。这还将具有过滤掉任何用户特定内容的额外好处。还要确保注册您要求执行代理工作的用户，并确认您只收到您要求执行该工作的用户的页面。您还可以尝试确保非常活跃的用户不会获得更高的工作机会，这将使“钓鱼”变得更加困难。

于 2010-04-06T00:14:32.457 回答
-1

怎么样：

站点 A 创建一个随机数（基本上是一个随机字符串），将其发送到您的站点 B，然后将其放入会话中。然后，当站点 A 从站点发出 POST 请求时，它会随请求一起发送随机数，并且仅当随机数与站点 B 会话中的随机数匹配时，才会接受该请求。

于 2010-04-02T18:25:30.170 回答