WinForms客户端和共享主机Web服务器之间的WCF安全性

嗯

我开发了这个WinForms客户端，它通过WCF调用与服务器（ASPX应用程序）交互。我现在想将服务器部署到我的共享Web主机上，但我对WCF有点陌生，尤其是它背后的安全可能性

其目标是某种程度上保护WCF服务，以便不是所有知道或发现端点地址的人都可以调用它。相反，只有我的WinForms客户端才能调用WCF服务

我不需要基于用户的身份验证，因此不需要来自客户端用户的身份验证但我只希望此WinForms客户端的实例能够与服务交互。服务器和客户端之间传递的信息不是非常敏感，因此实际上不需要对其进行保护，但如果可以轻松实现，这将是一个加号

在共享主机（IIS）环境中（不使用HTTPS）是否可能实现这一点？我应该使用什么绑定和选项？我想是wsHttpBinding，但是如何设置安全选项呢

使用.NET4.0

---

谢谢

您首先需要问自己：“如果有人连接了自己的定制客户端，他们可以对您的WCF服务做些什么？”查看通过WCF公开的所有功能，并假设可以随意访问它您对客户完全没有控制权，您永远也不会拥有这种能力。

HTTPS是美丽的，这是一个该死的耻辱，你被迫易受攻击。如果这取决于我，我会搬到另一个关心安全的主机。如果你在网络上抛出用户名和密码，那么你的行为会使你的用户处于危险之中

我在WCF服务中看到的最大问题之一是，它们有一个“executeQuery（）”函数被公开。允许客户机生成由服务器执行的查询的开发人员。这种方法存在根本缺陷，因为您只是将数据库交给了攻击者。这种类型的漏洞不是SQL注入，它属于

沿着与CWE-602相同的路线。攻击者可以通过提供不同的用户id来欺骗您的WCF服务，使其认为是另一个用户吗？你相信客户会说实话吗

---

您必须考虑的下一个漏洞分类是“污染和沉没”。例如，如果您正在公开一个函数，其中一个参数正在调用

cmd.exe

的

CreateProcess（）

中使用。此参数可能由攻击者控制，对于此变量，调用

CreateProcess（）

是一个“接收器”。这些方面存在许多类型的漏洞，包括但不限于：；SQL注入、LDAP注入、XPATH注入。这些类型的漏洞影响所有web应用程序

据我所知，您有一个面向互联网的服务，您希望仅限于您的客户端应用程序才能呼叫-正确吗？或者您是否设想其他客户端（如PHP、Ruby等）也希望在某个时候调用您的服务

要保护您的邮件，您在WCF中有两个选项-邮件或传输安全。在internet上，由于客户端和服务之间的跳数未知，传输安全性无法工作-只剩下消息安全性（在消息通过“网络”时对其进行加密）。为了实现这一点，您通常向服务（仅服务器端）添加一个数字证书，客户端可以使用该证书发现并加密消息。只有您的服务才能解密它们-因此您在这方面是安全的

下一点是：谁可以打电话给你的服务？如果您想对任何人完全开放，那么是的，您需要

wsHttpBinding

（或者RESTful变体-

webHttpBinding

）。如果您希望允许非.NET客户端，通常不允许进行身份验证（任何人都可以调用），也不允许使用用户名/密码方案，您将在服务器端对有效用户数据库进行验证

如果您只想允许自己的.NET客户端进入，则可以执行以下几项操作：

• 禁用服务上的元数据；这样，您就可以“隐藏”您的端点和它们提供的服务—有人使用“元数据扫描程序”（如果存在的话）不能只是偶然发现您的服务并找出它提供的方法等。但是，这也使得您组织之外的其他开发人员无法向您的服务添加服务引用

• 您可以定义并使用自定义二进制http绑定—只有使用此设置的其他客户端才能调用您的服务。二进制http绑定也会带来一些速度改进。有关如何执行此操作，请参见此

• 您需要以某种方式识别允许的调用方-一种可能的方法是在WCF消息中添加一个额外的头，然后在服务器端进行检查。这将确保发现您的服务并发现二进制http绑定的临时黑客仍然会被拒绝（至少在一段时间内）。有关如何为WCF实现这样的消息检查器扩展，请参见本文

• 最终的步骤是在客户机上安装数字证书以及您的服务。然后，您将设置客户端代理以使用该证书对服务进行身份验证。只有拥有该证书的客户端计算机才能调用您的服务

---

这实际上取决于你想走多远——WCF为你提供了很多选择，但你需要决定你想为此付出多少努力。

我无意与其他客户共享此服务，尤其是非.NET客户。考虑到这一点，以及4个可能