我用web api2开发了一个web应用程序。
我的客户端应用程序是一个使用c#、。net 4.0开发的windows应用程序。客户端应用程序向web api应用程序发送一些Json数据，应用程序将数据存储在数据库中。
现在的问题是用另一种方法发送请求，除了我的应用程序和发送转储数据到服务器。我在服务器上有身份验证，但这还不够，我需要一些令牌来处理这个问题。
经过一番搜索，我找到了这篇文章并阅读了它，但客户端是一个web应用程序。我可以使用这种方法在我的windows客户端应用程序?如何?
底线:你不需要。
根据定义，CSRF攻击只能影响跨域共享cookie的客户端应用程序。例如，如果您使用浏览器访问www.bank.com，然后打开另一个选项卡到www.evil.com，如果www.bank.com不保护CSRF，那么www.evil.com可能能够在您登录时向www.bank.com提交表单，然后通过在转账页面上伪造请求到form的action URL来转账。
如果你的客户端是一个Windows应用程序，HTTP客户端不应该存储除了你的web API以外的任何其他服务的cookie。
请注意，上述内容仅适用于将cookie用作会话管理机制时(即不适用Kerberos、NTLM、Basic Auth等)。
。我在服务器上有身份验证，但这还不够
这应该足够了，因为攻击者不能伪造一个HTTP请求到你的API，这个请求将与受害者的cookie一起发送，因为cookie是分开的，因为有不同的web客户端实例。就像在Chrome浏览器上登录谷歌，然后在Firefox浏览器上访问谷歌一样，你不会共享相同的登录会话。
当然，使用HTTPS保护您的API，以便信息在传输过程中加密。请注意，这并不能防止源代码的反编译，而反编译是不容易防止的。在一天结束的时候，你不能信任那些不在你控制之下的客户。你可以让它变得很困难，但不是不可能阻止别人工作或更改正在发送到你的API的内容。
跨站点防伪令牌是一种身份验证形式。它对发送请求的客户端进行身份验证:客户端必须访问某个页面才能从服务器获得令牌，因此不能是任何未访问该页面的客户端，并且以某种方式向该服务器发送随机数据。
身份验证的目的是让服务器对客户端进行身份验证(其他方式也是可能的，但让我们暂时忘记这一点)。你设置的系统使得其他人很难假装是你的Windows窗体应用程序。注意，这可能非常困难，但从理论上讲，它总是可能被伪造的。因此，目标是建立一个验证，使攻击者认为发起攻击是不切实际的。
此验证不应与验证人类用户的身份验证混淆。它们是不同的。应用程序可以为人类用户提供登录UI，但应用程序不是由您编写的。所以你需要验证两件事:
- 请求实际上来自你的应用程序，如果成功，则
- 人类用户是他声称他是谁，否则
- 拒绝请求