将授权令牌从 parent window 发送到 iframe 源，以便 iframe 源可以进行调用
Sending an authorization token from parent window to iframe origin so that iframe origin could make the call
我正在开发一个 SDK，可以为 e-commerce 无权拥有信用卡数据 (cc_data) 的公司（商家）接受在线卡支付。目前我正在努力想出一个合适的解决方案来保护 API.
currents 解决方案 使用无状态会话（不会更改）并且如下：
支付表单初始化
- 商家使用 HTTP 基本身份验证进行 API 调用以启动付款；
- 作为回应，商家会获得支付链接和令牌；
- 商家使用支付链接调用 iframe：每个输入（名称、cc_number 等）都有一个 iframe，包括作为 iframe 提交。这应该提供尽可能少的pre-design，以便商家可以设计自己的付款方式；
iframe，收集cc_data并提交
- 对于每个 iframe 都有对应的 html 和 javascript。例如。 name.html 与 name.js、submit.html 与 submit.js。来自输入的数据被存储到会话存储中；
- 一旦提交被推送，submit.js 将 AJAX 调用支付 API 端点（我们自己的服务器，因此为了内部安全使用 CSRF 令牌）到 post cc_date.
问题
现有支付 API 端点也需要提供给商家的令牌，但我还没有找到从商家那里获取令牌的合理解决方案，因为系统是无状态的。在某种程度上，我的解决方案没有遵循标准令牌授权，其中令牌是为用户授权其操作而提供的，因为用户（在我的例子中是商家）没有调用该操作。我只使用我自己的服务器提供的 CSRF 令牌来调用它。
可能的解决方案
在我看来，在某种程度上，也许我应该完全放弃令牌授权的想法，因为这不是它的情况 - 商家没有拨打电话，因此不需要授权（并且在期间付款启动它已经验证了自己）。但一些开发人员确实指出，在我的情况下，CSRF 令牌可能不够安全，因为他们有可能访问它（例如，模仿网络浏览器，令牌被保存的地方）然后他们能够滥用付款 API 令牌有效期间的端点。
考虑到前面提到的情况，我仍在尝试找到一种解决方案，以能够实现 API 安全性的方式传达授权令牌。显而易见的可能解决方案是使用 postMessage() 将令牌从商家 (parent window) 发送到 submit.js（iframe 来源）。但我不太喜欢这个想法，因为有很多可能的来源，令牌可能来自哪里，因此我无法做出合理的过滤器，我从哪里排除消息。将令牌发布到服务器不是一种选择，因为它是无状态的......并且调用 iframe 不提供包含 headers.
的可能性
提出想法
所以目前我正在寻找解决方案，并认为 Whosebug 可能是寻求建议的最佳场所。也许我应该完全改变我目前的概念证明（这意味着我的问题没有好的解决方案），所以也欢迎在这个层面上提出建议。当然，还要考虑到服务器是无状态的，cc_data一定不能到达商户，整个支付表单的设计尽可能在商户的控制下。
提前感谢您的建议。
这是我第一次 post 使用 Whosebug（几周前我作为初级开发人员开始工作），这是一次全新而有趣的体验。
编辑：
业务需要
- 无需重定向的付款，付款表格显示在商家网站上；
- 商家应尽可能多地控制付款表单设计（在初始化付款时，商家也可以为 iframe 来源选择样式）；
- 商家无权访问 cc_data（或以商家可以理解的形式拥有）
实际上我第二天就自己解决了这个问题，但我想先在实践中检查我的解决方案。答案其实很简单：double submit cookies.
所以基本上，无论何时使用 submit.js 调用 submit.html（负责将支付数据发送到 API 端点的 iframe 按钮），它都会从 back-end 服务器。服务器也会使用 https 安全 cookie 将加密 cookie 附加到 submit.html。
现在，每当 submit.js 调用 API 端点时，CSRF 令牌将与 header 一起发回。 Back-end 服务器获取附加到 submit.html 的加密 cookie，解密并将其与 header 中的 CRSF 令牌进行比较。如果匹配，则请求有效。
可以在此处找到更多信息：OWASP cheat cheet。
我正在开发一个 SDK，可以为 e-commerce 无权拥有信用卡数据 (cc_data) 的公司（商家）接受在线卡支付。目前我正在努力想出一个合适的解决方案来保护 API.
currents 解决方案 使用无状态会话（不会更改）并且如下：
支付表单初始化
- 商家使用 HTTP 基本身份验证进行 API 调用以启动付款；
- 作为回应，商家会获得支付链接和令牌；
- 商家使用支付链接调用 iframe：每个输入（名称、cc_number 等）都有一个 iframe，包括作为 iframe 提交。这应该提供尽可能少的pre-design，以便商家可以设计自己的付款方式；
iframe，收集cc_data并提交
- 对于每个 iframe 都有对应的 html 和 javascript。例如。 name.html 与 name.js、submit.html 与 submit.js。来自输入的数据被存储到会话存储中；
- 一旦提交被推送，submit.js 将 AJAX 调用支付 API 端点（我们自己的服务器，因此为了内部安全使用 CSRF 令牌）到 post cc_date.
问题
现有支付 API 端点也需要提供给商家的令牌，但我还没有找到从商家那里获取令牌的合理解决方案，因为系统是无状态的。在某种程度上，我的解决方案没有遵循标准令牌授权，其中令牌是为用户授权其操作而提供的，因为用户（在我的例子中是商家）没有调用该操作。我只使用我自己的服务器提供的 CSRF 令牌来调用它。
可能的解决方案
在我看来，在某种程度上，也许我应该完全放弃令牌授权的想法，因为这不是它的情况 - 商家没有拨打电话，因此不需要授权（并且在期间付款启动它已经验证了自己）。但一些开发人员确实指出，在我的情况下，CSRF 令牌可能不够安全，因为他们有可能访问它（例如，模仿网络浏览器，令牌被保存的地方）然后他们能够滥用付款 API 令牌有效期间的端点。
考虑到前面提到的情况，我仍在尝试找到一种解决方案，以能够实现 API 安全性的方式传达授权令牌。显而易见的可能解决方案是使用 postMessage() 将令牌从商家 (parent window) 发送到 submit.js（iframe 来源）。但我不太喜欢这个想法，因为有很多可能的来源，令牌可能来自哪里，因此我无法做出合理的过滤器，我从哪里排除消息。将令牌发布到服务器不是一种选择，因为它是无状态的......并且调用 iframe 不提供包含 headers.
的可能性提出想法
所以目前我正在寻找解决方案，并认为 Whosebug 可能是寻求建议的最佳场所。也许我应该完全改变我目前的概念证明（这意味着我的问题没有好的解决方案），所以也欢迎在这个层面上提出建议。当然，还要考虑到服务器是无状态的，cc_data一定不能到达商户，整个支付表单的设计尽可能在商户的控制下。
提前感谢您的建议。
这是我第一次 post 使用 Whosebug（几周前我作为初级开发人员开始工作），这是一次全新而有趣的体验。
编辑： 业务需要
- 无需重定向的付款，付款表格显示在商家网站上；
- 商家应尽可能多地控制付款表单设计（在初始化付款时，商家也可以为 iframe 来源选择样式）；
- 商家无权访问 cc_data（或以商家可以理解的形式拥有）
实际上我第二天就自己解决了这个问题，但我想先在实践中检查我的解决方案。答案其实很简单：double submit cookies.
所以基本上，无论何时使用 submit.js 调用 submit.html（负责将支付数据发送到 API 端点的 iframe 按钮），它都会从 back-end 服务器。服务器也会使用 https 安全 cookie 将加密 cookie 附加到 submit.html。
现在，每当 submit.js 调用 API 端点时，CSRF 令牌将与 header 一起发回。 Back-end 服务器获取附加到 submit.html 的加密 cookie，解密并将其与 header 中的 CRSF 令牌进行比较。如果匹配，则请求有效。
可以在此处找到更多信息：OWASP cheat cheet。