通过GUID保护AJAX请求 [英] Securing AJAX Requests via GUID
问题描述
我正在写一个web应用程序将使得通过AJAX请求，并想锁定这些调用。经过一段时间的研究，我正在考虑使用某种形式的随机令牌（字符串）被传递回连同请求（GUID？）。这是我的算法的重要组成部分：
I'm writing a web app that will be making requests via AJAX and would like to lock down those calls. After a little research, I am considering using some form of random token (string) to be passed back along with the request (GUID?). Here's the important parts of my algorithm:
- 分配令牌到JavaScript变量（服务器端生成）。
- 另外，存储，令牌在一个数据库，并给它一个有效的时间段（比如10分钟）。
- 如果令牌仍未被使用，是在它的有效时间窗口，允许呼叫。
- 在返回所需的信息，如果有效，否则，登录请求，并忽略它。
通过着眼于安全性，这是否有道理？对于令牌，将一个GUID的工作 - 它应该是别的东西吗？有没有在请求加密变量的好办法？
With an eye toward security, does this make sense? For the token, would a GUID work - should it be something else? Is there a good way to encrypt variables in the request?
编辑：
据我所知，这些AJAX请求不会是真正的安全，但我想在我想prevent其他人使用我打算写的服务意识增加基本保障。这个随机令牌将是一个基本的，一线反对滥用电话防御。这将要求（甚至提交产生这样的数据）将数据是极不可能被重复。
I understand that these AJAX requests wouldn't be truly "secure" but I would like to add basic security in the sense that I would like to prevent others from using the service I intend to write. This random token would be a basic, front-line defense against abusive calls. The data that would be requested (and even submitted to generate such data) would is HIGHLY unlikely to be repeated.
也许我错了，在使用GUID ...怎么样一个随机生成的字符串（标记）？
Maybe I'm wrong in using a GUID... how about a randomly generated string (token)?
推荐答案
如果你这样做是为了信任你发送到客户端浏览器，code，然后换方向。你真的不想相信用户输入，包括你发送到浏览器的JS调用。在服务器上的逻辑应该做这样没有错能经过那里完成。这就是说，asp.net采用的是签约现场，你可能希望走那条路，如果绝对必要的。
If you are doing this to trust code that you sent to the client browser, then change direction. You really don't want to trust user input, which includes calls from js that you sent to the browser. The logic on the server should be made so that nothing wrong can be done through there. That said, asp.net uses a signed field, you might want to go that way if absolutely necessary.
扩展一下： Asp.net篡改样张视图状态，它被作为一个HTML隐藏字段（取决于配置）。我相信有更好的联系作为参考，但至少它被提及在这一个：的 http://msdn.microsoft.com/en-us/library/ms998288.aspx
Expanding a bit: Asp.net tamper-proofs the viewstate, which is sent as a html hidden field (depending on the configuration). I am sure there are better links as reference, but at least it is mentioned on this one: http://msdn.microsoft.com/en-us/library/ms998288.aspx
验证。这指定的散列 算法用于产生HMACs到 使视图状态和形式 身份验证票证防篡改。 该属性还用于指定 用于加密算法 ViewState的加密。此属性 支持以下选项：
validation. This specifies the hashing algorithm used to generate HMACs to make ViewState and forms authentication tickets tamper proof. This attribute is also used to specify the encryption algorithm used for ViewState encryption. This attribute supports the following options:
- SHA1-SHA1用于防篡改 ViewState的，如果配置后， 窗体身份验证票。当SHA1 被选择用于验证 属性，使用的算法是 HMACSHA1。
- SHA1–SHA1 is used to tamper proof ViewState and, if configured, the forms authentication ticket. When SHA1 is selected for the validation attribute, the algorithm used is HMACSHA1.
这是该算法的http://msdn.microsoft.com/en-us/library/system.security.cryptography.hmacsha1.hmacsha1.aspx.
更新2： 对于防篡改要签名的数据（不加密的话）。需要注意的是，一般使用加密技术时，你应该避免使用自定义实现或算法。至于步骤，我会坚持到：
Update 2: For tamper-proofing you want to sign the data (not encrypt it). Note that when using cryptography in general, you should really avoid using a custom implementation or algorithm. Regarding the steps, I would stick to:
- 分配令牌到JavaScript变量（服务器端生成）。 你有信息来确定的要求和确切日期和放大器，其发行时间。签名将验证服务器端应用程序发出的数据。的
- 在确定双的提交如果合适的话。
这表示，之所以asp.net验证视图状态默认情况下，是因为开发者依靠信息即将在那里，因为只有被处理的应用程序时，他们不应该。同样可能适用于你的情况下，不要依赖这个机制。如果你要评估一个人是否可以做一些使用认证+授权。如果您想了解Ajax调用发送唯一有效的选择，对其进行验证。不要暴露在超过一个，你可以适当授权的操作粒度级别的API。这种机制只是一个额外的措施，以防滑倒的东西，而不是一个真正的保护。
That said, the reason asp.net validates the viewstate by default, is because devs rely on info coming in there as being handled only by the application when they shouldn't. The same probably applies for your scenario, don't rely on this mechanism. If you want to evaluate whether someone can do something use authentication+authorization. If you want to know the ajax call is sending only valid options, validate them. Don't expose an API at granularity level than the one where you can appropriately authorize the actions. This mechanism is just an extra measure, in case something slipped, not a real protection.
诗。与上述HMACSHA1，你会实例化它有固定的关键
Ps. with the HMACSHA1 above, you would instantiate it with a fixed key
这篇关于通过GUID保护AJAX请求的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
