高度缓存环境中 Ajax 中的安全令牌传递
问候 SO 社区！
我正在尝试思考高度缓存环境中 ajax 进程的安全问题，并且可以使用一些建议。我的情况是这样的：
- 网站的用户没有登录。
- 网站页面被高度缓存（通过 akamai）。
- 我有一个服务 API，可以通过 AJAX 从我域内的页面进行访问。
- 我需要保护该 API 不被在我的域之外使用。
我可以检查标头中传入的“主机”，以查看 ajax 请求是否来自我的域，但这似乎不安全，因为此类标头可能会被欺骗。另外，在我看来，通常的令牌传递方案对我不起作用，因为我的页面被缓存，所以我没有机会注入用户/请求特有的令牌（例如，如下所述：如何限制访问仅某些 PHP 页面从我网站内的页面？）。显然，在页面加载后通过 ajax 发出令牌请求是不安全的，所以我不确定如何实现这一点。我想我可以生成一个与页面一起加载的共享使用令牌，其生命周期是最大页面缓存生命周期的两倍，但似乎必须有更好的方法！
Greetings SO Community!
I'm trying to think through a security issue with an ajax process in a highly cached environment, and could use some advice. My situation is this:
- The users of the site are not logged in.
- The site pages are highly cached (via akamai).
- I have a service API that is to be accessed via AJAX from pages within my domain.
- I need to protect that API from being used outside of my domain.
I can check the incoming "host" in the headers to see if the ajax request came from my domain, but that seems insecure, as such headers could be spoofed. Also, it seems to me that the usual token passing scheme will not work for me because my pages are cached, so I don't have the opportunity to inject tokens unique to the user/request (e.g. as described here: How can I restrict access to some PHP pages only from pages within my website?). Clearly, it's insecure to make a token request via ajax after page load, so I'm not sure how to make this happen. I suppose I could generate a shared use token that loads with the page and has a lifetime twice that of my maximum page cache life, but it seems like there must be a better way!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你想实现什么目标？您是否试图防止跨站点请求伪造或某人\某物使用您的 API（不是您向用户提供的 javascript）？
前者是通过存储在页面源中的令牌来完成的。您可以通过在源代码（或创建令牌的某些代码）中添加令牌来使 XSRF 攻击变得困难。不幸的是，除非您可以将每个用户/请求的唯一数据获取到源中，否则有人总是可以获取您的源并对令牌进行逆向工程。然后他们就可以伪造请求。一般规则是除非用户已登录，否则不要担心它，因为攻击者可以自己访问该页面。
无论如何，后者（防止未经授权的使用）是不可能的。攻击者始终可以创建一个帐户，剥离她需要的令牌/密钥/凭证，然后在其服务器上使用某些 API。
What are you trying to accomplish? Are you trying to prevent cross site request forgery or someone\something from using your API that is not the javascript you served to the user?
The former is accomplished via tokens that are stored in the source of the page. You can make it hard to conduct an XSRF attack by having tokens in the source ( or some code that creates tokens). Unfortunately, unless you can get unique data per user/request into the source, someone can always just grab your source and reverse engineer the token. Then they can forge requests. The general rule is don't worry about it unless the user is loged in because the attacker could just go to the page themselves.
The later(preventing unauthorized use) is impossible in anycase. An attacker can always make an account, strip the tokens/keys/credentials she needs, and then use some API on their server.