约旦中央银行：测试您客户账户背后的移动银行应用。

1. 01

   《网络风险韧性指令》，第 35 条 (a) 项

   至少每年对关键系统进行一次渗透测试

   文本的内容

   至少每年或在系统发生根本性变更后，对关键系统实施渗透测试，测试范围依据系统及其支撑系统的敏感程度确定。测试在应用层面以及内部和外部网络层面实施。测试可以由第三方执行，但不得连续两年以上外包给同一第三方。

   来源：《网络风险韧性指令》，第 35 条 (a) 项

   对您的移动应用意味着什么

   如果您的移动银行应用支撑关键系统，该应用及其 API 就应纳入年度渗透测试，并在任何根本性变更后重新测试。

   Ostorlab 如何提供帮助

   AI 智能体渗透测试在登录后，针对您发布的版本测试应用及其 API，AI 智能体的每个发现都附有可重放的有效漏洞利用。它可以在每次发布时运行，填补年度测试之间的空档。

   仍由您负责的部分

   确定年度测试范围、选择和轮换测试方，以及确定何为根本性变更。

2. 02

   《网络风险韧性指令》，第 35 条 (b) 项和 (c) 项；《网络安全框架》，G.9.5

   评估漏洞并监控新出现的缺口

   文本的内容

   定期评估关键系统及其支撑系统的漏洞和安全缺口，处理已发现的缺口，并持续监控系统以发现新的缺口。该框架强烈建议至少每月对关键和敏感系统进行一次漏洞扫描，扫描既要绕过已实施的控制措施进行，也要透过这些控制措施进行。

   来源：《网络风险韧性指令》，第 35 条 (b) 项和 (c) 项；《网络安全框架》，G.9.5

   对您的移动应用意味着什么

   在两次年度渗透测试之间，应用及其 API 需要定期进行自动化扫描，发现须得到修复和跟踪。

   Ostorlab 如何提供帮助

   从您的 CI/CD 流水线对每个构建运行自动扫描，并在无需手动触发的情况下监控商店版本。通过定时运行流水线，可在两次发布之间保持每周的扫描频率。发现会被评为严重、高、中或低风险，以工单形式跟踪，并在修复发布后进行复测。

   仍由您负责的部分

   基础设施和网络扫描，以及每个系统的扫描频率。

3. 03

   《网络安全框架》，G.2.2 和 G.2.3

   在整个开发过程中测试安全性

   文本的内容

   定义安全开发生命周期：编码阶段进行静态代码分析，测试阶段通过漏洞扫描和渗透测试进行动态代码分析，并审查和修复结果。安全编码必须至少涵盖 OWASP Top Ten 和 CWE/SANS Top 25。应用安全不应依赖于隐藏功能、源代码、密钥或字符串，修复措施必须在发布前经过全面测试。

   来源：《网络安全框架》，G.2.2 和 G.2.3

   对您的移动应用意味着什么

   应用的每个版本在上架商店之前都应通过静态和动态测试，而隐藏在应用中的密钥并不是一种控制措施。

   Ostorlab 如何提供帮助

   Mobile SAST 直接分析 APK、AAB 或 IPA，无需源代码，并对嵌入的 SDK 进行污点分析。Mobile DAST 运行应用，并捕获流量、堆栈跟踪和截图。Ostorlab 还会在发布前发现 API 密钥和令牌等硬编码密钥。

   仍由您负责的部分

   威胁建模、由编码者以外的人员进行的人工代码审查，以及开发人员培训。

4. 04

   《网络安全框架》，H.2.1(2)

   加固移动银行应用

   文本的内容

   对于移动银行和网上银行，应用必须在首次使用时验证客户的手机号码和设备 IMEI 或 ESN，在最长五分钟无操作后终止会话，禁止并发会话，同时允许最多三台经过验证的设备，采用 TLS 证书固定等防范中间人攻击的技术，避免缓存敏感数据并加密存储在设备上的数据，并阻止在已 Root 或已越狱的设备上安装。

   来源：《网络安全框架》，H.2.1(2)

   对您的移动应用意味着什么

   上述每一项都是应用可测试的属性。证书固定和 Root 检测还必须能够抵御攻击者的绕过尝试。

   Ostorlab 如何提供帮助

   Mobile Shielding Scan 在已 Root 和已越狱的环境中运行应用，尝试绕过 Root 和越狱检测、防篡改、反插桩以及 TLS 证书固定，并显示应用是会阻止业务流程、拒绝启动，还是继续运行。Ostorlab 还会在本地存储、缓存、日志和截图中查找令牌和个人数据。

   仍由您负责的部分

   选择和配置您的加固产品，以及设备注册流程。

