如何确保我的AJAX请求是源自同一台服务器的Python [英] How to make sure that my AJAX requests are originating from the same server in Python

问题描述

我已经在这里询问了有关IP认证的问题：每小时每小时60个请求

为了克服刷新令牌的问题，我将这样做：

1. 客户访问该网站

   
   
   

   - >服务器生成 API TOKEN INIT

   
   
   

   - >客户端获取 API TOKEN INIT ，该值仅适用于启动1个请求。




2. 客户端使AJAX请求API

   
   
   

   - >客户端使用 API TOKEN INIT

   
   
   

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

   
   
   

   - >服务器接受请求

   
   
   

   - >服务器回传 API TOKEN

   
   
   

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




3. 客户端启动Comm API的限制时间或请求的数量。请注意，您也知道初始化令牌日期，以便您可以使用它来检查页面上的第一次访问。

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

这样你就不会需要刷新。

当然上述情况可以通过上面提到的一个令牌和时间限制进行​​简化。

当然，上述方案容易出现高级抓取工具，因为您没有认证。

当然，一个聪明的攻击者可以从服务器抓取令牌并重复这些步骤，但是从那以后你已经有了这个问题。

一些额外的点

• 由于提供的意见，请密切写入API 。如果您对实施有疑问（如果不使用验证）或额外的安全性，则不希望成为DOS攻击的受害者。


• 如上所述的令牌场景也可以变得更复杂，例如不断交换令牌

仅供参考GAE云存储使用 signed_urls 为同一目的。

希望它有帮助。

PS。关于IP欺骗和防御欺骗攻击维基百科说，所以这个包不会被归还给攻击者：

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

I have already asked a question about IP Authentication here: TastyPie Authentication from the same server

However, I need something more! An IP address could be very easily spoofed.

Scenario: My API (TastyPie) and Client App (in javascript) are on the same server/site/domain. My users don't login. I want to consume my API in my javascript client side.

Question: How can I make sure (authentication) that my AJAX requests are originating from the same server?

I'm using Tatypie. I need to authentication that the requests from the client are being made on the same server/domain etc. I cannot use 'logged in sessions' as my users don't login.

I have looked at private keys and generating a signature but they can viewed in the javascript making that method insecure. If I do it in a way to request a signature form the server (hiding the private key in some python code) anyone can make the same http request to get_signature that my javascript makes, thus defeating the point.

I also tried to have the Django view put the signature in the view eliminating the need to make the get_signature call. This is safe, but means that I have to now refresh the page every time to get a new signature. From a users point of view only the first call to the API would work, after which they need to refresh, again pointless.

I cannot believe I'm the only person with this requirement. This is a common scenario I'm sure. Please help :) An example using custom authentication in Tastypie would be welcome too.

Thanks

Added:

解决方案

Depending on your infrastructure @dragonx's answer might interest you most.

my 2c

You want to make sure that only if a client visits your website can use the api? Hmm does the bot, robot, crawler fall in the same category with the client then? Or am I wrong? This can be easily exploited in case you really want to secure it really.

I cannot believe I'm the only person with this requirement.

Maybe not, but as you can see you are prone to several attacks to your API and that can be a reason for someone not sharing your design and making security stricter with auth.

EDIT

Since we are talking about AJAX requests what does the IP part has to do with this? The IP will always be the Client's IP! So probably, you want a public API...

• I would Go with the tokens/session/cookie part.

• I 'd go with a generated token that lasts a little while and a flow described below.

• I'd go with a limiter per some time, like Github does. Eg 60 requests per hour per ip or more for registered users

To overcome the problem with the refreshing token I would just do this:

1. Client visits the site

   -> server generates API TOKEN INIT

   -> Client gets API TOKEN INIT which is valid only for starting 1 request.

2. Client makes AJAX Request to API

   -> Client uses API TOKEN INIT

   -> Server checks against API TOKEN INIT and limits

   -> Server accepts request

   -> Server passes back API TOKEN

   -> Client consumes response data and stores API TOKEN for further usage (Will be stored in browser memory via JS)

3. Client Starts Comm with the API for a limited amount of time or requests. Notice that you know also the init token date so you can use it to check against the 1st visit on the page.

The 1st token is generated via the server when the client visits. Then the client uses that token in order to obtain a real one, that lasts for some time or something else as of limitation. This makes someone actually visit the webpage and then he can access the API for a limit amount of time, requests perhaps etc.

This way you don't need refreshing.

Of course the above scenario could be simplified with only one token and a time limit as mentioned above.

Of course the above scenario is prone to advanced crawlers, etc since you have no authentication.

Of course a clever attacker can grab tokens from server and repeat the steps but, then you already had that that problem from start.

Some extra points

• As the comments provided please close writes to the API. You don't want to be a victim of DOS attacks with writes if you have doubts about your implementation(if not use auth) or for extra security
• The token scenario as described above can also become more complicated eg by constantly exchanging tokens

Just for reference GAE Cloud storage uses signed_urls for kind of the same purpose.

Hope it helps.

PS. regarding IP spoofing and Defense against spoofing attacks wikipedia says so packet's won't be returned to the attacker:

Some upper layer protocols provide their own defense against IP spoofing attacks. For example, Transmission Control Protocol (TCP) uses sequence numbers negotiated with the remote machine to ensure that arriving packets are part of an established connection. Since the attacker normally can't see any reply packets, the sequence number must be guessed in order to hijack the connection. The poor implementation in many older operating systems and network devices, however, means that TCP sequence numbers can be predicted.

这篇关于如何确保我的AJAX请求是源自同一台服务器的Python的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！