根据 2016-2017 安全升级的 Paypal IPN 处理

Posted 2023-02-22

【中文标题】根据 2016-2017 安全升级的 Paypal IPN 处理

【英文标题】：Paypal IPN handling in light of 2016-2017 security upgrade

【发布时间】：2017-07-11 16:51:47

【问题描述】：

我对@9​​87654321@ 有疑问。我多年来一直在运行一个使用贝宝的网站，并希望符合IPN Verification Postback to HTTPS 的要求。我担心我在这里收到的任何答复都不是来自贝宝代表的正式答复，但我似乎别无选择，因为PayPal support page 的“询问我们的社区”链接指向此处。

根据我对 IPN 验证回发到 HTTPS 要求的理解，它仅指的是我的网站将我的网站发回 返回到贝宝网站以验证任何传入的 IPN。但是，该文档令人困惑，因为它引用了一些我从未在我的代码中使用过的 URL，即 ipnpb.paypal.com 和 ipnpb.sandbox.paypal.com。

我希望有人可以为我回答这些问题：

1) 我的代码发回至 https://www.sandbox.paypal.com/cgi-bin/webscr 用于沙盒或 https://www.paypal.com/cgi-bin/webscr 用于生产操作。这些贝宝端点会继续工作还是我必须更改它们？

2) 如果您向传入的 IPN 请求发送 301 或 302 重定向，paypal 网关是否会遵循重定向并将 IPN 重新发布到新的 url？ PayPal会在IPN尝试中失败吗？

3) 如果我修改我的 IPN 处理 url 以发送 400 BAD REQUEST，如果有任何不安全（即非 HTTPS）请求访问它，该怎么办？ PayPal 系统会采取任何措施，还是会因为我拒绝回复而丢失通知？

4) 鉴于 paypal 似乎为每笔交易/定期付款/订阅存储 IPN url，如果 PayPal 系统为 IPN 通知指定非 HTTPS 链接，他们将如何处理我的旧交易？ paypal 会直接切换到 HTTPS 吗？订阅/交易/什么会被取消吗？如果我们想遵守，这似乎是非常重要的信息。

编辑：我会在这些问题上再补充两个：

5) paypal 是否提供了我帐户上尝试的传入 API 请求的日志，以便我可以检查是否有任何使用 GET 而不是 POST？

6) paypal 是否有任何 UI 或界面，我可以在其中获取可能为我的系统生成 IPN 的操作列表，以便我可以检查 IPN url？我的网站在我们的网站上使用了 3-5 个不同的 url 来进行 IPN 报告，我们仍然会在其中一些网站上收到 IPN。很高兴看看我们是否可以淘汰一些旧的 IPN 脚本并检查是否使用了 HTTPS 或 HTTP。

【问题讨论】：

整个 Paypal 测试系统是荒谬的。使用起来很复杂，它们有多个域来处理支持、测试、开发，它们之间存在交叉链接，循环往复。当它们完全起作用时，您依赖于极难调试的回调。缺少有关您提出的关键方面的文档，他们的支持人员培训不足。我相信他们只是让 Paypal 死掉，因为他们也拥有 Stripe 的一部分。

【参考方案1】：

绝对是非官方的，但由于指令实际上是在一年前发布的（并修改为将实施推迟到 2017 年），只是分享早期实施的经验 - 我错过了延期通知 :)

底线：TLS 1.2 用于 ALL 与（绑定）Paypal 的安全通信

PayPal 正在升级用于保护所有与我们的系统建立的外部连接的协议。

如果您完成了这项工作（如果您支持大量遗留资源，这可能会很困难），那么就安全路线图而言，您应该是“优秀”的。

to 是我的重点，因为他们没有提及 Paypal 与您的资源的通信（反之：Paypal -> your site）。然而，恕我直言，作为一个电子商务应用程序，并且经过了实施工作的努力，我很难找到在您的应用程序中针对任何/所有电子商务/支付相关流程不实施它的理由（redirecturl，cancelurl，等等）

您可以使用described here 验证/测试您的设置 - 包括您关于重定向、错误代码的问题。尽管 IINM，Paypal 文档包括如何正确响应 IPN 消息（或其任何 API）的协议，以及失败协议（例如retry mechanism）

Paypal 将最好地回答您的最后一个问题（订阅）。我对此事的看法可以追溯到“底线”——全面实施 https/TLS 1.2..

第 ..

---

更新

完全无法处理 301/302 重定向。如果我发送 400 响应，它似乎确实解决了可能发生的情况。听起来这样会导致 PayPal 重试 IPN 多达 15 次

所有 API 都有协议供使用。 official protocol for IPN 声明：

After receiving the IPN message from PayPal, your listener returns an empty
HTTP 200 response to PayPal. Otherwise, PayPal resends the IPN message.

如果您想测试“否则”（例如：如果 30x/40x 或 任何 http 响应，而不是空的 200），那么您 可以 - 但协议已记录在案。

注意：https://ipnpb.x.x 端点也在此处记录

就端点 URL 而言 - 安全升级是关于 HTTP 1.1 和 TLS。您提到的documents include the base urls（带有准备测试的日期，以及何时实施生产限制）-回复：所以在 HTTP 1.1/TLS 1.2 的上下文中，无论 API 端点资源（完整路径-[baseurl]/some/resource/endpoint） 安全更新中包含。

我不为 Paypal 工作，也不声称掌握了他们的所有 API。我会查看您正在使用的特定 API 并检查 API 级别更改 - 重新：端点/资源/字段等，如果有的话（ipnpb 资源是一些 API 级别更改/更新的示例）。

【讨论】：

感谢您在此处提供的信息，但您没有具体解决我提出的 4 个问题中的任何一个。实际上，我已经阅读了您发送的第一个链接，因此我已经使 TLS 1.2 正常工作。您发送的第二个贝宝链接信息量很大，但完全无法解决 301/302 重定向。如果我发送 400 响应，它似乎确实解决了可能发生的情况。听起来这样会导致 PayPal 重试 IPN 多达 15 次。