安全的Web服务：HTTPS上的REST与SOAP + WS-Security。哪个更好？[关闭]

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

在创建需要具有数据传输功能的新服务时。关于哪种方法更安全，我们进行了辩论-使用HTTPS的REST或使用WS-Security的SOAP WS。

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

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

网络似乎遍地都是。

也许这里的社区可以权衡每个人的利弊？谢谢！

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

WS-Security提供从消息创建到消息使用的机密性和完整性保护。因此，不是确保通信的内容只能由正确的服务器读取，而是确保只能由服务器上的正确进程读取通信的内容。代替假定安全发起的会话中的所有通信都来自已认证的用户，每个通信都必须进行签名。

这里有一个涉及裸体摩托车手的有趣解释：

https://docs.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的开销。我知道这是一个解决方案，但是必须由精通此问题的人来决定实际上有多少保护措施是合理的（不仅仅是建立什么保护措施）。

REST安全与传输有关，而SOAP安全与传输无关。

REST从基础传输继承安全性措施，而SOAP通过WS-Security定义其自身的措施。

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

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

但是，使用WS-Security，它具有消息级别的安全性-即使消息离开传输通道，它仍将受到保护。另外-使用消息级安全性，您可以对消息进行部分加密（不是整个消息，而是仅加密所需的部分）-但是，对于传输级安全性，则不能加密。

WS-Security具有用于身份验证，完整性，机密性和不可否认性的措施，而SSL不支持不可否认性（它使用两足式OAuth可以支持）。

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

谢谢...

从技术上讲，您所说的方式都不正确，因为SOAP方法的通信不安全，并且REST方法没有说明对合法用户进行身份验证。

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

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

如果RESTful系统具有验证用户身份的方式，并且具有WS-Security的SOAP应用程序正在使用HTTPS，那么实际上两者都是安全的。这只是表示和访问数据的另一种方式。

参见维基文章：

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

但是，WS-Security解决了维护消息完整性和机密性的更广泛问题，直到从原始节点发送消息之后，才提供所谓的端到端安全性。

那是：

• HTTPS是传输层（点对点）安全机制
• WS-Security是一种应用程序层（端到端）安全性机制。

就像您说的那样，REST对银行来说足够好，因此对您来说也足够好。

安全有两个主要方面：1）加密和2）身份。

使用SSL / HTTPS进行传输可通过网络进行加密。但是，您还需要确保两个服务器都可以确认他们知道与谁交谈。可以通过SSL客户端证书，共享机密等。

我敢肯定，可以证明SOAP“更安全”，但可能没有任何重要意义。裸体电单车司机的比喻很可爱，但如果准确无误，则意味着整个互联网都是不安全的。

我还没有需要添加评论的代表，或者我只是将其添加到Bell的答案中。我认为Bell在总结这两种方法的最高优缺点方面做得很好。您可能还需要考虑其他一些因素：

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

2）实际上，可以使用SSL通过称为相互身份验证的功能向服务器提供有关客户端身份的保证。但是，由于配置它的复杂性，在某些非常特殊的情况下并没有太多用处。因此，贝尔说对了，WS-Sec在这里更合适。

3）很大程度上由于证书管理问题，一般来说SSL可能会影响设置和维护（即使是在简单的配置中）。拥有一个知道如何为您的平台执行此操作的人将是一大优势。

4）如果您可能需要进行某种形式的凭证映射或身份联合，则WS-Sec可能值得承担这些开销。并不是说您无法使用REST做到这一点，只是结构上的不足以帮助您。

5）将所有WS-Security难题放到客户端的正确位置，比您想象的要痛苦得多。

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

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

今天，我不得不向女友解释WS-Security与HTTPS的表达能力之间的区别。她是一名计算机科学家，因此即使她不了解所有XML混合语言（甚至比我更好），她也知道加密或签名的含义。但是我想要一个强大的形象，这可以使她真正了解事物的用途，而不是实现方式（后来出现了，她没有逃脱它:-）。

就像这样。假设您赤身裸体，并且必须将摩托车开到某个目的地。在（A）情况下，您通过了一条透明的通道：不因淫秽行为而被捕的唯一希望是没有人在看。那并不是您可以提出的最安全的策略……（请注意，男人额头上的汗水：-）。显然，这等效于POST，当我说“等效”时，是指它。在（B）情况下，您的情况更好。隧道是不透明的，因此只要您进入隧道，公共记录都是安全的。但是，这仍然不是最好的情况。您仍然必须离开家并到达隧道入口，一旦到达隧道外，您可能必须下车然后走到某个地方……这适用于HTTPS。真正，您的消息在遇到最大障碍时是安全的：但是，一旦您将消息传递到另一端，您实际上并不知道在到达要处理数据的实际点之前，它需要经历多少个阶段。当然，所有这些阶段都可以使用与HTTP不同的东西：例如，经典的MSMQ可以缓冲无法立即处理的请求。如果有人潜入您的数据而处于预处理阶段，该怎么办？嗯 （将此“ hm”读为Morpheus在句子“您认为呼吸的空气吗？”结尾处所说的那个。）。这个比喻中的完整解决方案（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. 证明邮件未在途（MITM）修改。
3. 允许服务器对客户端进行身份验证/授权。

最后一点对于服务请求很重要，如果客户端（呼叫者）的身份对于了解是否应该授权它们从服务接收此类数据至关重要。标准SSL是单向（服务器）身份验证，不执行任何操作来标识客户端。

答案实际上取决于您的特定要求。

例如，您是否需要保护您的Web消息，或者不需要保密，而您所需要做的只是验证最终方并确保消息的完整性？如果是这种情况（Web服务通常是这种情况），HTTPS可能是错误的锤子。

但是，根据我的经验，请不要忽视正在构建的系统的复杂性。不仅HTTPS易于正确部署，而且依赖传输层安全性的应用程序也易于调试（通过纯HTTP）。

祝好运。

只要API提供程序在服务器端实现授权，HTTP上的REST应该是一种安全的方法。同样在Web应用程序的情况下，我们要做的是通过HTTPS和某些身份验证/授权访问Web应用程序，传统上Web应用程序不存在安全问题，因此Restful API也可以毫无问题地解决安全问题！

如果您的RESTFul调用来回发送嵌入在HTTP请求的HTML正文中的XML消息，则在使用任何安全功能的同时，您应该能够在XML消息中获得WS-Security的所有好处，例如XML加密，证书等。可从http获得，例如SSL / TLS加密。