如何确保我的 AJAX 请求来自 Python 中的同一服务器答案

【问题标题】：How to make sure that my AJAX requests are originating from the same server in Python如何确保我的 AJAX 请求来自 Python 中的同一服务器
【发布时间】：2014-03-18 10:16:15
【问题描述】：

我已经在这里问过一个关于 IP 认证的问题：TastyPie Authentication from the same server

但是，我需要更多的东西！ IP 地址很容易被欺骗。

场景：我的 API (TastyPie) 和客户端应用程序（在 javascript 中）位于同一服务器/站点/域上。我的用户没有登录。我想在我的 javascript 客户端使用我的 API。

问题：如何确保（身份验证）我的 AJAX 请求来自同一服务器？

我正在使用 Tatypie。我需要验证来自客户端的请求是在同一服务器/域等上发出的。我不能使用“登录会话”，因为我的用户没有登录。

我查看了私钥并生成签名，但它们可以在 javascript 中查看，从而使该方法不安全。如果我这样做是为了向服务器请求签名（在某些 python 代码中隐藏私钥），任何人都可以向get_signature 发出与我的 javascript 发出的相同的 http 请求，从而打破这一点。

我还尝试让 Django 视图将签名放入视图中，从而无需进行 get_signature 调用。这是安全的，但意味着我现在每次都必须刷新页面才能获得新的签名。从用户的角度来看，只有第一次调用 API 会起作用，之后他们需要刷新，同样没有意义。

我不敢相信我是唯一有此要求的人。我敢肯定，这是一个常见的情况。请帮助 :) 在 Tastypie 中使用自定义身份验证的示例也将受到欢迎。

谢谢

添加：

【问题讨论】：

