为什么RPC over HTTP存在安全问题？

Question

我目前正在阅读Web服务。 http://www.w3schools.com/soap/soap_intro.asp上有一个SOAP教程。以下段落来自该页面：

  

“今天的应用程序在DCOM和CORBA等对象之间使用远程过程调用（RPC）进行通信，但HTTP不是为此而设计的.RPC表示兼容性和安全性问题;防火墙和代理服务器通常会阻止此类流量。”

我不明白这一点。请有人向我解释一下。特别是我想知道，为什么RPC是一个安全问题（至少通过HTTP）。知道为什么这是一个兼容性问题也会很好。

Answer 1

他们提出的观点是“传统RPC”有时使用不常见的低级网络协议，这些协议通常会被企业防火墙阻止。因为SOAP使用HTTP，所以它的流量与普通网页视图“无法区分”，因此不会被这些防火墙捕获。 我不太确定安全点，我认为他们可能暗示HTTP可以通过HTTPS轻松保护，而专有的RPC协议通常不会。当然，这是依赖于协议的，并非所有RPC协议都是不安全的，并且其中许多协议可以通过HTTPS进行隧道传输。

Answer 2

关于兼容性，问题在于，使用DCOM与使用CORBA的东西进行对话并不明显。 SOAP的目标之一是提供互操作性，以便协调这种通信的实现方式。 （关于与SOAP的互操作性，可能仍然存在一些问题，具体取决于您使用的工具。）

关于安全性，很长一段时间以来，围绕使用端口号来区分应用程序已经制定了策略：如果要阻止某个服务（比如NNTP），则会在防火墙级别阻止其端口。它可以很容易地对可以使用哪些应用程序进行粗略控制。 SOAP over HTTP的作用是在上面的层面推动问题。您无法再从TCP级别的端口号区分使用哪个应用程序或服务，而是必须能够分析HTTP消息的内容和SOAP消息以授权某些应用程序或服务。

SOAP主要使用HTTP POST发送消息：使用HTTP作为传输协议，而HTTP是传输协议，因此不使用HTTP根据Web体系结构（SOAP 2可能试图改善这种情况）。因为现在几乎每个人都需要访问网络，所以几乎可以保证HTTP端口不会被阻止。如果在此之上没有添加安全层，那么这实际上是使用了一个环洞。 这就是说，就安全性而言，使用HTTP进行SOAP通信具有优势，因为例如在现有HTTP认证系统方面存在更多协调。 SOAP / WS- *堆栈尝试做的是协调“RPC”通信，独立于平台。这不是“SOAP是安全的”v。的情况。 “DCOM / CORBA不是”，您仍然必须使用其安全组件，例如： WS-Security，您也可以通过其他系统实现合理的安全级别。