防止启用 silverlight 的 WCF 服务的 CSRF（或跨站点请求伪造/XSRF）
启用 silverlight 的 WCF 服务通信使用 USB 令牌/智能卡进行保护。首次访问必须通过输入 PIN 码进行确认。经过身份验证后，恶意网站可以使用 IMG 标签和/或 JavaScript 向 WCF 服务发起 CSRF 请求。根据编写和 部署 Silverlight 应用程序，这里常用的技术是使用（会话）令牌或所谓的“nonce”，而检查 HTTP Referrer 标头已被证明是不安全的。
我理解这背后的想法，据我了解，如果您有一个表单（即联系表单）和一个服务，您可以确保用户在发送之前必须查看并填写表单，那么它会很好地工作。在 Silverlight 应用程序中，我无法预定义此类顺序，许多请求（例如请求产品的价格更新）可以按任意顺序启动。
您对我应该如何保护 Silverlight 到 WCF 通信的安全以防止 CSRF 攻击、确保已通过身份验证的调用者从受信任的站点发出请求有什么建议吗？
The silverlight enabled WCF Service communication is secured using a USB token/smartcard. The first access has to be confirmed by entering a PIN. Once authenticated, a malicious website could start CSRF requests to the WCF service using IMG-Tags and/or JavaScript. According to the Security Guidance for Writing and
Deploying Silverlight Applications, a usual technique here is to use (session-)tokens or a so called "nonce", while checking the HTTP Referrer header has proven to be insecure.
I understand the idea behind this, to my understanding it works well if you have a single form (i.e. contact form) and a single service where you can ensure that a user has to see and fill out the form before sending. In a Silverlight application, I'm not able to predefine such kind of sequence, many requests (like requesting a price update for a product) can be started in an arbitrary order.
Do you have some advices how I should secure the Silverlight to WCF communication to prevent CSRF attacks, ensuring that an already authenticated caller requests from a trusted site?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一种选择可能是：
攻击者无法欺骗这一点，因为如果他调用提到的服务，他将为自己的会话获得不同的令牌。只要这个随机数没有存储在cookie中，浏览器就不会在向服务器发出请求时自动提交它。因此，只要攻击者无法猜测随机数（使用加密的安全随机数来生成它），这应该可行。
One option could be:
An attacker could not trick this, because if he called the mentioned service he would get a different token for their own session. And as long as this nonce is not stored in a cookie, it will not be automatically submitted by the browser upon requests to the server. So as long as the attacker cannot guess the nonce (use a cryptographically secure random to generate it), this should work.