仅使用反向代理保护 Web 应用程序

信息安全 http oauth http代理
2021-09-01 12:37:06

为了保护其公共 HTTP API(所谓的 REST),我的客户要求我实现一个简单的 HTTP 反向代理,该代理将验证(OAuth 2.0)访问令牌并将 HTTP 请求转发到内部 Web 服务进行处理。

这个想法是我的客户端具有“强大的”网络级安全性:位于代理后面的各种 Web 应用程序将没有安全约束,因为它们无法从外部访问。当多个内部服务相互调用时,他们希望保持调试简单。用于内部调用的纯 http,没有 TLS。

我认为让内部应用程序“完全开放”是一个糟糕的主意,因为任何设法进入网络的攻击者基本上都可以免费访问敏感(明文)客户数据……而历史似乎证明这种情况经常发生. 从操作的角度来看,从代理(OAuth 范围/URL 匹配)强制执行细粒度约束(如 ACL)并在部署新服务时保持配置是最新的将是一件痛苦的事情。

你们看到我遗漏了什么吗?实施应用程序级安全性的任何其他论点?


编辑:一些我没有明确提及/解释的重要细节:

  • 我在这里谈论的 Web 应用程序(仅隐藏在安全代理后面)都是 Web 服务。
  • 具有用户界面(公共/内部“站点”)的 Web 应用程序位于另一个网络区域,与相关 Web 服务相比,具有一些不错的应用程序级安全性。

我提到的“强大”网络安全都是关于区域的,最终用户(和未经授权的内部人员)理论上无法直接访问 Web 服务(只能通过代理)。我猜操作人员在访问机器时仍然可以提供某种路由,如答案中所述。

4个回答

根据我的理解,我认为你甚至不需要进入内部网络来证明这是一个糟糕的主意。攻击者(可能是前雇员、第三方承包商或现有的心怀不满的员工)对这个不安全的内部应用程序有一些上下文,包括详细信息,例如托管应用程序的内部主机地址、应用程序的重要功能、一些知识应用程序整体外观和感觉(这显然有助于创建网络钓鱼网站),当然,应用程序容易受到常见 Web 应用程序问题的影响(尤其是跨站点请求伪造)。

好吧。基于以上假设,我可以想到以下可能的攻击:

  • 利用 CSRF 漏洞欺骗内部用户向应用程序发出状态更改请求这本身可用于通过欺骗经过身份验证的用户访问您的网站来利用应用程序中的其他常见漏洞,您的 JavaScript 将等待使用您的有效负载向应用程序发出请求,但使用受害者的会话 cookie您可以发送用于命令注入、SQL 注入、XSS 等的注入负载。由于您了解攻击面,因此可以相应地制作请求。

  • 利用应用程序上配置错误的 JSONP 或 CORS 实现同样,为此,您将利用 CSRF 漏洞通过其会话 cookie 向内部应用程序发出请求。但是这一次,您的恶意 JavaScript 将读取来自应用程序的敏感响应(因为 JSONP 和 CORS),而不是执行状态更改请求。您可以在此处此处此处阅读有关它的更多信息

  • 网络钓鱼内部用户(可能通过 DNS 缓存中毒)现在,由于您知道内部应用程序的外观,您可以创建一个网络钓鱼网站或只是应用程序的登录页面并将其托管在公共地址上。然后,您可以毒害网络中企业 DNS 服务器的 DNS 缓存,或者通过简单地修改内部系统的主机文件(可能通过诱骗他们下载恶意软件)。从网络外部利用这最后一步有点棘手,但我希望你明白这一点。如果您对进一步阅读感兴趣,可以了解有关 DNS 缓存中毒的更多详细信息:DNS 和 DNS 缓存中毒设置完成后,没有什么可以阻止您对内部用户进行网络钓鱼,因为应用程序未通过 TLS(无身份验证)!

这就是一般情况下的处理方式。

与企业对话

