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

Pro*_*eus 24 python django tastypie

我已在此处询问有关IP身份验证的问题: 来自同一服务器的TastyPie身份验证

但是,我需要更多的东西!IP地址可能非常容易欺骗.

在此输入图像描述

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

问:我怎样才能确保我的(认证)AJAX请求来自同一服务器发起

我正在使用Tatypie.我需要验证来自客户端的请求是在同一服务器/域等上进行的.我不能使用"登录会话",因为我的用户没有登录.

我查看了私钥并生成了签名,但他们可以在javascript中查看,使该方法不安全.如果我以某种方式请求服务器的签名形式(在某些python代码中隐藏私钥),任何人都可以向get_signature我的javascript发出相同的http请求,从而打败这一点.

示例获得签名

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

使用Django进行签名

我无法相信我是唯一有此要求的人.这是我确定的常见情况.请帮助:)在Tastypie中使用自定义身份验证的示例也会受到欢迎.

谢谢

添加:

Jim*_*ane 7

根据您的基础设施,@ dragonx的答案可能会让您最感兴趣.

我的2c

你想确保只有客户访问你的网站才能使用api?嗯机器人,机器人,爬虫与客户属于同一类别吗?还是我错了?如果你真的想要真正保护它,这很容易被利用.

我无法相信我是唯一有此要求的人.

也许不是,但正如您所看到的,您可能会对您的API产生多次攻击,这可能是某人不与您分享您的设计并使用auth更严格的安全措施的原因.

编辑

既然我们在谈论AJAX请求IP部分与此有什么关系呢?IP 永远是客户的IP!所以可能,你想要一个公共API ......

  • 我会使用令牌/会话/ cookie部分.

  • 我将使用生成的令牌持续一段时间,并在下面描述流程.

  • 我每次都会使用限制器,就像Github那样.例如,对于注册用户,每小时每小时60个请求或更多

要解决刷新令牌的问题,我会这样做:

  1. 客户访问该网站

    - > server生成API TOKEN INIT

    - >客户端获取API TOKEN INIT,仅对启动1个请求有效.

  2. 客户端向API发出AJAX请求

    - >客户使用API TOKEN INIT

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

    - >服务器接受请求

    - >服务器传回API TOKEN

    - >客户端使用响应数据并存储API TOKEN以供进一步使用(将通过JS存储在浏览器内存中)

  3. 客户端在有限的时间或请求下启动Comm API .请注意,您还知道init令牌日期,因此您可以使用它来检查页面上的第一次访问.

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

这样你就不需要刷新了.

当然,如上所述,上述场景可以仅使用一个令牌和时间限制来简化.

当然,由于您没有身份验证,上述方案很容易出现高级爬虫等.

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

一些额外的点

  • 如提供的评论,请关闭API的写入.如果您对实施有疑问(如果不使用auth)或额外的安全性,您不希望成为DOS攻击的受害者
  • 如上所述的令牌场景也可以变得更复杂,例如通过不断地交换令牌

仅供参考GAE云存储使用signed_urls来实现相同的目的.

希望能帮助到你.

PS.关于IP欺骗和防御欺骗攻击,wikipedia说所以数据包不会被返回给攻击者:

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


dra*_*onx 6

如果它是完全相同的服务器,则可以验证针对127.0.0.1或localhost的请求.

否则,解决方案可能位于网络级别,以便拥有可以检查的单独的私有子网.攻击者很难在不占用子网的情况下欺骗您的子网.

  • 是的,假客户端可以欺骗127.0.0.1作为源请求.但是,该地址始终绑定到localhost,因此响应将被发送到本地计算机,它不会被发送到欺骗程序.解决方案是打破网络级别的欺骗.只有当攻击者能够将响应重定向回自己时,欺骗才有效.您可以做的其他事情是围绕系统的这一部分设置防火墙,以便他们无法进行欺骗.但在客户端内,你可以做的事情受到限制. (3认同)

jwa*_*ker 5

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

现在,如果上述情况正确地描述了您的情况,那么您可能要尝试做的就是保护您的API免受机器人抓取。最简单的保护是CAPTCHA,您可以在Wiki页面上找到更多想法。

如果您担心其他站点可能会对您的API进行AJAX调用以复制您的站点功能,那么您不应该这样做-AJAX请求只能与JS运行所在的页面发送到同一服务器,除非它是JSONP 。