电商API接口|电商平台使用的物流API的安全风险

电子商务平台的物流 API 如果出现安全漏洞，则消费者的个人信息会被大量暴露。

物流 API 整合了企业和第三方供应商之间的数据和服务，以解决各种市场需求。如果 电商API 接口集成不当，可能会出现泄露个人身份信息 (PII) 的风险。许多使用 API 通信的垂直行业应该得到足够的保护，尤其是在传输敏感数据时。否则，无意的 PII 泄漏不仅会对未能履行其法律或合规义务的组织造成严重后果，也会对暴露 PII 的消费者造成严重后果。

什么是外部物流供应商？

外部物流供应商说白了就是商家用来交付产品的快递服务（第二方物流或 2PL），也可以是由仓储、电商平台和交付产品组成的第三方物流 (3PL) 服务。下图显示了外部物流提供商在不同用例中的工作方式。

外部物流提供商如何在不同用例中发挥作用

最初，研究人员调查了通过不安全的方法无意中暴露PII的3PL和4PL提供商。但随着研究的深入，我们也发现，除了 3PL 和 4PL 提供商会暴露敏感信息外，已经集成到其系统中的服务也存在自身的安全漏洞，从而加剧了整个电子商务生态系统的风险。电子商务平台允许商家通过 API 整合现有的外部物流提供商，将不同的服务整合到一个平台中。电子商务平台和物流提供商共享的 API 密钥和身份验证密钥旨在促进一个安全的通信渠道。

PII是如何从电子商务和物流API实现中泄露的？

PII 从物流 API 实施中暴露的方式有很多，这些方式与不安全的编码做法相关。

URL查询参数

不经意间暴露PII的一个编码做法涉及电子商务平台和物流API 中的 URL 查询参数。电子商务平台通常要求客户登录帐户或选择访客结帐选项。一些在线购物网站使用他们通过电子邮件或短信发送给用户的唯一 URL，将他们重定向到可以访问订单信息的网站。

将发送到收件人拥有的电子邮件地址或电话号码的唯一URL的组合使用足以保护PII的假设是有问题的，因为这会产生错误的安全感。研究表明，未经授权的各方仍然可以通过直接访问URL来检索客户的PII，而不需要进一步的身份验证。

URL参数中的身份验证密钥

当消费者在在线商店下订单时，商店会向他们发送一封确认电子邮件，其中包含 URL 链接和 URL 参数上的身份验证密钥，以查看订单详细信息。此密钥用于验证检查订单页面的用户是否是电子邮件的收件人。订单页面包含客户姓名、电子邮件地址、电话号码和付款方式等信息。

尽管没有正确的身份验证，但仍然显示客户的PII

将身份验证密钥作为 URL 参数的一部分传递的做法可能会泄漏 PII，因为这些密钥仍然可以使用其他方式检索，例如访问用户的浏览历史记录和路由器日志。使用未加密的 URL 查询参数使 PII 容易受到嗅探和中间人攻击。

未经身份验证的 3PL API

虽然在线零售商使用的 3PL 服务的基本组件包括订单处理、运输和跟踪，但我们还发现 3PL 提供商的 API（在下图中称为 X 公司）通过未经身份验证的 API 服务披露 PII。其他四家 3PL 提供商正在使用此 API 服务来显示客户的订单信息。

四家 3PL 公司使用另一家 3PL 公司的 API 检索订单和跟踪信息

当我们通过四个 3PL 提供商中的一个提供的 URL 链接检查订单信息页面，并检查为查看订单详细信息而发出的 HTTP 请求时，研究人员发现他们正在查看的页面正在后台向另一个 3PL 发出 HTTP 请求供应商获取订单详情。

从 API 请求中检索到的数据显示了完整的客户信息集

研究人员仔细检查了订单信息页面 URL 的参数。其中一个在后台发出的 API 请求使用未经身份验证的方法来验证 API 请求，该请求返回了有关客户和所购买商品的完整信息集。因此，任何有权访问订单信息 URL 的人都可以重建 URL 以检索客户的 PII。

过期设置超过建议持续时间的会话和 cookie

另一种不安全的编码做法是某些 3PL 提供商使用会话和 cookie 的过期日期设置不当。我们观察到许多 3PL 提供商不遵守特定于使用会话和 cookie 来规范身份验证的最佳安全做法的实例。此方法是开放 Web 应用程序安全项目 (OWASP) 推荐的最佳做法之一，尽管会话生存时间 (TTL) 应始终在事务完成后或用户退出连接后立即过期。攻击者可以使用检测到的 cookie 密钥来重放交易并获取 PII，他们可以利用这些 PII 来启动恶意计划。

该列表显示了过期日期设置超过 OWASP 建议的持续时间的 cookie，从而使 cookie 信息可供攻击者重播交易

解决不安全编码做法的安全建议

泄露的 PII 的诱惑、其潜在的恶意用途以及 API 在电子商务中发挥的关键作用，都强有力地证明了利益相关方需要采用一种审慎的方法来确保物流API实现的安全性。

以下是如何改进编码做法的一些建议。

1.会话和cookie过期

会话过期决定何时终止会话与服务器的经过身份验证的连接。默认情况下，该时间设置为一天，或者会话在用户停止与网站的连接后终止。相同的机制适用于 cookie 过期。一旦用户不再在网站上执行任何操作，应激活会话超时，以防止重复使用过期的 cookie。

2. 过多的数据暴露

当暴露超出事务要求的数据时，就会发生过多的数据暴露。一些开发人员实现发送交易的所有信息，而不是完成交易所需的信息。这会造成数据暴露给具有访问限制或有限权限的帐户的情况。物流API泄露的数据可能被用于诈骗或欺诈。

从 API 响应中暴露过多信息

开发人员应采用识别交易所需的重要客户信息并对其风险级别进行分类的做法。

3. 破坏对象级授权

对象级授权通常在编码阶段实现，它是一种访问控制策略，用于确保只有经过授权的用户才能访问对象。对象级授权检查应该在接收对象ID并对对象执行任何类型操作的每个API端点中实现。这些测试确保已登录的用户具有对所请求对象执行操作的权限。

在处理PII时，更安全的做法是加密数据并在授予访问权之前要求用户身份验证。当使用3PL API集成时，在与3PL相关供应商共享PII时，应该充分保护PII。有许多不同的身份验证算法可用于保护API事务。令牌如JSON Web令牌(JWT)或使用使用salt编码的base64生成的自定义令牌对于保护API调用是必不可少的。

总之，开发人员应牢记在整个交易过程中应提供哪些数据以及应采取哪些身份验证措施。

给电商平台用户的安全建议

消费者在最大限度地降低 PII 暴露风险方面发挥着同样重要的作用。以下安全做法可以帮助他们保护 PII 的安全：

1.正确处置发货信息，并确保带有 PII 的标签被撕碎或混淆，这样攻击者就无法再阅读它们。

2.删除浏览历史记录，尤其是在公共或共享设备上。

3.避免将未知浏览器扩展安装到可以读取和收集未加密 URL 查询字符串的 Web 浏览器。

4.在公共 Wi-Fi 网络上使用合法的虚拟专用网络 (VPN) 以减少个人数据的暴露。

5.对电子商务平台和其他需要用户输入 PII 的网站实施双因素或多因素身份验证。