交易授权备忘录¶

目的与受众¶

本备忘录讨论了开发人员如何保护交易授权并防止其被绕过。这些指南适用于

银行 - 必须为交易授权制定功能性和非功能性要求。
开发人员 – 需要消除交易授权中的漏洞。
渗透测试人员 – 必须确定交易授权是否安全。

简介¶

通常，移动和在线应用程序会要求用户提交第二因子，以便系统可以检查他们是否被授权执行敏感操作（例如电汇授权）。在本文件中，我们称这些行为为交易授权。

交易授权常用于金融系统，但对安全交易的需求促使授权在互联网上得到广泛采用。例如，一封允许用户通过提供秘密代码或带有令牌的链接来解锁用户帐户的电子邮件就包含交易授权。交易授权可以通过以下方法实现

带有交易授权码的卡片
基于时间的动态密码（OTP）令牌，例如OATH TOTP (基于时间的一次性密码)
通过短信发送或通过电话提供的一次性密码
智能卡或智能手机提供的数字签名
挑战-响应令牌，包括未连接的读卡器或扫描用户电脑屏幕上交易数据的解决方案

这些形式的交易授权有些可以通过物理设备或移动应用程序实现。

1. 功能性指南¶

1.1 交易授权方法必须允许用户识别并确认重要的交易数据¶

由于开发人员不能假定用户电脑是安全的，外部授权组件将不得不检查典型交易的数据。

当开发人员构建交易授权组件时，他们应遵循“所见即所签”（What You See Is What You Sign）原则。授权方法必须允许用户识别和确认给定交易的重要数据。例如，在电汇的情况下，用户应该能够识别目标账户和金额。

开发人员在确定哪些交易数据是重要的时，他们的决策应基于：

实际风险
所选授权方法的技术能力和限制
用户获得积极体验

例如，如果短信确认重要的交易数据，开发人员可以通过向用户返回目标账户、金额和转账类型来响应。然而，对于未连接的CAP读卡器来说，要求用户输入这些数据很不方便。在这种情况下，开发人员可能应该返回最少量的重要交易数据（例如部分目标账户号码和金额）以供确认。

通常，用户必须在交易授权过程中验证所有重要的交易数据。如果交易过程要求用户将交易数据输入外部设备，则应提示用户确认交易中的特定值（例如，目标账号）。缺乏有意义的提示很容易被社会工程技术和恶意软件滥用，如下文第1.4节所述。此外，有关输入过载问题的更详细讨论，请参阅此处。

1.2 授权令牌的更改应使用当前授权令牌进行授权¶

如果用户可以使用应用程序界面更改授权令牌，他们应该能够使用当前的授权凭据（如密码更改程序中那样）授权此操作。例如：当用户更改用于接收短信代码的电话号码时，授权短信代码应发送到当前的电话号码。

1.3 授权方法的更改应使用当前授权方法进行授权¶

有些应用程序允许用户选择其交易将如何被授权。在这种情况下，开发人员应确保应用程序能够确认用户的授权方法，以防止任何恶意软件将用户的授权方法更改为最脆弱的方法。此外，应用程序应告知用户与其授权方法相关的任何潜在危险。

1.4 用户应能轻松区分身份验证过程与交易授权过程¶

由于开发人员需要防止用户授权欺诈性操作，他们的应用程序不应要求用户为身份验证和交易授权执行相同的操作。考虑以下示例：

一个应用程序使用相同的方法进行用户身份验证和交易授权（例如，使用OTP令牌）。
恶意软件可以利用中间人攻击，在用户向应用程序提交凭据时向其呈现一个虚假的错误消息，从而诱骗用户重复身份验证过程。第一个凭据将被恶意软件用于身份验证，第二个凭据将被用于授权欺诈性交易。即使是挑战-响应方案也可能在这种情况下被滥用，因为恶意软件可以呈现一个来自欺诈性交易的挑战，并诱骗用户提供响应。这种攻击场景在针对电子银行的恶意软件攻击中被广泛使用。

为了阻止此类攻击，开发人员可以通过以下方式确保身份验证行为与交易授权行为不同：

