笔者在N年前曾经参与一个第三方支付平台的设计开发工作，这过程中研究了某个国内著名的第三方支付平台，就是因为该平台的设计者轻易
的相信外部传入的数据，不进行校验，导致被我发现了一个致命的漏洞，从而测试性的盗取了2分钱，这个事情一直到2个月后，该平台通过
与网银对账才发现，由于不知道这个致命的漏洞是否已经修复，避免有恶意的人使用该方式去做违法的事情，我在这里只简单描述该漏洞，
而不公开该支付平台的真实身份。
该漏洞出现在充值业务上，实现逻辑请看下面的Sequence diagram：
描述一下流程：
1.客户打开第三方支付平台的充值页面，选择一个银行，填入充值数据（充值虚拟账户、充值金额等），提交表单。
2.充值页面把数据（包括充值数据，第三方支付平台在该银行注册的商户标识）使用银行提供的加密工具进行加密，传递给指定银行的网银系统前台。
3.网银系统前台产生一张转账订单，并要求用户输入账号、密码，然后提交。
4.网银系统后端校验账号和密码，然后根据用户账号，充值金额，第三方支付平台商户标识，把金额从用户账号转账到第三方支付平台账号。
5.网银系统把确认数据（充值虚拟账户、充值金额、充值结果、转入商户标识等）加密后重定向到第三方支付平台结果页面。
6.页面把确认数据提交给后台，并向客户显示充值成功。
7.第三方支付平台后台接收到确认数据，把虚拟金额充入虚拟账户，完成整个流程。
漏洞描述：
我们可以看到，用户在第三方支付平台充值页面提交数据，和网银向第三方支付平台发送确认数据，都需要对数据进行非对称加密，但在当
时，我发现某一银行，竟然不提供发送充值数据时的加密工具，这意味着，选择这家银行，用户必须以明文的格式提交充值数据，好了，这
下我可以尝试进行man in the middle attack了，在我提交表单一刻，我把页面的HTML脚本修改了，把提交时由第三方支付平台指定的在所
选银行注册的商户标识修改为另外一个商户的标识（假设是我自己注册的商户），OK，这意味着我的充值金额从我的账号转到我修改后的注
册商户账号，这时，该网银把确认数据（注意，包括转入商户标识，这时的商户标识是我修改后的标识）发送回第三方支付平台，其实，如
果第三方支付平台如果能进一步校验确认数据中的注册商户标识，就能发现注册商户标识被恶意篡改，从而导致充值失败，但该平台的设计
人员却假设之前的充值页面已经自动填入了自己的注册商户标识，这里并不作校验，从而导致这个致命的漏洞，钱没有转到自己的账号上，
而自己却把等额的虚拟资金充值到了第三方虚拟账户中。
特别声明：本文内容纯属用于技术研讨，任何人尝试使用本文的信息实施非法行为而导致的任何损失和责任，本人概不负责。