Open Banking安全性前瞻

近两年来，Open Banking（Open Banking服务）已经悄然成为金融科技热点，如果说推动金融与科技的融合是金融科技发展的1.0阶段，那么，Open Banking背后的金融数据共享，足以将金融科技带入到2.0时代。可以预见的是，金融数据共享必将推动银行和金融科技企业更深层次的协作和竞争，并重塑整个金融生态，从而引发全球金融巨变。但与此同时，Open Banking也给金融与科技的融合发展、行业监管、行业竞争态势带来全新的挑战。

目前，Context已经与许多组织合作，帮助它们安全地与Open Banking生态系统集成，包括银行(ASPSP)和第三方提供商(TPP)。本文将介绍Open Banking面临的挑战、使用中的权限模型和可用的测试工具。

在研究人员开始之前，让研究人员先定义几个首字母缩写：

· ASPSP：帐户服务付款服务提供商（简称为银行）

· TPP：第三方提供商（例如，金融科技初创公司）

· PSD2：修订的支付服务指令(欧盟为促进银行一体化、更安全和开放而制定的新规则)

完整的词汇信息，请点击这里。

Open Banking简介

Open Banking是PSD2在英国的实现。除PSD2法规之外，Open Banking还为银行和第三方之间交互通信提供了详细的规范。这使公司（TPP）可以构建其应用程序并以标准化方式与任何银行（ASPSP）公开的在线服务集成。如果可以的话，为所有银行提供一个通用接口。

以下是开放式银行业务的流程：

例如，Open Banking允许终端用户查看其在不同银行持有的账户余额，并允许应用程序在一个连贯的仪表板中显示所有信息。这让用户可以在一个地方看到他们所有的财务状况，与此同时，信任第三方、过度获取银行信息、甚至整个网上银行门户都存在严重风险。使用Open BankingAPI，用户能够通过银行直接管理有关帐户的每个帐户的细粒度访问权限。通过Open Banking，银行的移动应用程序可以显示其他银行的账户详细信息。从这个模型可以看出，银行可以同时作为ASPSP和TPP，尽管是不同的实体。或者，他们可能依赖第三方提供访问其他银行账户数据的平台。

Open Banking在允许第三方提供商访问数据和与客户银行帐户交互方面是革命性的，与此同时，Open Banking设置了严格的准则，以确保客户对谁可以访问其数据有一个总体了解和控制。这样，第三方可以合法地对银行帐户进行操作，从而提供比银行本身更替的接口或更丰富的功能。这是客户与银行互动方式的根本变化，试图在传统金融机构中引入全面的变化和创新。

在内部实现所需的更改以支持公共API是一项复杂的工作，因为它为外部实体与银行交互引入了一个全新的渠道。PSD2最终的截止期限是2019年9月14日，然而，许多银行在规定的严格期限内全面实现API并与Open Banking生态系统集成时遇到了困难。对于影响核心服务的紧急复杂项目，必须按照最高标准执行开发和测试(功能和安全性)，这就要求银行业和安全业都创新合作方式并交付大型项目的新方法。

提供API只是整个努力的第一步，下一步将是让组织开始使用API提供高级服务，并使公众理解同意访问请求意味着什么。这两个方面都揭示了其他有趣的安全问题，这些问题一旦通过协作解决，将为银行客户带来更安全的未来。

Open Banking：读/写API许可模型、技术工作流和工具

接下来，研究人员将介绍成功进行安全评估所需的读/写API许可模型、技术工作流和工具。

研究人员已经介绍并描述了读/写API，但是这里简要列出了主要组件：

· AISP：帐户和交易信息；

· PISP：付款启动；

· CBPII：基于卡的支付工具发行人访问。

权限模型

读/写API是Open Banking的主要组件，因为它可以处理对交易和帐户数据的所有访问请求。因此，在描述权限模型时，请务必记住最终用户正在通过第三方与银行进行交互，图1中说明了基本的工作流程。

TPP对读/写API的访问仅限于它们提供的服务所需的访问，资金管理应用程序就是一个简单的例子。有些应用专注于预算管理，只需要读取帐户信息（AISP API）。其他应用程序也可能为用户提供付款的能力，因此TPP将需要访问AISP和PISP API。

读/写API旨在提供对PSU（最终用户）帐户的非常特定的粒度控制访问，对于任何级别的访问，TPP都需要创建一个“同意”，并要求最终用户直接通过其银行进行批准。

请注意，同意是由TPP定义的，因此，在授权TPP查询数据之前，aspsp必须向用户提供有关访问请求的简明信息。Open Banking规范为用户界面提供了指导方针，以使每个银行的用户体验尽可能简洁明了。

下图显示了帐户和事务API (AISP)的用户旅程，同样的用户流也应用于PISP和CBPII。

AISP用户流程

1. 终端用户希望在资金管理应用程序中显示其帐户余额；

2. TPP应用程序将用户重定向到其银行以授权特定的访问请求，用户登录到其在线银行帐户并确认TPP应用程序可以访问帐户余额，授权视图包含确切的访问请求以及TPP将有权访问数据的时间；

3. 用户被重定向回具有TPP查询数据授权的TPP应用程序；

然后，TPP应用程序可以连接到帐户余额的各个Open Banking AISP终端，并在TPP应用程序中显示信息，直到访问请求到期。

上图显示了用户流程的简化视图，下一节将详细介绍有关用户流程和测试读/写API的挑战的技术细节。此外，研究人员将讨论研究人员的Open Banking测试工具。

测试读/写API

当查看上面的用户流程图时，用户流程的复杂性不是立即显而易见的。Open Banking涉及三个参与者,而不是通常的客户机/服务器模型，并利用各种技术，如用户重定向，交互TLS，消息签名以及PSU的手动身份验证和授权，所有这些使自动化测试比常规的Web服务评估更加复杂。

