这个答案主要是关于 Chris Dixon 的声明,而不是回答“有多少攻击来自 MiTM”。
如果我们断言一种可能成为 MiTM 的不同方式以及给定的后果,我认为我们可以得出一些结论,即我们是否关心 MiTM 攻击的普遍程度。
如果我们查看不同情况下的一些风险,我们可能会遇到以下情况:
- 有人通过利用 Web 应用程序本身窃取数据库?
- 有人通过 MiTM 攻击攻击用户/管理员
我会说第一个影响更大(通常),应该在许多方面得到最大程度的缓解并首先处理。
因此,要使第 2 点胜过第 1 点,我认为 MiTM 真的必须疯狂地让我们将其视为与第 1 点一样高的安全障碍(正如 Chris 在引文中所指出的那样)!
现在,如果我们看到不同的攻击向量。首先是 MiTM。例如,要成为 MiTM,可以:
- 拥有一个流氓无线接入点。这是微不足道的,但对于有针对性的攻击,您必须与使用您的 web 应用程序的受害者处于相同的物理位置。
- 嗅探未加密的无线数据或来自 HUB 的数据(它们甚至不再存在?)
- 使用 ARP Poisoning 攻击用户。除非您与使用您的 web 应用程序的目标用户在同一个网络上,否则这不是微不足道的。
- DNS缓存中毒。为此,您需要毒化目标用户正在使用的 DNS。如果 DNS 设置不正确,则执行此攻击会变得有些微不足道,但是要使其起作用有很多依赖。
- 网络钓鱼攻击。这些仍然欺骗了毫无戒心和天真的用户,但是很多责任都在用户身上。
所有这些只是为了攻击一个或一小部分用户。即使那样,攻击这些用户也会在他们的浏览器中给他们一个警告(也有攻击这个的方法,但我不在这里讨论)。只有通过破坏根 CA 或发现用于生成证书的算法中的缺陷,您才能被允许冒充为受信任的证书颁发者。
另一方面,如果我们查看所有潜在的讨厌的东西,如果我们不投资于 webapp 本身的足够安全性,我们会看到攻击向量,例如:
- SQL 注入 - 微不足道且易于利用和发现。非常高的伤害影响。
- XSS (Cross Site Scripting) - 容易发现,更难利用。我认为未来我们会看到越来越高的用户影响。我预见这将成为我们过去看到的“新 SQL 注入”趋势。
- CSRF(跨站点请求伪造) - 适度发现,适度利用。这将需要用户导航到已经拥有的站点,触发对您的 web 应用程序的请求,该请求将代表用户进行交易。
因此,通过仅提及这几个攻击 webapp 和成为 MiTM 的流行方法,我将把它留给你试图保护的特定给定组织的特定风险/后果分析,无论你是否应该直接保护你的用户实施 SSL 或通过整体保护 webapp(其中还包括知识产权、用户数据、敏感数据、可能破坏其他应用程序的潜在数据等)。
因此,以我的拙见,我非常同意 Chris Dixon 的说法。在开始考虑保护传输层之前,尽可能优先考虑保护 webapp。
编辑:附带说明:在 Firesheep 之后,Facebook、Gmail 等页面受到了严重的 MiTM 攻击。这只能通过 SSL 和意识来缓解。
但是,如果您考虑一下,使用 Firesheep 嗅探无线流量并劫持会话将需要您连接的无线 LAN 没有任何加密。
当我今天进行战争驾驶时,它大大减少了开放无线 AP 的数量以及启用 WEP 的 AP 的数量。我们不断看到越来越多的 WPA2 加密 AP,它们在大多数情况下为我们提供了足够的安全性。
现在有人创建一个简单方便的工具来嗅探和劫持用户会话的风险是什么?对这些用户有什么影响?它也可以通过不同的方式来缓解(当同时来自不同的足迹时重新验证用户,当出现问题时通知用户(gmail就是一个很好的例子))。