【问题标题】:What are the specific security risks of this web services architecture?这种 Web 服务架构的具体安全风险是什么?
【发布时间】:2009-10-20 15:00:34
【问题描述】:

我需要弹药来尝试推广WS-Security 以获得一组直接与我们的生产客户服务应用程序交互的外部可用网络服务。我的愿景是实现 IPassword 提供程序并通过我们的 AD 商店进行身份验证。从高层下来的架构建议是 SSL,在路由器上带有一个 IP 过滤器,只允许某些 IP 地址调用 Web 服务。将使用 GUID 密钥授予访问权限。无需登录名或密码。

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

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

【问题讨论】:

  • 能否详细说明 GUID 键部分。

标签: .net web-services architecture ws-security


【解决方案1】:

嗯...这里有很多可能出错的地方...

一方面,SSL 服务器证书只能保护您免受正常窃听,如果操作正确,还可以保护服务器的身份。它不能确定客户是谁。 (我假设您正在对客户端上的服务器证书进行适当的安全检查)。

但这不会告诉服务器有关客户端的任何信息。为此,您还需要分配一个客户端证书并在服务器上对其进行验证,即使如此,如果没有正确完成,此解决方案仍然容易受到man in the middle attacks 的攻击。

回到您的配置。如果您的服务器证书验证未正确完成,则有人不仅可以窃听而且还可以注入/修改您的通信通道上的信息(因为您没有对消息本身执行任何签名以验证它没有被修改)。

IP 过滤器很弱,因为大多数机构都有一些NATProxy 配置供外部访问。因此,通过同一节点进行外部访问的 pc 将显示相同的 IP。所以不需要“欺骗”......你只需要破坏任何内部机器......就像秘书的机器(咯咯笑)......然后从那里提出请求。

我不确定 IP 欺骗是否是有效的攻击,在这种情况下,攻击者会在客户端机器上造成拒绝服务,然后尝试连接到服务器伪造数据包并利用被欺骗的客户端无法响应并首先发送数据包以终止连接。

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

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

1 - 在客户端验证的服务器 SSL 证书。 - 在服务器上进行验证的客户端 SSL 证书。 - 消息的某种校验和,除了 GUID 令牌.. 我建议每次为每个会话客户端生成。 (不要忘记在加密存储 pkcs12 等上安全地分发此证书,否则这种方法容易受到中间人攻击)

2 - 使用 WS-Security 扩展 Web 服务肥皂消息,并使用客户端和服务器签名/加密与客户端和服务器证书,并使用时间戳服务。

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

在旁注中,Kevin Mitnick 在1994 中使用 IP 欺骗攻击 Shimomura...所以这是可能的而且不是非常困难。我敢打赌,根据您的服务器操作系统版本,已经有一些工具可以自动化大部分过程。

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

【讨论】:

    【解决方案2】:

    您的 GUID/SSL 方法有漏洞。可以使用欺骗 IP 地址的功能,如果使用 GUID 密钥拦截电子邮件 - 您就被盗用了。

    WS-Security 是一个成熟的协议,这意味着它已经被安全研究人员和博士研究和锤炼过。这些是实施安全措施时值得信赖的人。而家庭出品的安全几乎总是存在严重缺陷。

    【讨论】:

      【解决方案3】:

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

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

      【讨论】:

        【解决方案4】:

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

        没有安全措施是万无一失的 - 如果您构建它,有人可能会破坏它。安全级别取决于您要保护的内容和手头的资源。所提出的解决方案对于许多应用来说是非常合理的。一些拥有破解它的资源的人拥有破解您的解决方案的资源。破解前者可能更难。

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

        【讨论】:

          【解决方案5】:

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

          这听起来像是一个两因素身份验证方案,但要说它是“气密的”,我必须了解更多关于 guid 密钥以及如何实施的信息。每个人都将使用相同的密钥,还是每个人/应用程序访问 Web 服务的密钥不同?

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

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

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 1970-01-01
            • 2017-06-17
            • 2015-06-12
            • 2015-06-17
            • 2011-03-01
            • 1970-01-01
            • 1970-01-01
            相关资源
            最近更新 更多