我需要弹药来尝试促进一组外部的 WS-Security可用的 Web 服务直接与我们的生产客户服务应用程序交互。我的愿景是实现 IPassword 提供程序并通过我们的 AD 商店进行身份验证。自上而下的架构建议是 SSL，在路由器上使用 IP 过滤器，仅允许某些 IP 地址调用 Web 服务。将通过 GUID 密钥授予访问权限。无需登录或密码。
我们将向每个有权访问我们的网络服务的合作伙伴授予一个密钥。它将由我们生成并可能通过电子邮件发送给他们。据我所知，没有过期政策。
我觉得这不对，但他们并不相信我的论点，即这里没有实际的身份验证。该架构存在哪些具体的安全风险？到底有哪些攻击场景是可能的，以及破坏我们的系统有多容易？我需要能够详细说明风险，甚至可能向我们的架构团队展示它们。
I need ammunition to try to promote WS-Security for a set of externally-available web services that interact directly with our production customer service application. My vision is to implement IPassword provider and authenticate with our AD store. The architecture recommendation that came down from on high is SSL, with an IP filter on the router to only allow certain IP addresses to call the web services. Access will be granted with a GUID key. No login or password required.
A key will be granted to each partner authorized to access our web services. It will be generated by us and probably emailed to them. There is no expiration policy that I'm aware of.
This feels wrong to me, but they're not buying my argument that there is no actual authentication in play here. What specific security risks are there with this architecture? Exactly what attack scenarios are possible and how easy would it be to compromise our systems? I need to be able to detail the risks, possibly even demonstrate them to our architecture team.
发布评论
评论（5）
嗯...这里可能会出现很多问题...
首先，SSL 服务器证书只能保护您免受正常窃听，如果操作正确，则可以保护服务器的身份。它不能确保客户是谁。 （我假设您正在对客户端上的服务器证书进行适当的安全检查）。
但这不会告诉服务器任何有关客户端的信息。为此，您还需要分配客户端证书并在服务器上验证它，即使这样，此解决方案仍然容易受到 中间人会发起攻击。
回到你的配置。如果您的服务器证书验证未正确完成，那么有人不仅可以窃听，还可以注入/修改您的通信通道上的信息（因为您没有对消息本身执行任何签名来验证它没有被修改）。
IP 过滤器相当弱，因为大多数机构都有一些 NAT 或 用于外部访问的代理配置。因此通过同一节点进行外部访问的电脑将显示相同的 IP。所以不需要“欺骗”......你只需要妥协任何内部机器......比如秘书的机器（咯咯笑）......并从那里提出请求。
我不确定 IP 欺骗是否是有效的攻击，在这种情况下，攻击者会在客户端计算机上造成拒绝服务，然后尝试连接到服务器，伪造数据包并利用欺骗客户端无法响应的优势，首先数据包来终止连接。
这意味着猜测包裹序列号，这在现在很难，但并非不可能。从那里，攻击者可以盲目地注入他需要的任何消息，但在这种情况下，因为连接不是纯 html，而是一个 ssl 流，其中涉及密钥等信息的交换，并且考虑到攻击者看不到，因为注入是盲目完成的（至少除非它在同一个子网中并且可以嗅探数据包）...我怀疑它的可能性。
无论如何...推荐配置。
1
- 服务器 SSL 证书在客户端进行验证。
- 客户端 SSL 证书在服务器上进行验证。
- 除了 GUID 令牌之外，某种消息的校验和......我建议每次为每个会话客户端生成该校验和。
（不要忘记在加密存储 pkcs12 等上安全地分发此证书，否则此方法容易受到中间人攻击）
2
- 使用 WS-Security 扩展 Web 服务肥皂消息，并使用客户端和服务器签名/加密以及客户端和服务器证书，并使用时间戳服务。
你仍然可以 ip 绑定连接...但是没有必要...而且它仍然很弱。
顺便说一句，早在 1994 时，Kevin Mitnick 就曾使用 IP 欺骗来对抗 Shimomura。所以这是可能的，而且不是很难。我敢打赌，根据您的服务器操作系统版本，已经有一些工具可以自动化大部分过程。
我很想听听其他人的想法。希望这有帮助。
Well... there is so much that can go wrong here...
For one, the SSL server certificate only protects you against normal eavesdropping and if done correctly the identity of the server. It doesnt ensures who the client is. (Im assuming you are doing the proper security checks on the servers certificate on your client).
But that tells the server nothing about the client. To do that you need to also assign a client certificate and validate it on the server and even then this solution is still vulnerable to man in the middle attacks if not done correctly.
Going back to your configuration. If your server certificate validation is not done correctly someone could not only eavesdrop but also inject/modify the information on your communication channel (since you are not performing any signature on the message itself to verify it wasnt modified).
The IP filter is pretty weak, since most institutions have some NAT or Proxy configurations for outside access. So pcs with outside access through the same node would show the same IP. So no "spoofing" is required... you just need to compromise any of the internal machines... like a secretary's machine (giggles).... and make the requests from there.
The IP Spoofing im not sure would be a valid attack, in this case an attacker would cause a denial of service on the client machine and then try to connect to the server forging the packets and taking advantage that the spoofed client cant respond and rst the packets to terminate the connection.
It would imply guessing the package sequence number, which is hard now days, but not impossible. from there an attacker can inject blindly whatever message he needs but in this case since the connection is not plain html but an ssl stream which involves exchange of info like keys etc, and given that the attacker cant see, since the injection is done blindly (at least unless its in the same subnet and can sniff the packets)... i doubt its possible.
Anyways... recommended configurations.
1
- Server SSL certificate with validation on the client.
- Client SSL certificate with validation on the server.
- Some sort of checksum of the message, besides the GUID token.. which i would advice to be generated each time for each session-client.
(Dont forget to distribute this certificates securely on encrypted stores pkcs12 etc otherwise this approach is susceptible to man in the middle attacks)
2
- Extend the web service soap message with the WS-Security and use client and server signature/encription with Client and Server certificates, and use timestamping services.
You can still ip bind the connections... but there would be no need... and its still weak.
On a side note, IP spoofing was used by Kevin Mitnick against Shimomura back in 1994... so it is possible and not extremely hard. I bet that depending on your servers OS version there are tools that automate most of the process already.
Id love to hear what others think. Hope this helps.
您的 GUID/SSL 方法有漏洞。可以使用欺骗 IP 地址的功能，如果使用 GUID 密钥截获电子邮件 - 您就受到了威胁。
WS-Security 是一个已建立的协议，这意味着它已经过安全研究人员和博士的研究和锤炼。这些人是实施安全措施时值得信赖的人。而自制的安全性几乎总是存在严重缺陷。
Your GUID/SSL method has holes. The ability to spoof IP adresses is available and if an email is intercepted with the GUID key - You're compromised.
WS-Security is an established protocol and that means it's been studied and hammered at by security researchers and Doctorates. These are the people to trust when implementing security measures. Whereas home baked security almost always has critical flaws in it.
根据您检查 IP 地址的方式，这些地址可能很容易被欺骗：
http:// en.wikipedia.org/wiki/IP_address_spoofing
Depending on how you're checking IP Addresses, it is possible these could be spoofed quite easily:
http://en.wikipedia.org/wiki/IP_address_spoofing
你可能正在打一场失败的战斗。
没有一种安全措施是万无一失的——如果你构建了它，有人就可以破坏它。安全级别取决于您要保护的内容和现有的资源。所提出的解决方案对于许多应用来说都是非常合理的。拥有资源来破解它的人也拥有资源来破解您的解决方案。破解前者可能更难。
另一个问题是资源。也许运营团队可以更好地处理安全问题。简而言之，即使有最好的论据，你也可能无法获胜。
You may be fighting a losing battle.
No security is foolproof - if you build it someone can break it. The level of security is dependent on what you are securing and the resources at hand. The proposed solution is very reasonable for many applications. Some one who has the resources to hack it has the resources to hack your solution. It probably is harder to hack the former.
The other issue is resources. Maybe the ops team can better handle security. In short even with the best arguments you may not prevail.
那是相当安全的。在路由器级别欺骗 IP 地址非常困难，并且是银行常见的安全方法。通过在路由器上通过 IP 地址锁定它，您非常确定您知道哪些组织将访问您的 Web 服务。
这听起来像是一个两因素身份验证方案，但要说它是“无懈可击的”，我必须了解更多有关 guid 密钥及其实施方式的信息。每个人都会使用相同的密钥，还是访问 Web 服务的每个人/应用程序都会使用不同的密钥？
他们的方法实际上看起来相当合理。 IP 地址充当“用户名”，guid 代表传统用户名/密码模型中的“密码”。该堆栈级别的 IP 地址很难被欺骗，因为 IP 地址本质上是由 ISP 验证的。对于经验不足的人来说，欺骗上游的 IP 地址以导致 DOS 可能是可能的，但实际上欺骗 IP 以在您的服务和“流氓”客户端之间打开是极其困难的。
最安全的方法是通过在路由器上使用 IP 过滤将两者结合起来，并强制通过 SSL 使用用户名和密码。
That's pretty secure. Spoofing an IP address at the router level is pretty hard and is a common security approach for banks. By locking it down by ip adress at the router, you are pretty certain you know which organizations will be accessing your web service.
It sounds like a two factor authentication scheme, but to say that it is "air tight", I'd have to hear more about the guid key and how that is going to be implemented. Is everyone going to use the same key, or will it be different for each person/application accessing the web service?
Their approach actually seems pretty sound. The IP Address acts as a "user name" and the guid represents the "password" in a traditional user name / password model. IP Address at that level of the stack are very hard to spoof, because the IP address is essentially verified by the ISP. Spoofing an IP address on the upstream to cause a DOS might be possible for someone less experienced, but actually spoofing the IP to open between your service and a "rogue" client is extremely hard.
The most secure approach would be to combine the two by using IP filtering at the router, and force the use of a user name and password all through SSL.