5. 05

   《网络安全框架》，H.2.1(1) 和 H.4(2)

   为敏感操作增加授权因素

   文本的内容

   对账户激活、密码重置、金融交易以及添加或修改收款人实施额外的授权因素，可使用带外一次性密钥、基于时间或基于哈希的 OTP，或加密认证器。一次性密钥的有效期最长为五分钟。通过电子渠道变更联系方式须采用多因素认证，并将提醒和第二因素发送到原手机号码或电子邮件地址。

   来源：《网络安全框架》，H.2.1(1) 和 H.4(2)

   对您的移动应用意味着什么

   针对收款人、密码重置和联系方式变更的增强验证，正是欺诈者试图跳过的控制措施。无论应用发送什么内容，这些控制都必须在服务器端有效。

   Ostorlab 如何提供帮助

   Ostorlab 使用您的测试账户完成短信、电子邮件或 TOTP 一次性验证码，测试 MFA 强制执行和增强验证流程（包括攻击者试图操纵它们的方式），以及账户变更背后的 API 调用。

   仍由您负责的部分

   选择认证方法以及一次性密钥的发送渠道。

6. 06

   《网络安全框架》，G.3（7.4、7.6、8.3）和 H.3(5)

   正确计算认证因素，并在三次失败后锁定

   文本的内容

   只有在使用至少两个属于不同因素的认证器时，认证才算作多因素认证。设备验证、基于知识的认证、位置和行为生物特征都不属于认证因素。在最多三次认证或授权尝试失败后，必须阻止对电子支付服务的访问，临时密码必须很快失效。

   来源：《网络安全框架》，G.3（7.4、7.6、8.3）和 H.3(5)

   对您的移动应用意味着什么

   如果受信任设备和短信验证码可以被同时获取，二者加起来并不等同于两个因素。锁定和失效必须由后端强制执行。

   Ostorlab 如何提供帮助

   认证测试覆盖登录和注销、令牌刷新、超时、会话失效和 MFA 强制执行，流量分析则显示凭据如何从应用传输到后端。

   仍由您负责的部分

   密码策略、锁定时长以及重新激活程序。

7. 07

   《网络安全框架》，I.3

   保护向第三方开放的 API

   文本的内容

   对于信息访问和支付发起服务提供商，第三方在调用任何 API 之前都必须经过认证，强烈建议使用双向 TLS。用户在登记同意之前须通过至少两个因素的认证，客户端须在 API 层面进行认证，强烈建议使用 OAuth 2.0 和 OpenID Connect，用户可以随时撤回同意。

   来源：《网络安全框架》，I.3

   对您的移动应用意味着什么

   应用背后的 API 以及任何开放 API 都需要对每个请求有效的授权，无论调用方是谁。

   Ostorlab 如何提供帮助

   即使启用 TLS 证书固定，Ostorlab 也能拦截应用流量，测试 API 是否存在失效的授权（BOLA、BFLA、IDOR）、令牌和会话的滥用，以及枚举、重放和自动化等滥用行为，并为每项发现提供请求和响应证据。

   仍由您负责的部分

   第三方接入、VPN 连接、同意管理和 API 风险目录。

8. 08

   CBJ《国家支付系统打击金融欺诈指南》，内部控制程序，C、D 和 G

   将反欺诈控制内置到应用中

   文本的内容

   使用至少两个因素认证客户，避免仅依赖短信 OTP，包括在访问移动应用、执行交易以及在新设备上激活应用时。对于异常会话，或从非受信任设备向新收款人转账的情况，要求第三个因素。移动应用应检测越狱或 Root，并阻止应用运行或限制敏感功能，同时限制并发登录或设备数量。

   来源：CBJ《国家支付系统打击金融欺诈指南》，内部控制程序，C、D 和 G

   对您的移动应用意味着什么

   反欺诈控制位于应用和支付 API 中。已 Root 设备检测、设备绑定和增强验证规则都是您反欺诈防线的一部分。

   Ostorlab 如何提供帮助

   Ostorlab 测试应用及其 API 中与欺诈相关的控制措施：认证、增强验证、会话处理、设备防护以及支付背后的业务逻辑。

   仍由您负责的部分

   交易监控、反欺诈部门、黑名单和客户安全意识教育。

9. 09

   第 (65/2016) 号指令，第 9 条和附件 5

   向审计人员提供测试证据

   文本的内容

   审计委员会和外部审计师须在每年第一季度向 CBJ 提交年度内部 IT 审计报告和年度外部 IT 审计报告。审计计划涵盖的事项包括漏洞评估和渗透测试的效率与充分性，以及电子渠道和电子支付系统的运营控制。

   来源：第 (65/2016) 号指令，第 9 条和附件 5

   对您的移动应用意味着什么

   审计人员会询问应用是如何测试的、发现了什么，以及是否已修复。

   Ostorlab 如何提供帮助

   扫描结果、附有复现步骤的发现以及复测结果，为您逐个版本留下注明日期的记录，说明应用的控制措施如何接受测试和修复。

   仍由您负责的部分

   审计本身、IT 治理框架以及向 CBJ 报告。

本页概述了 CBJ 公开文本的英文版本，核对日期为2026年9月27日。部分文本仅适用于特定类型的牌照，已在文中注明。本页不构成法律意见。