具有自定义基本身份验证的 WCF 安全性答案

【问题标题】：WCF Security with Custom Basic Authentification具有自定义基本身份验证的 WCF 安全性
【发布时间】：2013-12-04 22:08:31
【问题描述】：

我已经使用自定义基本身份验证在我的 RESTFUL WCF 服务中设置了安全性（因此停用了 iis 基本身份验证并且根本不使用 Windows 帐户登录；我的服务由 iis 托管）使用以下链接。

blog link

我了解消费者必须实现客户端才能在请求标头中传递凭据。

它是基于 64 位的编码，我们可以在调试时看到在 firebug 网络选项卡中传递的凭据（它始终是相同的字符串编码相同的凭据......）

因此，此外，为了加强安全性，我将添加 SSL 来加密 url：

https://myrestfulserviceurl.com/Method

现在消费者问我为什么我们不把登录名和密码放在 url 请求中，即

https://myrestfulserviceurl.com/Method?login=XXX&password=YYY （也与 SSL 结合使用）

因此更改需要在我的操作合同中添加登录名和密码作为参数，并在我的方法“方法”中调用一个方法进行身份验证..等

我的问题是：

自定义基本身份验证（请求标头中的凭据）和简单地在参数中的 url 中传递凭据之间有什么区别（两种方案都将使用 ssl）？

我的意思是：我只是在问自己为什么要费心实施基本身份验证。在 url 或 header 中传递凭据看起来很相似：它在请求中传递东西。但是从安全性的角度来说，看起来是一样的？

除了基于 64 位的编码之外，基本身份验证看起来并不安全。

如果我错了，请纠正我。

我只是在寻找实施自定义基本身份验证的原因。

有什么想法/建议吗？谢谢

【问题讨论】：

标签： wcf security rest ssl basic-authentication

【解决方案1】：

想到的主要区别在于数据的可见性和可能保留多长时间。

例如，假设 SSL 在您的应用程序服务器上终止，get 参数中的值可能会自动记录到您的文件系统（例如在请求日志中）。在那里有用户名和密码并不理想，因为它更容易被泄露。

如果 SSL 在负载平衡器或某些类似代理处终止，则用户名和密码可能会保存在服务器上的请求日志中，您可能不会考虑并且可能无法控制。

相比之下，身份验证标头不太可能被记录到您不期望的位置。

【讨论】：

【解决方案2】：

我自己考虑过这样做并决定不这样做，因为我希望 Restful URL 只关注操作并保持安全性，例如我可能想在不同的应用程序上重用相同的代码。

我也不确定，但我认为重放攻击可能存在安全隐患，如果有人获得了链接，那么他们可以在任何 http 客户端中执行它。如果您在 http 标头中使用了 authroisation 属性，您可以通过在其上设置过期时间来避免这种情况。另外我认为最好从 html 页面正文中隐藏这些信息。

写这个http://lbadri.wordpress.com/2012/07/30/anatomy-of-a-simple-web-token-swt/的家伙，取自他的书“Pro ASP.NET web Security”。给出了一个相当不错的创建令牌示例，然后您可以在 http 标头“授权”中使用该令牌，例如：Authorization: Basic d2FsaWRAGssSGZ21haWwuY29tOn236dhbGlk

【讨论】：