此Web服务体系结构的特定安全风险是什么？

Question

我需要弹药来尝试推广WS-Security一组外部可用的Web服务，这些服务直接与我们的生产客户服务应用程序交互。我的愿景是实施IPassword提供商并通过我们的AD商店进行身份验证。从高处降低的体系结构建议是SSL，路由器上的IP过滤器仅允许某些IP地址调用Web服务。将使用GUID密钥授予访问权限。无需登录或密码。

将授予授权访问我们的Web服务的每个合作伙伴密钥。它将由我们生成，并可能通过电子邮件发送给他们。我没有知道的过期政策。

这对我来说是错误的，但他们并没有购买我的论点，即这里没有实际的身份验证。这种架构有哪些特定的安全风险？究竟什么样的攻击场景是可能的，破坏我们的系统有多容易？我需要能够详细说明风险，甚至可能向我们的架构团队展示它们。

Answer 1

嗯......这里有太多可能出错......

例如，SSL服务器证书仅保护您免受正常的窃听，并且如果正确完成了服务器的身份。它不能确保客户是谁。 （我假设您正在对客户端上的服务器证书进行适当的安全检查）。

但这告诉服务器没有关于客户端的信息。为此，您还需要分配客户端证书并在服务器上对其进行验证，如果操作不正确，此解决方案仍然容易受到man in the middle attacks的攻击。<​​/ p>

返回您的配置。如果您的服务器证书验证未正确完成，则不仅可以窃听，还可以注入/修改您的通信渠道上的信息（因为您没有对邮件本身执行任何签名以验证其未被修改）。

IP过滤器非常弱，因为大多数机构都有一些NAT或Proxy配置用于外部访问。因此，通过同一节点进行外部访问的PC将显示相同的IP。因此，不需要“欺骗”......你只需要妥协任何内部机器......就像秘书的机器（咯咯笑）......并从那里提出请求。

IP欺骗我不确定是一种有效的攻击，在这种情况下，攻击者会在客户端计算机上导致拒绝服务，然后尝试连接到服务器伪造数据包并利用欺骗客户端无法响应和rst数据包终止连接。

这意味着猜测包裹序列号，现在这很难，但并非不可能。从那里攻击者可以盲目地注入他需要的任何消息，但在这种情况下，因为连接不是简单的html，而是一个ssl流，涉及交换信息，如密钥等，并且鉴于攻击者无法看到，因为注入是盲目进行的（至少除非它在同一个子网中并且可以嗅探数据包）...我怀疑它是否可能。

无论如何......推荐的配置。

1 - 服务器SSL证书，在客户端上进行验证。 - 客户端SSL证书，在服务器上进行验证。 - 除了GUID令牌之外的某种消息校验和..我建议每次为每个会话客户端生成。 （别忘了在加密的商店pkcs12等上安全地分发这些证书，否则这种方法很容易受到中间人的攻击）

2 - 使用WS-Security扩展Web服务soap消息，并使用客户端和服务器签名/ encription与客户端和服务器证书，并使用时间戳服务。

你仍然可以绑定连接...但是没有必要......而且它仍然很弱。

另一方面，Kevin Mitnick在1994中使用了IP欺骗对抗Shimomura ...所以这是可能的，而不是非常困难。我敢打赌，根据您的服务器操作系统版本，有一些工具可以自动完成大部分流程。

我喜欢听别人的想法。希望这会有所帮助。

Answer 2

您的GUID / SSL方法有漏洞。可以使用欺骗IP地址的功能，如果使用GUID密钥截取电子邮件 - 您已被入侵。

WS-Security是一个既定的协议，这意味着它已被安全研究人员和博士学位研究和敲定。这些是实施安全措施时要信任的人。家庭烘焙安全几乎总是存在严重缺陷。

Answer 3

根据您检查IP地址的方式，可能很容易欺骗这些地址：

http://en.wikipedia.org/wiki/IP_address_spoofing

Answer 4

这很安全。在路由器级别欺骗IP地址非常困难，并且是银行的常见安全方法。通过路由器上的ip地址将其锁定，您可以确定您知道哪些组织将访问您的Web服务。

这听起来像是一个双因素身份验证方案，但要说它是“气密性的”，我必须听到更多有关guid密钥以及如何实现的信息。每个人都会使用相同的密钥，或者访问Web服务的每个人/应用程序是否会有所不同？

他们的做法看起来确实很合理。 IP地址充当“用户名”，guid表示传统用户名/密码模型中的“密码”。堆栈该级别的IP地址非常难以欺骗，因为IP地址基本上由ISP验证。在上游欺骗IP地址可能会导致DOS经验不足，但实际上欺骗IP在您的服务和“流氓”客户端之间打开是非常困难的。

最安全的方法是在路由器上使用IP过滤将两者结合起来，并通过SSL强制使用用户名和密码。

Answer 5

你可能正在打一场失败的战斗。

没有安全是万无一失的 - 如果你建立它，有人可以打破它。安全级别取决于您所保护的内容和手头的资源。对于许多应用，所提出的解决方案非常合理。有资源破解它的人有资源破解你的解决方案。破解前者可能更难。

另一个问题是资源。也许操作团队可以更好地处理安全问题。简而言之，即使有最好的论据，你也可能不会占上风。