当服务与客户端在同一台 PC 上运行时的 WCF 安全性
我面临着一个 WCF 安全场景，该场景在网上没有特别详细的记录。
我正在 WCF 中开发一项产品许可服务，该服务将与我们的软件一起部署（即该服务与客户端在同一台 PC 上运行）。该许可服务将负责与控制我们软件的使用以及连接到我们的远程许可服务器进行更新、撤销等相关的许多事情。因此，这不是我想要欺骗的服务类型，而且我真的不想欺骗客户也可以与之通信。
由于它与客户端在同一台 PC 上运行，任何人都可以为这种情况建议安全策略吗？我对身份验证特别感兴趣，因为大多数其他安全原则都很简单。如果可以的话，我不愿意进入证书，但由于相互身份验证是一个优先事项，我开始认为我可能需要在服务和客户端之间实现自定义的“挑战/验证”方案。
有什么想法吗？感谢您的阅读。
克里斯.
I am faced with a WCF security scenario that isn't particularly well documented online.
I am developing a product licensing service in WCF that will be deployed along with our software (i.e. the service is running on the same PC as the client). This licensing service will be responsible for a number of things related to controlling use of our software and connecting to our remote licensing server for updates, revocations etc. Consequently it's not the kind of service I want spoofed, and I don't really want spoof clients communicating with it either.
As it's running on the same PC as the client can anyone suggest a security policy for this scenario? I'm particularly interested in authentication as most of the other security principles are straightforward. I'm reluctant to get into certificates if I can help it but as mutual authentication is a priority I'm beginning to think I may need to implement a custom 'challenge/verify' scheme between the service and client.
Any ideas? Thanks for reading.
Chris.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我的建议是，无论你为此付出多少努力，都会有一个攻击向量使你的所有努力变得无效。一种选择是使用 ILMerge 为整个应用程序提供单个 dll，并将其加密存储在磁盘上，并创建一个加载程序来命中传递注册信息的服务。在您这边，该服务将验证客户信息并发回解密密钥。加载程序将使用解密密钥解密内存中的 DLL 并动态加载它。
这种方法的缺点是，坚定的破解者可以调试您的应用程序，并且当 DLL 被解密时，将未加密的流写入磁盘。您唯一的报复方法是在 DLL 上放置某种标记，以便您可以识别谁对破坏您的复制保护负有责任，并在发现它在 Internet 上打开时采取法律行动。
My suggestion is that no matter how much effort you put into that, there will be an attack vector that makes all of your effort null and void. One option is to use ILMerge to provide a single dll for your entire application, and store it encrypted on disk and create a loader that hits your service passing in the registration information. On your side, the service will validate the customer information and send back a decryption key. The loader would use the decryption key to decrypt the DLL in memory and load it dynamically.
The shortcoming of this approach is that a determined cracker could debug your application and when the DLL is decrypted, write the unencrypted stream to disk. Your only means of retribution would be to place some kind of marker on the DLL so that you can identify who was responsible for breaking your copy protection and bring legal action if it's found open on the Internet.
只要您将此软件部署到客户端，您就无法在其中存储任何类型的密钥而不冒被泄露的风险。即使您使用证书，您也无法在对客户端隐藏它们的同时仍使它们对您的应用程序可见。如果您将钥匙嵌入组件本身，那么有人就会使用 Reflector 将其弹出。
假设您不关心彻底破解（即修补程序集的代码以简单地绕过许可证检查），那么有一种也是唯一一种正确的方法来实现这种类型的安全性，那就是模仿 PKI 的工作方式，通过使用专门的远程服务器。
在 PKI 中，当服务器需要通过证书验证客户端时，它会根据证书颁发机构的 CRL 检查该证书。如果 CRL 报告证书已吊销，则它拒绝访问。如果无法联系 CRL，则证书被视为无效。
如果您想实现此场景，那么您需要 3 个逻辑服务，但当前配置中不需要。您需要的是远程许可服务器、客户端和应用程序服务器。理论上，应用程序服务器可以驻留在客户端上，但此应用程序服务器的关键方面是它针对远程许可服务执行许可证检查并处理所有重要的应用程序逻辑。这样，“欺骗”服务器就几乎成为不可能的任务，因为随意的破解者必须在此过程中对整个应用程序进行逆向工程。
这比使应用程序服务器成为远程服务器的安全性要低得多，并且与简单地将远程安全检查嵌入到客户端本身并完全废弃本地应用程序/许可服务器相比，可能不会提供很多优势。但如果您决定采用这种 3 层方法，那么上述架构将是您的最佳选择。
再次强调，这是假设您不担心“直接”破解。如果是的话，那么您将必须阅读特定于该特定攻击媒介的技术，并了解它们都不是万无一失的；它们只能减慢攻击者的速度，而不能完全阻止他。
As long as you're deploying this software to the client, then you cannot store any kind of key inside it without risking compromise. Even if you use certificates, you cannot hide them from the client while still making them visible to your application. And if you embed the key in the assembly itself then someone will just pop it open using Reflector.
Assuming you don't care about outright cracking (i.e. patching the assembly's code to simply bypass the license checks), then there's one and only one correct way to implement this type of security and that is to mimic the way a PKI works, by using a remote server exclusively.
In a PKI, when a server needs to validate a client via a certificate, it checks that certificate against the certificate authority's CRL. If the CRL reports that the certificate is revoked then it refuses access. If the CRL cannot be contacted then the certificate is considered invalid.
If you want to implement this scenario then you need 3 logical services but not in your current configuration. What you need is a remote licensing server, a client, and an application server. The application server can, theoretically, reside on the client, but the key aspect of this app server is that it performs license checks against the remote licensing service and handles all of the important application logic. That way, "spoofing" the server becomes an almost impossible task because a casual cracker would have to reverse-engineer the entire application in the process.
This is significantly less safe than making the application server a remote server, and may not offer many advantages over simply embedding remote security checks in the client itself and scrapping the local app/licensing server completely. But if you are determined to take this 3-tier approach then the aforementioned architecture would be the way to go.
Again, this is assuming that you aren't worried about "direct" cracking. If you are, then you'll have to read up on techniques specific to that particular attack vector, and understand that none of them are foolproof; they can only slow an attacker down, never stop him completely.