关于应用中支付中安全一些总结
2014-09-19 17:39
471 查看
通常涉及到支付的应用分为实物类和虚拟类,前一类以影票和购物为主,通过支付后,会生成订单,订单中包含的一些信息,后一类以杂志为多,并不需要生成订单,对于应用开发来说只是一些是否购买,只是一些逻辑的不同,对于这两类在支付的过程中和应用上线后都或多或少的出现问题,下面足以分析。
实物类和虚拟类都容易出现的问题:
由于支付宝的支付报文和私钥公钥等都在第三方应用里维护着,所以在客户端里存在篡改报文的问题(这个方面支付宝不如银联,银联的处理是银联和应用服务端交互,生成一个sid给银联插件,所有逻辑和数据都有插件和银联服务器交互)。
解决方案: 篡改报文,对于支付宝,只要不修改支付模式,这个没有办法解决,可以弥补就是支付宝支付完成之后会回调应用服务端,在回调中将交易信息和数据同时给了服务端,在服务端做验证,交易数据(钱数)和自己的订单数据是否一致,自己控制本次交易是否失败。对于实物类应用,判断后交易影响不大。
虚拟类容易出现的问题:
虚拟类的有很多逻辑是在客户端处理的,对于是否支付,简单的可能只是通过一种boolean状态去判断的,支付在客户端得到支付宝的支付成功逻辑之后认为交易成功。
解决方案: 对于此种逻辑尽可能的移植到服务器中,特别是重要内容,比如杂志类项目中的文章在加载打开由服务端判断。
实物类和虚拟类都容易出现的问题:
由于支付宝的支付报文和私钥公钥等都在第三方应用里维护着,所以在客户端里存在篡改报文的问题(这个方面支付宝不如银联,银联的处理是银联和应用服务端交互,生成一个sid给银联插件,所有逻辑和数据都有插件和银联服务器交互)。
解决方案: 篡改报文,对于支付宝,只要不修改支付模式,这个没有办法解决,可以弥补就是支付宝支付完成之后会回调应用服务端,在回调中将交易信息和数据同时给了服务端,在服务端做验证,交易数据(钱数)和自己的订单数据是否一致,自己控制本次交易是否失败。对于实物类应用,判断后交易影响不大。
虚拟类容易出现的问题:
虚拟类的有很多逻辑是在客户端处理的,对于是否支付,简单的可能只是通过一种boolean状态去判断的,支付在客户端得到支付宝的支付成功逻辑之后认为交易成功。
解决方案: 对于此种逻辑尽可能的移植到服务器中,特别是重要内容,比如杂志类项目中的文章在加载打开由服务端判断。
相关文章推荐
- 关于Android应用开发的一些安全注意事项
- 关于Android应用开发的一些安全注意事项
- 一些关于HTML与CSS的总结与实际应用
- 【阶段总结】关于C# WinForm程序的一些应用总结
- 关于app集成支付宝应用内支付的问题总结
- Spring MVC学习总结(5)——SpringMVC项目关于安全的一些配置与实现方式
- 关于关联容器set的一些应用总结
- Spring MVC学习总结(5)——SpringMVC项目关于安全的一些配置与实现方式
- 关于app集成支付宝应用内支付的问题总结
- 关于苹果支付ApplePay的一些个人总结
- 关于字符函数的一些应用总结
- 关于boost库性能与安全的一些总结
- 关于NTFS文件夹的安全权限分配的一些总结
- 关于Android应用开发的一些安全注意事项
- 关于递归思想与prolog中的一些递归应用总结
- 关于app集成支付宝应用内支付的问题总结
- 关于Android应用开发的一些安全注意事项
- 关于事务、ThreadLocal应用、CompletionService的一些总结
- Spring MVC学习总结(5)——SpringMVC项目关于安全的一些配置与实现方式