使用不同的方法进行身份验证和授权
在外部安全组件中采用不同的操作（即在CAP读卡器中使用不同的操作模式）
向用户明确显示他们正在“签署”的内容（所见即所签原则）

尽管采用了身份验证和操作授权方法，仍可能使用社会工程学方法进行攻击，但应用程序不应使此类攻击场景变得更容易。

1.5 每笔交易都应使用唯一的授权凭据进行授权¶

如果应用程序只要求一次交易授权凭据（例如静态密码、通过短信发送的代码或令牌响应），用户就可以在整个会话期间授权任何交易，或者在需要授权交易时重复使用相同的凭据。在这种情况下，攻击者可以利用恶意软件嗅探凭据，并在用户不知情的情况下使用它们来授权任何交易。

2. 非功能性指南¶

2.1 授权应在服务器端执行和强制实施¶

如同所有其他安全控制一样，交易授权应在服务器端强制执行。绝不应通过修改从客户端流向服务器的数据来影响授权结果，例如：

篡改包含交易数据的参数
添加/删除将禁用授权检查的参数
导致错误

为确保数据仅在服务器端管理，应应用安全编程最佳实践，例如：

默认拒绝
避免在生产代码中使用调试功能

应考虑其他保护措施以防止篡改，例如加密数据以保证机密性和完整性，然后在服务器端解密和验证数据。

2.2 授权方法应在服务器端强制实施¶

如果向用户提供了多种交易授权方法，服务器端必须确保交易使用用户选择的授权方法或应用程序策略强制执行的授权方法进行。否则，恶意软件可能会将授权方法降级到最不安全的授权方法。开发人员必须使攻击者无法通过操纵客户端提供的参数来更改所选的授权方法。

如果被要求添加一种增强安全性的新授权方法，开发人员应特别小心。不幸的是，开发人员经常决定在旧代码库的基础上构建新的授权方法。这种情况是不安全的，攻击者可以通过操纵客户端，使用旧方法发送参数来成功授权交易，尽管应用程序已经切换到新方法。

2.3 交易验证数据应在服务器端生成¶

如果开发人员决定以编程方式将重要的交易数据传输到授权组件，他们应格外小心，防止客户端在授权时对交易数据进行任何修改。所有重要的交易数据必须由用户验证，在服务器上生成和存储，然后传递给授权组件，并且不能有任何被客户端篡改的可能性。

当开发人员在客户端收集重要的交易数据并将其传递到服务器时，恶意软件可能会操纵数据并在授权组件中显示伪造的交易数据。

2.4 应用程序应防止授权凭据被暴力破解¶

开发人员必须确保他们的应用程序不能允许攻击者在交易授权凭据提交给服务器进行验证时进行暴力破解。在达到设定次数的失败授权尝试后，应重新启动整个交易授权过程。此外，还有其他方法可以防止暴力破解和阻止其他自动化相关技术，请参阅OWASP 身份验证备忘录。

2.5 应用程序应控制允许的交易状态转换¶

交易授权通常分多步执行，例如：

用户输入交易数据。
用户请求应用程序授权。
应用程序初始化授权机制。
用户验证/确认交易数据。
用户响应授权凭据。
应用程序验证授权并执行交易。

**开发人员必须确保交易授权的业务逻辑流按顺序发生，以便用户（或攻击者）无法乱序执行步骤，甚至跳过任何步骤。这应该能防范以下攻击技术：

在用户输入授权凭据之前覆盖交易数据
跳过交易授权

请参阅OWASP ASVS 要求15.1)。

2.6 交易数据应受到保护，防止被修改¶

开发人员绝不能允许攻击者在用户首次输入数据时修改交易数据。不良实现可能允许恶意软件：

在用户输入授权凭据之前，在后台重放第2.5节中的第一步（发送交易数据），然后用欺诈性交易覆盖交易详情。
创建新的交易数据参数并将其添加到正在授权交易的HTTP请求中。在这种情况下，执行不佳的交易授权过程可能会授权初始交易，然后执行欺诈性交易（检查时与使用时漏洞的具体示例）。

