我需要弹药来尝试为一组外部可用的 Web 服务推广WS-Security，这些 Web 服务直接与我们的生产客户服务应用程序交互。我的愿景是实现 IPassword 提供程序并通过我们的 AD 商店进行身份验证。从上层下来的架构建议是 SSL，在路由器上有一个 IP 过滤器，只允许某些 IP 地址调用 Web 服务。将使用 GUID 密钥授予访问权限。无需登录名或密码。
每个授权访问我们的网络服务的合作伙伴都将获得一个密钥。它将由我们生成，并可能通过电子邮件发送给他们。我不知道没有到期政策。
这对我来说感觉不对，但他们并没有接受我的论点，即这里没有实际的身份验证。这种架构有哪些特定的安全风险？究竟有哪些攻击场景是可能的，入侵我们的系统有多容易？我需要能够详细说明风险，甚至可能向我们的架构团队展示它们。
嗯......这里有很多可能出错的地方......
一方面，SSL 服务器证书只能保护您免受正常窃听，并且如果操作正确，则可以保护服务器的身份。它不能确定客户是谁。（我假设您正在对客户端上的服务器证书进行适当的安全检查）。
但这不会告诉服务器有关客户端的任何信息。为此，您还需要分配一个客户端证书并在服务器上对其进行验证，即使这样，如果没有正确完成，该解决方案仍然容易受到中间人攻击。
回到你的配置。如果您的服务器证书验证未正确完成，则有人不仅可以窃听而且还可以注入/修改您的通信通道上的信息（因为您没有对消息本身执行任何签名以验证它没有被修改）。
IP 过滤器非常薄弱，因为大多数机构都有一些NAT或代理配置以供外部访问。因此，通过同一节点进行外部访问的 pc 将显示相同的 IP。所以不需要“欺骗”......你只需要破坏任何内部机器......就像秘书的机器（咯咯笑）......然后从那里提出请求。
IP 欺骗我不确定是否是有效的攻击，在这种情况下，攻击者会在客户端计算机上造成拒绝服务，然后尝试连接到服务器伪造数据包并利用被欺骗的客户端无法响应并首先数据包终止连接。
这意味着猜测包裹序列号，这在现在很困难，但并非不可能。从那里，攻击者可以盲目地注入他需要的任何消息，但在这种情况下，因为连接不是纯 html，而是涉及交换密钥等信息的 ssl 流，并且鉴于攻击者看不到，因为注入是盲目完成的（至少除非它在同一个子网中并且可以嗅探数据包）......我怀疑它的可能性。
无论如何...推荐的配置。
1 - 在客户端验证的服务器 SSL 证书。- 在服务器上进行验证的客户端 SSL 证书。- 消息的某种校验和，除了 GUID 令牌.. 我建议每次为每个会话客户端生成。（不要忘记在加密存储 pkcs12 等上安全地分发此证书，否则这种方法容易受到中间人攻击）
2 - 使用 WS-Security 扩展 Web 服务肥皂消息，并使用客户端和服务器签名/加密与客户端和服务器证书，并使用时间戳服务。
您仍然可以 ip 绑定连接...但是没有必要...而且它仍然很弱。
附带说明一下，Kevin Mitnick 早在1994 年就使用 IP 欺骗来对付 Shimomura ......所以这是可能的，而且不是非常困难。我敢打赌，根据您的服务器操作系统版本，已经有一些工具可以自动化大部分过程。
我很想听听别人的想法。希望这可以帮助。
您的 GUID/SSL 方法有漏洞。欺骗 IP 地址的能力是可用的，如果使用 GUID 密钥拦截电子邮件 - 你就被攻陷了。
WS-Security 是一个既定的协议，这意味着它已经被安全研究人员和博士研究和锤炼过。这些是实施安全措施时值得信赖的人。而家庭烘焙的安全性几乎总是存在严重缺陷。
根据您检查 IP 地址的方式，这些地址可能很容易被欺骗：
这很安全。在路由器级别欺骗 IP 地址非常困难，并且是银行常用的安全方法。通过在路由器上通过 IP 地址锁定它，您可以确定您知道哪些组织将访问您的 Web 服务。
这听起来像是一个两因素身份验证方案，但要说它是“气密的”，我必须了解更多关于 guid 密钥以及如何实施的信息。每个人都将使用相同的密钥，还是每个人/应用程序访问 Web 服务的密钥都不同？
他们的方法实际上看起来很合理。IP 地址充当“用户名”，而 guid 代表传统用户名/密码模型中的“密码”。该堆栈级别的 IP 地址很难被欺骗，因为 IP 地址本质上是由 ISP 验证的。对于经验不足的人来说，在上游欺骗 IP 地址以导致 DOS 可能是可能的，但实际上欺骗 IP 在您的服务和“流氓”客户端之间打开是非常困难的。
最安全的方法是通过在路由器上使用 IP 过滤将两者结合起来，并通过 SSL 强制使用用户名和密码。
你可能正在打一场失败的战斗。
没有安全是万无一失的——如果你建造它，有人可以破坏它。安全级别取决于您要保护的内容和手头的资源。所提出的解决方案对于许多应用来说是非常合理的。一些拥有破解它的资源的人拥有破解您的解决方案的资源。破解前者可能更难。
另一个问题是资源。也许运维团队可以更好地处理安全问题。简而言之，即使有最好的论据，你也可能不会占上风。