安全 Web 服务: 基于 HTTPS 的 REST 与 SOAP + WS-Security。哪个更好？

无论如何，我不是一个安全专家，但是我喜欢创建 REST 风格的 Web 服务。

在创建一个新的服务，需要有数据传输安全。我们已经进入了一场关于哪种方法更安全的辩论——使用 HTTPS 的 REST 还是使用 WS-Security 的 SOAP WS。

我的印象是，我们可以对所有的 Web 服务调用使用 HTTPS，而且这种方法是安全的。我的看法是，“如果 HTTPS 对银行和金融网站足够好，对我来说也足够好”。再说一次，我不是这方面的专家，但我认为这些人已经非常认真地考虑过这个问题，并且对 HTTPS 非常满意。

一个同事不同意，并说 SOAP 和 WS-Security 是唯一的方法。

这件事上网络似乎无处不在。

也许这里的社区可以分享一下各自的优缺点? 谢谢！

227926 次浏览
小开

见 维基百科文章:

在点对点的情况下，还可以通过使用传输层安全性(Transport Layer Security，TLS)在 Web 服务上强制执行机密性和数据完整性，例如通过 https 发送消息。

然而，WS-Security 解决了在从原始节点发送消息之前保持消息的完整性和机密性这一更广泛的问题，提供了所谓的端到端安全性。

那就是:

  • HTTPS 是一种传输层(点到点)安全机制
  • WS-Security 是一种应用层(端到端)安全机制。
小开

从技术上讲，您使用它的方式也是不正确的，因为 SOAP 方法的通信是不安全的，而且 REST 方法没有说任何关于验证合法用户的内容。

HTTPS 防止攻击者在两个系统之间的通信中使用 偷听。它还验证主机系统(服务器)实际上是用户打算访问的主机系统。

WS-Security 防止未经授权的应用程序(用户)访问系统。

如果 RESTful 系统有一种验证用户的方法，而带有 WS-Security 的 SOAP 应用程序正在使用 HTTPS，那么两者都是安全的。这只是表示和访问数据的一种不同方式。

小开
最佳答案

HTTPS 保护消息在网络上的传输，并向客户机提供有关服务器身份的一些保证。这对你的银行或在线股票经纪人来说很重要。他们对认证客户端的兴趣不在于计算机的身份，而在于您的身份。因此，卡号、用户名、密码等都是用来验证你的身份的。然后，通常会采取一些预防措施，以确保提交的内容没有被篡改，但总的来说，会议中发生的任何事情都被认为是由您发起的。

WS-Security 提供了从创建消息到使用消息的机密性和完整性保护。因此，与其确保通信内容只能由正确的服务器读取，不如确保只能由服务器上正确的进程读取。与假设安全发起的会话中的所有通信都来自经过身份验证的用户不同，必须对每个通信进行签名。

这里有一个关于裸体摩托车手的有趣解释:

Https://learn.microsoft.com/archive/blogs/vbertocci/end-to-end-security-or-why-you-shouldnt-drive-your-motorcycle-naked

因此 WS-Security 提供了比 HTTPS 更多的保护，而 SOAP 提供了比 REST 更丰富的 API。我的观点是，除非您确实需要额外的特性或保护，否则应该跳过 SOAP 和 WS-Security 的开销。我知道这有点逃避，但是关于保护程度的决定(不仅仅是建造什么东西会很酷)需要由那些深知问题所在的人来做出。

小开

我还没有代表需要添加一个评论，否则我只会添加到贝尔的答案。我认为 Bell 在总结这两种方法的优缺点方面做得非常好。还有一些其他的因素，你可以考虑一下:

1)客户和服务之间的请求是否需要通过需要访问有效负载的中介？如果是这样，那么 WS-Security 可能更适合。

2)实际上，使用 SSL 可以通过一种称为相互认证的特性为服务器提供客户端身份的保证。然而，由于配置的复杂性，这在一些非常专业的场景之外并没有得到太多的使用。所以 Bell 是对的 WS-Sec 更适合这里。

3)由于证书管理问题，SSL 的设置和维护(即使是在更简单的配置中)通常都有点麻烦。拥有一个知道如何为你的平台做这些的人将是一个很大的优势。

4)如果您可能需要进行某种形式的凭证映射或身份联合，那么 WS-Sec 的开销可能是值得的。并不是说您不能使用 REST 来完成这项工作，只是可以使用的结构较少。

5)把所有的 WS-Security 黏糊糊的东西放到客户端的正确位置可能比你想象的更痛苦。

尽管最终它确实取决于很多我们不太可能知道的事情。在大多数情况下，我会说这两种方法都是“足够安全的”，因此这不应该是主要的决定因素。

小开

答案实际上取决于您的具体要求。

例如，您是否需要保护您的 Web 消息，或者不需要保密性，而您所需要的只是对最终方进行身份验证并确保消息的完整性？如果是这样的话—— Web 服务通常都是这样的—— HTTPS 可能是错误的选择。

然而，根据我的经验，不要忽视您正在构建的系统的复杂性。不仅 HTTPS 更容易正确部署，而且依赖于传输层安全性的应用程序更容易调试(通过普通 HTTP)。

祝你好运。

小开

正如您所说的，REST 对银行来说已经足够好了，所以对您来说也应该足够好了。

安全性有两个主要方面: 1)加密和2)身份。

在 SSL/HTTPS 中传输提供了通过线路的加密。但是您还需要确保两个服务器都能确认它们知道正在与谁通话。这可以通过 SSL 客户端证书、共享机密等。