有多种方法可以防止交易数据在授权过程中被修改：

如果交易数据被修改，代码可能会使任何先前输入的授权数据（例如，生成的OTP）和挑战失效。
对交易数据的修改可能会触发授权过程的重置。
任何在用户输入后尝试修改交易数据的行为都是对系统的攻击，应记录、监控并仔细调查。

2.7 在所有客户端-服务器通信过程中，交易数据的机密性应受到保护¶

交易授权过程应保护用户将授权的交易数据的隐私（即第2.5节的步骤2和4）。

2.8 系统应检查每笔交易的执行，并确保其已得到适当授权¶

交易录入和授权过程（如第2.5节所述）的最终结果也称为交易执行。在交易执行之前，应该有一个最终的控制门，验证交易是否已由用户正确授权。此控制应与执行绑定，并防止诸如以下攻击：

检查时与使用时（TOCTOU）——示例见第2.6节
在交易录入过程中跳过授权检查（参见第2.5节）

2.9 授权凭据的有效期应仅限于有限的时间段¶

在某些攻击中，用户的授权凭据被恶意软件传递到命令和控制服务器，然后从攻击者控制的机器使用。通常，这个过程是由攻击者手动执行的。为了确保这些攻击难以实现，服务器应只允许在有限的时间窗口内进行交易授权，该窗口应发生在挑战（或OTP）的生成和授权完成之间。此外，这种保护措施也将有助于阻止资源耗尽攻击。这个时间段应仔细选择，以免干扰正常的用户行为。

2.10 授权凭据应在每次操作中都是唯一的¶

为防止多次重放攻击，每组授权凭据在每次操作中都应是唯一的。这些凭据可以根据机制的不同通过不同方法生成。例如：开发人员可以在签名交易数据中或作为挑战的一部分使用时间戳、序列号或随机值。

备注¶

以下是在实施交易授权时应考虑的一些其他问题，但超出了本备忘录的范围：

哪些交易应该被授权？是所有交易还是仅其中一部分？每个应用程序都不同，应用程序所有者应决定是否所有交易都应被授权，或仅其中一部分。开发人员应考虑风险分析、给定应用程序的风险暴露以及应用程序中实现的其他保护措施。
我们建议使用加密操作来保护交易并确保完整性、机密性和不可否认性。
在设备“配对”期间，提供和保护设备签名密钥至关重要，其重要性不亚于实际的签名协议本身。恶意软件可能会尝试注入/替换或窃取签名密钥。
用户意识：例如在交易授权方法中，当用户将重要的交易数据输入授权组件（例如外部专用设备或移动应用程序）时，应培训用户从受信任的来源而不是从计算机屏幕重写交易数据。
存在一些防恶意软件解决方案可以抵御此类威胁，但这些解决方案不可能达到100%的有效性，仅应作为额外的保护层使用。
使用第二因子（如密码、生物识别等）或利用安全元件（TEE、TPM、智能卡）来保护您的签名密钥。

参考文献与延伸阅读¶

参考文献与延伸阅读

Wojciech Dworakowski: 电子银行交易授权 - 可能的漏洞、安全验证和实施最佳实践。2015年AppSec EU演示。
Saar Drimer, Steven J. Murdoch, and Ross Anderson: 注定失败 - 在线银行读卡器。
Jakub Kałużny, Mateusz Olejarka: 基于脚本的恶意软件检测在网上银行安全中的概述。
支持2FA的网站列表.
Laerte Peotta, Marcelo D. Holtz, Bernardo M. David, Flavio G. Deus, Rafael Timóteo de Sousa Jr: 网上银行攻击和漏洞的正式分类。
Marco Morana, Tony Ucedavelez: 银行恶意软件攻击的威胁建模。
OWASP 反恶意软件 - 知识库。
OWASP 反恶意软件项目 - 意识计划。
Arjan Blom , Gerhard de Koning Gans , Erik Poll , Joeri de Ruiter , and Roel Verdult: 注定失败 - 用于网上银行的USB连接读卡器