您的请求需要回复吗？您可以在应用程序级别尝试三向握手。通过欺骗 IP 地址，攻击者应该无法得到任何响应（因为响应将被发送到被欺骗的 IP 地址）
@Paulo Bu 这很有趣，我能看到 Tatypie 示例或指南中的任何内容吗？
No :( 只是我刚刚得到的一个想法。希望有人能给出答案。
另外 - 为什么 csrf 还不够呢？它专门用来防止这种伪造
我认为您需要在这里考虑两件事。首先，听起来你有一个公共 API。在这种情况下，请确保以不允许写入的方式锁定 API。第二。您要确保您拥有的脚本可以在同一站点上运行。如果这是一个 Django 站点，为什么不创建一个临时会话，请针对该会话进行验证。这样，当该会话超时时，用户将无法再访问 API。这意味着如果用户通过本地表单进行远程调用，他们将不得不继续在您的站点上启动新会话。等

标签： python django tastypie

【解决方案1】：

根据您的基础架构，@dragonx 的回答可能是您最感兴趣的。

我的 2c

您想确保只有当客户访问您的网站时才能使用该 api？嗯，机器人、机器人、爬虫与客户端属于同一类别吗？还是我错了？如果你真的想保护它，这很容易被利用。

我不敢相信我是唯一有此要求的人。

也许不是，但正如您所见，您的 API 容易受到多次攻击，这可能是有人不分享您的设计并使用 auth 使安全性更严格的原因。

编辑

既然我们谈论的是 AJAX 请求，那么 IP 部分与此有什么关系？ IP 将永远是客户的 IP！所以很可能，你想要一个公共 API……

我会选择令牌/会话/cookie 部分。
我会使用持续一段时间的生成令牌和下面描述的流程。
有时我会使用限制器，like Github does。例如，registered users registered users 每小时每个 ip 60 个请求或更多

要克服刷新令牌的问题，我会这样做：

客户访问网站

-> 服务器生成API TOKEN INIT

-> 客户端获取 API TOKEN INIT，仅对开始 1 个请求有效。
客户端向 API 发出 AJAX 请求

-> 客户端使用 API TOKEN INIT

-> 服务器检查 API TOKEN INIT 和限制

-> 服务器接受请求

-> 服务器传回API TOKEN

-> 客户端消费响应数据并存储 API TOKEN 以供进一步使用（将通过 JS 存储在浏览器内存中）
客户端在有限时间或请求内使用 API 启动通信。请注意，您还知道初始化令牌日期，因此您可以使用它来检查页面上的第一次访问。

第一个令牌是在客户端访问时通过服务器生成的。然后客户端使用该令牌以获得真实的令牌，该令牌持续一段时间或其他限制。这使得某人实际访问该网页，然后他可以在有限的时间内访问该 API，也许是请求等。

这样你就不需要刷新了。

当然，上面的场景可以简化为只用一个令牌和上面提到的时间限制。

当然，由于您没有身份验证，因此上述情况很容易出现高级爬虫等。

当然，聪明的攻击者可以从服务器获取令牌并重复这些步骤，但是，您从一开始就已经遇到了这个问题。

加分

由于提供的 cmets，请关闭对 API 的写入。如果您对自己的实施（如果不使用身份验证）或额外的安全性有疑问，您不想成为 DOS 攻击的受害者
上述令牌场景也可能变得更加复杂，例如通过不断交换令牌

仅供参考 GAE 云存储使用signed_urls 用于相同目的。

希望对您有所帮助。

PS。关于 IP 欺骗和防御欺骗攻击 wikipedia 表示不会将数据包返回给攻击者：

一些上层协议提供自己的 IP 防御欺骗攻击。例如，传输控制协议 (TCP) 使用与远程机器协商的序列号来确保到达的数据包是已建立连接的一部分。由于攻击者通常看不到任何回复数据包，序列号必须猜到才能劫持连接。穷人在许多较旧的操作系统和网络设备中实现，但是，这意味着可以预测 TCP 序列号。

【讨论】：

机器人与我无关。该页面实际上是一个注册表单。所以这就是为什么我的用户在那个阶段没有登录。你是第二个说“3 路 ip 检查”的人，但我仍然不确定 TastyPie 是如何工作的。
还有你建议的这个选项我还需要保持刷新，对吧？

【解决方案2】：

如果是纯同一个服务器，可以针对 127.0.0.1 或者 localhost 验证请求。

否则解决方案可能是在网络级别，拥有一个可以检查的单独私有子网。攻击者应该很难在不进入您的子网的情况下欺骗您的子网。

【讨论】：

dragonx，我想进一步探索一下。但这肯定更容易欺骗吗？即 addr = socket.gethostbyname(socket.gethostname()) if addr == "127.0.0.1"
问题是我必须相信他的客户要求说的话对吗？我仍然不明白如何使用此方法确保 AJAX 请求来自同一服务器。
是的，假客户端可以欺骗 127.0.0.1 作为源请求。但是，该地址始终与 localhost 相关联，因此响应将发送到本地计算机，而不会发送到欺骗者。解决方案是在网络级别打破欺骗。只有当攻击者能够将响应重定向回自己时，欺骗才有效。您可以做的其他事情是围绕系统的这一部分设置防火墙，以便他们无法进行欺骗。但是在客户内部，你能做的事情是有限的。

【解决方案3】：

我猜你有点困惑（或者我是，请纠正我）。您的 JS 代码与您的 API 发布在同一台服务器上并不意味着 AJAX 请求将来自您的服务器。客户端从您的服务器下载 JS 并执行它，这会导致请求从客户端发送到您的 API，而不是从同一服务器发送。

现在，如果上述场景正确描述了您的情况，您可能正在尝试保护您的 API 免受bot scraping 的侵害。最简单的保护是 CAPTCHA，您可以在 Wiki 页面上找到更多想法。

如果您担心其他网站可能会对您的 API 进行 AJAX 调用以复制您的网站功能，那么您不应该这样做——AJAX 请求只能在运行 JS 的页面上发送to the same server，除非它是 JSONP。

【讨论】：

【解决方案4】：

简答：无法阻止专门的攻击者。

除了客户提供给您的信息之外，您没有其他方法可以识别客户。例如，用户名/密码身份验证是在假设只有有效客户端才能提供有效凭据的情况下工作的。当有人登录时，您只知道有人提供了这些凭据——您假设这意味着这意味着他们是合法用户。

根据我的理解，让我们在这里看看您的场景。验证客户端的唯一方法是 IP 地址，very weak form of authentication。正如您所说，这很容易被欺骗，并且通过一些努力，您的服务器的响应可以被接收回攻击者的原始 IP 地址。 如果发生这种情况，您将无能为力。事实是，如果您假设来自有效 IP 地址的某人是有效用户，那么欺骗者和合法用户是无法区分的。这就像有人窃取了您的密码并尝试登录 StackOverflow 一样。对于 StackOverflow，攻击者和你是无法区分的，因为他们所要做的只是用户名和密码。

您可以像其他答案中提到的那样对客户端做一些花哨的事情，例如令牌、时间限制等，但是专门的攻击者将能够模仿合法客户端的操作，而您将无法将它们区分开来，因为它们似乎都来自有效的 IP 地址。例如，在您的上一个示例中，如果我是一个想要进行 API 调用的攻击者，我会欺骗一个合法的 IP 地址，获取签名，并使用它来进行 API 调用，就像合法客户端一样。

如果您的应用程序足够重要，可以将这种级别的想法视为安全性，那么您至少应该考虑实施 API 令牌、公钥加密或其他比 IP 地址更安全的身份验证方法来区分您的客户端从任何攻击者。通过 IP 地址（或其他容易伪造的令牌，如主机名或标头）进行身份验证根本无法解决问题。

【讨论】：

请问如何：with some effort your server's response can be received back to the attacker's original IP address。我认为通过“一些”努力是不可能的。
我的回答是基于security.stackexchange.com/questions/13255/…；一般来说，共识答案似乎是基于 IP 地址的身份验证易受攻击。

【解决方案5】：

也许您可以通过使用同源策略

来实现这一点

参考http://en.wikipedia.org/wiki/Same_origin_policy

【讨论】：

【解决方案6】：

正如 Venkatesh Bachu 所建议的，Same Origin Policy 和 http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing (CORS) 可以用作解决方案。在您的 API 中，您可以检查 Origin 标头并做出相应的响应。需要检查是否可以使用篡改数据等扩展来修改 Origin 标头。坚定的黑客仍然可以通过将浏览器指向本地代理服务器来窥探。

【讨论】：

【解决方案7】：

如果此应用服务器运行在具有可配置监听 IP 地址的普通 Web 服务器上，请将其设置为 127.0.0.1。使用 TCPServer 模块，就像

SocketServer.TCPServer(("127.0.0.1", 12345), TheHandlerClass)

使用netstat命令验证监听地址是否正确为“127.0.0.1”

tcp4 0 0 127.0.0.1.12345 *.* LISTEN

这将有效地使来自同一主机之外的任何连接在 TCP 级别上都不可能。

【讨论】：

【解决方案8】：

有两种通用的解决方案类型：使用普通 Web 服务器/客户端机制的带内解决方案，易于实施但有局限性；以及依赖您在外部进行配置的带外解决方案，这需要更多的工作，但没有带内相同的限制。

如果您更喜欢带内解决方案，那么用于防止跨站点请求伪造 (XSRF) 的典型方法会很有效。服务器发行一个生命周期有限的令牌；客户端在请求中使用令牌；令牌的隐私（某种程度上）通过使用 HTTPS 连接得到保证。这种方法被广泛使用，并且效果很好，除非您担心可能会拦截令牌的中间人攻击，或者可能会向其他顽皮的客户端代码泄露数据的错误浏览器。

如果您有动力，可以通过引入客户端证书来消除这些限制。这些是我们都在 Web 服务器上使用的 SSL 证书的另一面——它们以相同的方式运行，但用于识别客户端而不是服务器。因为证书本身永远不会通过网络传输（您将其安装在浏览器或其他客户端本地），所以您不会面临来自中间人和浏览器泄漏的相同威胁。此解决方案在野外使用不多，因为它设置起来很混乱（对于典型用户来说非常混乱），但如果您的客户端数量有限并且它们在您的控制之下，那么部署和管理可能是可行的这个数量有限的客户端证书。证书操作由浏览器处理，而不是在客户端代码中（即不在 JavaScript 中），因此您对在 JavaScript 中可见关键数据的担忧在这种情况下不适用。

最后，如果您想跳过客户端配置的废话，请使用最终的带外解决方案 -- iptables 或类似工具来创建仅允许来自网络接口的会话的应用程序级防火墙（如本地环回）您确定无法直接访问。

【讨论】：