在讨论应用程序的安全性时,我认为客户可以真正涉及到三件事。(90% 的时间用户是脚注)

  1. IP(知识产权)。没有客户希望将他们的秘密提供给他们的竞争对手。
  2. 图片。如果声誉和形象受到威胁,公司可以被善意地激励采取更好的安全措施。如果您的客户处于竞争激烈的环境中,其中的违规行为可能会使用户蜂拥而至,则尤其如此。
  3. 钱。没有什么比亏损的威胁更能激励公司采取行动了。在安全方面,是雇佣额外的外部帮助所花费的时间和费用,而在合规情况下,加起来也是罚款。

与团队交谈

在安全领域,风险是我们玩的游戏,我们的工作是说服企业适应。从技术角度来看,我们在安全团队中将这种类型的场景视为“这是一个基本的事情”。从企业的角度来看,他们的想法是“我将受到损害的真正机会是什么?”

我显然不了解您的客户或他们的网络,但这是我将如何开始的基础知识(在提问时尽量不要做出判断):

  • 他们的“安全网络是什么样的”?他们有最佳实践吗?事情是否保持最新?
  • 为什么他们不想应用安全性?知识库?钱?在你的情况下调试。
  • 他们不做某事的原因能否以更安全的方式解决?想到在测试环境中进行调试。

最后,Speak at there level

小型企业不是中型企业,不是大型企业,不是财富 500 强企业,抓住我了吗?各个级别都有需求、需求和能力,如果您告诉客户他们需要另外 50K 的安全设备,那么您将有一个非常不情愿的业务合作。

我将重点关注的三件事:

  • 与他们的行业交谈。了解医疗行业如何做某事很好,但如果他们在工业控制领域工作,他们不在乎。
  • 看看他们的利润率。这可以追溯到我之前关于公司规模的陈述。汉堡王没有苹果的资源。
  • 谈谈他们的经历。如果他们的行业或竞争对手有违规行为,请与它交谈。他们通常会知道(消息传开),如果他们没有听说过,它会重新强化他们可能和可能成为目标的概念。

我知道这并不能完全说明手头的代理问题,但我不能在不了解客户的情况下具体说明详细的客户情况。

内部用户的浏览器也连接到外部,提供 Intranet 和公共 Internet 之间的路由。我经常向那些告诉我“别担心这是一个内部网络应用程序”的人指出这一点。

在您的情况下,HTTPS 是必要的。这不仅可以防止您提到的威胁、闯入网络的人,还可以防止不需要闯入的恶意内部人员。除了暴露敏感数据本身,如果没有 https,您将以明文形式暴露凭据,凭据这可能会提供对内部资源的更多访问权限。如果内部使用无线,问题会变得更糟。

听起来这些网络应用程序的内部用户根本没有访问控制。我觉得访问控制应该内置到应用程序本身中。

如果他们想让调试更容易,请关闭安全控件的测试环境。

我们的反向代理 (Pound) 确实很好地提供了一项安全功能:它充当外部客户端和我们的 Web 资源之间的中介。这允许我们使用它来设置访问策略。这是您要保护的敏感内部 Web 应用程序的保护层之一,但我认为它不应该是唯一的层。

在这种情况下,我个人会做三件事:

  1. 向客户显示由网络钓鱼导致的重大违规百分比数据(大约 95-97%)

  2. 进一步表明,网络钓鱼可以直接导致攻击者嗅探网络上的流量,并且他/她可以查看传入和传出这些服务的每一位数据。

  3. 识别这些 Web 服务正在传递的数据的数量和质量,并将它们与一个风险模型一起呈现给客户端,该模型试图量化与攻击者的时间嗅探流量相关的潜在成本。

这主要与缺少 SSL 有关,但考虑到您的情况,这似乎是最紧迫的问题。

祝你工作顺利。我了解向不情愿的客户强调安全性是多么困难。但是,您必须始终牢记您的工作是增加业务价值,向他们展示您如何做到这一点,他们将开始看到您的观点。