PayPal JavaScript SDK - 了解客户端的安全问题

Posted 2023-02-22

【中文标题】PayPal JavaScript SDK - 了解客户端的安全问题

【英文标题】：PayPal JavaScript SDK - understand security problems on the client-side

【发布时间】：2021-03-29 09:05:11

【问题描述】：

我最近在我的 Angular 11 项目 (implementation reference) 中实现了 PayPal javascript SDK。它似乎完美无缺，但是，我开始认为可以在客户端修改定价金额。此外，如果支付的金额实际上与请求的金额相符，PayPal 方面似乎没有进一步的验证。

        paypal.Buttons(
          style: 
            layout: 'vertical',
            color: 'gold',
            shape: 'pill',
            label: 'paypal'
          ,
          createOrder: (data, actions) => 
            console.log(data);
            return actions.order.create(
              purchase_units: [
                
                  reference_id: this.id,
                  description: this.description,
                  amount: 
                    currency_code: 'EUR',
                    value: this.pricing
                  
                
              ]
            );
          ,
          onApprove: (data, actions) => 
            console.log(data);
            return actions.order.capture();
          ,
          onError: error => 
            console.error(error);
          ,
          onCancel: error => 
            console.error(error);
          
        ).render(this.paypalElement.nativeElement);

因此我开始研究客户端安全性，尤其是 PayPal SDK。在这个过程中，我在 *** 上发现了一些有趣的帖子，例如：

PayPal express checkout security with silent ajax call How can I secure transactions made with client-side PayPal Smart Checkout buttons? Secure PayPal Checkout Client-side? PayPal Checkout: Is it safe to receive a payment with only client-side code?

总体共识是：“您说得对，它不安全，您需要在后端执行此操作。”

然而，虽然我现在意识到这似乎不是一个安全的长期解决方案，但上述帖子中的答案都没有提供一些关于攻击者如何实际修改客户端代码的额外信息。在修改客户端 JavaScript 代码方面，我相当缺乏经验，因此我非常希望了解该过程并了解我必须在多大程度上保护我的应用程序。

【问题讨论】：

逻辑中的简单调试器断点将授予攻击者对修改变量的完全访问权限，例如this.pricing

【参考方案1】：

攻击者如何实际修改客户端代码。在修改客户端 JavaScript 代码方面，我相当缺乏经验，因此我非常希望了解该过程并了解我必须在多大程度上保护我的应用程序。

调试器检查点和从浏览器开发工具调试器或控制台修改变量是一种显而易见的方法，对于熟悉所有主流浏览器附带的常规工具的人来说。

如果您不这样做，修改客户端 JS 最直接的方法是下载 JS 文件或 html-with-JS 文档，进行任何您想要的更改，然后使用类似 @987654321 的扩展名提供您的替换@ 并再次完成流程。

在实用性的另一端，客户端可以是自定义浏览器可执行文件，使用任何语言从头开始编写，具有自己的或修改后的 JavaScript 解释器。或者只是像 Firefox 或 Chromium 这样的开源浏览器，经过修改然后编译。

基本上，客户端有可能发送、接收和执行它（因此也是攻击者）想要的任何命令。这是完全不安全的，您的服务器必须验证您想要验证的所有内容。不是某些事情，而是所有事情。

因此，始终假设客户端_可能_是 100% 的恶意行为者，并且完全不信任，因为它应该来自“您自己的”客户端代码。

【讨论】：

好的，这绝对让我对客户端安全有了更多的了解（不安全性比其他 *** 帖子，谢谢。