接下来，研究人员将首先描述技术工作流，然后提供有关所涉及技术的更多信息。本文介绍的知识可用于测试TPP和ASPSP。然而，当测试一个ASPSP的读/写API实现时，就需要覆盖更多的用户工作流。

技术工作流程

在测试ASPSP的读/写API时，需要同时考虑PSU和TPP的角色。因此，测试人员需要：

· 配置和测试交互TLS；

· 向ASPSP的OAuth端点进行身份验证；

· 调用相应的读/写API以创建同意并执行授权的操作；

· 生成从TPP到ASPSP的重定向；

· 向ASPSP认证为PSU，以授权访问请求（同意）；

· 处理来自ASPSP的重定向（回调）；

· 根据Open Banking规范实现和配置消息签名。

下图显示了终端用户通过Open Banking进行国内支付的一个示例序列。灰色区域突出了TPP和ASPSP之间的交互TLS联系，蓝色区域标记了TPP需要消息签名的请求。

PISP国内支付顺序

可以在Open Banking规范中找到每个版本和组件的更详细的序列图，例如，读/写版本3.1.2 – PISP。

交互TLS

Open Banking生态系统中的注册机构有两套证书，用于传输和消息签名。Open Banking安全配置文件定义到读/写API的连接需要使用交互身份验证的TLS (MTLS)进行保护，MTLS连接使用传输证书处理。

OAUTH

在一个TPP可以向ASPSP的读/写API发出请求之前，它们需要使用OAuth终端进行身份验证。这在图2中被注释为“pre-auth OAuth token”，用于创建不需要用户授权的同意和其他请求。

对于其他终端，不同的OAuth令牌需要与授权代码一起生成，授权代码包含在从ASPSP重定向到TPP同意授权后。这将在“重定向”部分中进一步解释。

有关Open Banking的OAuth的更多信息，请参考规范。每个ASPSP的具体信息可以在Open Banking规范的实现指南中找到，或者通过ASPSP的开发人员门户找到。

消息签名

除了交互TLS之外，Open Banking规范还将消息签名定义为一种附加措施，以确保不可拒绝来自TPP和ASPSP的特定敏感API终端。

Open Banking签名算法规定了一个符合RFC 7515（关键标头）和RFC 7797（未编码/分离的有效负载）的库。在撰写本文时，Brian Campbell的Jose4J Java库是同时符合上述两个RFC的少数几个库之一，这可能会将消息签名算法的实现限制为具有兼容库的编程语言。下面的代码片段是使用Jose4J进行Open Banking消息签名的示例：

重要功能以黄色突出显示：

· 禁用Base64编码(第25行)；

· 设置关键标头(第16、17和29行)；

· 生成一个分离的JWS和所需的声明(第31行)。

关于Open Banking消息签名要求的更多细节可以在每个读/写版本(即3.1版本)的Confluence（一个专业的企业知识管理与协同软件，也可以用于构建企业wiki）页面上找到。

研究人员已经将算法整合到一个小的图形用户界面，以提高可用性。下图显示了示例AISP同意有效负载和生成的分离的JWS标头。

消息签名

然后，JWS可以包含在带有“x-jws-signature”头的请求中，如下面的示例所示(是图3中分离的JWS的占位符)：

用户重定向

如AISP用户流图(图1)所示，有两个用户重定向。第一次重定向时，用户被发送到ASPSP进行身份验证，然后授权访问请求。在同意授权之后，用户被重定向回TPP，下图（图4）是重定向技术方面的更集中视图。

重定向

为了在测试ASPSP时完成用户流程，研究人员需要：

生成从TPP到银行的重定向；

处理来自银行的重定向。

下面是从TPP到ASPSP的重定向请求示例，" <> "中的值是占位符，需要为每个同意进行更改或生成。

最重要的参数是“redirect_uri”和“request”，分别包含TPP回调URL和授权请求详细信息，有关其他OAuth2参数的更多信息可以在这里找到。

JWS包括同意和TPP信息，下面是来自Open Banking规范的一个示例JWS结构：

通过重定向，用户被发送到银行的身份验证门户。

需要为每个同意生成重定向请求参数，下面是研究人员为此创建的GUI的截图：

用户重定向到ASPSP

在用户授权同意后，银行将把用户发送到TPP重定向中指定的URL。该URL必须是软件声明声明（SSA）中注册的终端之一，如果不是，则银行不得转发PSU。

下面是一个重定向URL的例子：

“id_token”参数包含有关授权同意的详细信息，TPP使用OAuth代码(黄色突出显示)创建下一个访问令牌，对读/写API执行授权操作。正如OAuth2 RFC 6749中“为了减少泄漏风险”所指定的那样，代码仅在几秒钟内有效。毕竟，此代码用于生成用于执行付款的访问令牌或查看敏感的财务数据。因此，新的访问令牌必须在收到回调后立即被请求：

Open Banking Burp Suite扩展

研究人员使用Burp套件来测试大多数web应用程序和web服务，虽然Burp已经提供了许多优秀的本机功能，包括许多扩展，但它们并没有完全覆盖Open Banking的用户流(例如特定的消息签名算法和用户重定向)。这就是为什么我们为Burp创建了Open Banking扩展的原因，它具有上一部分提到的算法。

Open Banking Burp Suite扩展

该扩展程序可以通过在响应正文中突出显示同意ID并将其发送到扩展程序来生成用户重定向，自动在Repeater和Intruder中签名消息以启用模糊测试，还可以处理来自银行的回调重定向以及后续的OAuth请求。

以上所述，是Open Banking所必需具备的基本安全功能。