确保 SPA 安全是一项团队运动

多年来，我注意到的一个有趣且更令人沮丧的事情是网络工程师和应用开发人员对应用程序的看法存在差异。 我们已经在网络图上描绘应用的方式以及相反地在应用架构图上显示网络的方式中看到了这一点。 

毋庸置疑，每个人对彼此的看法都非常简单。 

对于安全而言也是如此，其在保护网络和应用方面所起的作用至关重要，而且对业务本身的保护也至关重要。 重要的是，安全团队需要跳出典型架构图的框框来真正理解应用。 相当大比例的（成功的）攻击都是在应用层执行的。 我们越是不能认识到各种类型应用的独特特性，这些应用就越容易受到攻击。 

今天的讨论将集中于 SPA。 对于那些想知道这个特定的 TLA 代表什么的人来说，这就是“单页applications”。 

SPA 简介 

单页应用就是这样的 - 一个单一的网页，作为所有与应用程序相关的任务的框架。 这种架构让人回想起 Web 2.0 时代以及 AJAX 的出现，作为一种“刷新”单个 DOM（文档对象模型）元素而不是重新加载整个页面的方法。 这种技术极大地提高了性能，是现代单页应用的先驱。

这些应用程序更紧密地反映了移动应用程序的行为，其中客户端 UI 在首次打开时加载，并且与服务器的通信仅涉及数据。 这意味着对服务器的每次调用只包含数据，并且对 UI 的任何更改都会发生在客户端上。 这大大减少了来回发送的数据量，并且可以想象，这意味着更好的性能。 这些类型的应用程序使用 API 来交换数据。

一般来说，我们一直假设大多数 API 都是使用 REST 原则实现的。 这意味着每个对象（通常被认为与单个 UI 元素绑定）都有自己的 API，可以调用该 API 来执行 CRUD（创建、读取、更新和删除）事务。 从安全角度来看，这使得事情变得更容易一些，因为您可以预期给定 API（URI）调用的特定格式的数据。 发送到“/update/product/123”的数据将始终是相同的序列化对象，而发送到“/delete/order/4433”的数据将是不同的序列化对象。 这意味着可以使用将特定策略与特定 URI 绑定的传统做法来保护该 API。 

单一 URI 模式 

现在，SPA 可能会（也可能不会）遵循这种模式。 围绕 SPA 的新兴实践可以并且确实使用相同的 API 来进行交易以及更传统的函数到 URI 映射。 使用单个 URI 模式 SPA，URI 不会改变 - 但在服务器之间来回发送的序列化对象会改变。

这让人想起 SOA/XML 事务，其中单个端点（URI）可用于调用多个功能。 目标函数（端点）包含在序列化的 XML 数据中，或者有时插入到自定义 HTTP 标头中。 该模型导致需要 SOA/XML 网关，负责接收请求并确定调用哪个函数，然后将其路由到正确的端点（服务器）。 

使用 SPA，您可能需要处理多个 API 调用，或者仅仅处理几个。 在所有情况下，您都可能需要以某种格式（可能是 XML，更可能是 JSON）保护数据。 这意味着您需要意识到内容存在风险。 由于某些数据可能用于动态生成 UI 元素（或以其他方式在客户端上操作 DOM），因此在每次提交时寻找并销毁潜在的恶意代码非常重要。 

安全断开 

不幸的是，如果使用单个 URI 来交换不同功能的数据，那么将策略附加到 URI 的传统做法将不起作用。 事实上，这可能会破坏安全性，因为此类策略通常经过训练以预期特定的有效载荷格式。 API 网关也经常将策略（路由、计量、访问）绑定到特定 URI。这意味着，仅使用几个 URI（API 调用）来处理具有不同数据格式的更多功能的做法可能会破坏现有的安全性。

这就是为什么安全和开发（不是 DevOps，而是开发人员）从第一行代码到部署的更紧密合作变得越来越重要。 开发人员可以尽早采取一些措施，以便更轻松地实施适当的安全保护措施 - 例如插入带有指示器的 HTTP 标头，以便可以执行正确的策略。 诸如“X-Code：“order””这样简单的指令就能丰富请求，让安全解决方案能够识别并随后扫描数据以查找潜在漏洞。

从架构上讲，这可能需要一个智能 L7 代理，它可以在将请求路由到适当的安全解决方案（WAF、API 网关等）之前提取代码并重写 URI。 如果智能 L7 代理可以使用数据格式语言（例如 JSON），并且开发人员在每个交换中都包含一些可用于重写和路由到正确位置的代码或端点名称，则这种方法也有效。 

最佳情况下，将应用层安全性纳入应用程序本身将实现性能和安全性的最佳平衡。 然而，这并不总是可能的，有时需要创造性的架构解决方案来实现安全目标。 

安全是一项团队运动

一般来说，开发人员在客户端和服务器之间分配各种职责的方式的变化，对应用服务基础设施与后续请求和响应的交互方式有重大影响。 安全、开发人员和应用服务基础设施团队参与整个 SDLC 非常重要。架构解决方案也需要时间来实施。 如果将其留到“最后”，则您需要花费几天、几周甚至几个月的额外时间来推向市场。 或者您要在没有安全服务的情况下进行营销，这本身就有一系列风险（和后果）。  

从开发第一天开始进行协作是确保应用投入生产时可用、快速和安全的最佳和最快方法。