我确信有人会说 SOAP“更安全”，但可能没有任何重要的意义。裸体摩托车手的比喻很可爱，但如果准确的话，就意味着整个互联网都是不安全的。

小开

REST 安全性依赖于传输，而 SOAP 安全性不依赖于传输。

REST 从底层传输继承安全措施，而 SOAP 通过 WS-Security 定义自己的安全措施。

当我们谈论 REST 时，通过 HTTP-所有应用 HTTP 的安全措施都是继承的，这称为传输级安全。

传输级安全性，仅当消息在线上时保护您的消息-一旦消息离开线，消息就不再安全。

但是，对于 WS-Security，它的消息级安全性——即使消息离开了传输通道，它仍然受到保护。另外，使用消息级安全性，您可以对消息进行部分加密(不是整个消息，而只是您想要的部分) ，但是使用传输级安全性，您无法完成这项工作。

WS-Security 具有身份验证、完整性、机密性和不可否认性措施，而 SSL 不支持不可否认性(它支持2条腿的 OAuth)。

在性能方面，SSL 比 WS-Security 快得多。

谢谢..。

小开

如果您的 RESTFull 调用来回发送嵌入在 HTTP 请求的 Html 主体中的 XML 消息，那么您应该能够在您的 XML 消息中获得 WS-Security 的所有好处，比如 XML 加密、证书等等，同时使用从 HTTP 获得的任何安全特性，比如 SSL/TLS 加密。

小开

只要 API 提供者实现了服务器端的授权，REST Over HTTPS 应该是一种安全的方法。在 Web 应用程序的情况下，我们所做的就是通过 HTTPS 和一些认证/授权来访问 Web 应用程序，传统的 Web 应用程序没有安全问题，那么 Restful API 也可以毫无问题地解决安全问题！

小开 
Brace yourself, here there's another coming :-)

今天我不得不向我的女朋友解释 WS-Security 和 HTTPS 在表达能力上的区别。她是一个计算机科学家，所以即使她不知道所有的 XML 胡言乱语，她也理解(也许比我更好)什么是加密或签名。然而，我想要一个强大的形象，这可以让她真正理解什么东西是有用的，而不是他们是如何实现的(后来，她没有逃避它:))。

所以是这样的，假设你是裸体的，你必须把你的摩托车开到一个特定的目的地。 在第一种情况下，你通过一个透明的隧道: 你不会因为淫秽行为而被逮捕的唯一希望是没有人在看。这可不是你能想出来的最安全的策略... ... (注意男人额头上的汗珠: ——)。这相当于一个 POST 的 clear，当我说“等价”的时候，我是认真的。 在(B)的情况下，你的处境更好。隧道是不透明的，所以只要你进入其中，你的公共记录是安全的。然而，这仍然不是最好的情况。你仍然必须离开家，到达隧道入口，一旦出了隧道，你可能不得不下车，走到某个地方... HTTPS 也是如此。诚然，当你的信息跨越最大的鸿沟时，它是安全的: 但是一旦你把它传递到另一边，你真的不知道在到达真正的数据处理点之前，它将经历多少个阶段。当然，所有这些阶段都可以使用与 HTTP 不同的东西: 例如，经典的 MSMQ 可以缓冲无法立即提供服务的请求。如果有人潜伏在你的数据当他们在预处理地狱时会发生什么？嗯。(把这个“ hm”读作莫斐斯在句末所说的“你认为你呼吸的是空气吗?”). 这个比喻中的完整解决方案(c)是微不足道的，令人痛苦: 给自己穿上一些该死的衣服，特别是在骑摩托车时戴上头盔! ! ！因此，你可以安全地四处走动，而不必依赖于不透明的环境。希望这个比喻是清楚的: 不管平均值或周围的基础设施如何，服装都随身携带，就像消息级别的安全性一样。此外，你可以决定遮盖一部分，但暴露另一部分(你可以在个人基础上这样做: 机场安检可以脱掉你的夹克和鞋子，而你的医生可能有更高的访问级别) ，但记住，短袖衬衫是不好的做法，即使你为你的二头肌感到自豪: (更好的马球，或 T 恤)。

我很高兴地说，她明白我的意思了！我不得不说，衣服的比喻是非常有力的: 我很想用它来引入政策的概念(迪斯科俱乐部不允许你穿运动鞋; 你不能穿着内衣去银行取钱，而这是完全可以接受的外观，同时在冲浪中保持平衡; 等等) ，但我认为一个下午就足够了; -)

架构-WS，狂野的想法

提供者: http://blogs.msdn.com/b/vbertocci/archive/2005/04/25/end-to-end-security-or-why-you-shouldn-t-drive-your-motorcycle-naked.aspx

小开

我每天都在这个空间工作，所以我想总结一下对这个问题的好评，以便结束这篇文章:

SSL (HTTP/s)只是确保:

  1. 连接到的服务器提供一个证明其 身份(虽然这可以通过 DNS 中毒欺骗)。
  2. 通信层是加密的(没有窃听)。

WS-Security 及相关标准/实现使用 PKI:

  1. 证明客户的身份。
  2. 证明邮件未被修改 过境运输。
  3. 允许服务器对 客户。

最后一点对于服务请求非常重要，因为客户端(调用方)的身份对于了解它们是否应该被授权从服务接收此类数据至关重要。 标准的 SSL 是单向(服务器)身份验证，不执行任何识别客户端的操作。


提交答案