更改域名代理商对网站有影响吗,如何免费简单建一个网站,网站推广优化如何做,wordpress qtranslate1. 客户端直接verify苹果的receipt 如果verify成功 自行发放商品2. 客户端将receipt传给server,由server进行验证并发放商品按照安全性原则, 客户端的所有信息都是不可信的,而且支付是业务中的核心模块,所以应该选择第二种。下面简要介绍下,第二种方式的简单流程。1. 客户端支付…1. 客户端直接verify苹果的receipt 如果verify成功 自行发放商品2. 客户端将receipt传给server,由server进行验证并发放商品按照安全性原则, 客户端的所有信息都是不可信的,而且支付是业务中的核心模块,所以应该选择第二种。下面简要介绍下,第二种方式的简单流程。1. 客户端支付成功,拿到receipt2. 客户端将receipt传到服务端3. 服务端去apple验证receipt 如果验证成功 就发放receipt中的商品支付安全性作为支付,安全性是第一位的下面简要分析一下常用的攻击手段。1、劫持apple server攻击 通过dns污染,让客户端支付走到假的apple_server,并返回验证成功的response。 这个主要针对支付方式一 如果是支付方式二 就无效。2、重复验证攻击 一个receipt重复使用多次3、跨app攻击 别的app的receipt用到我们app中来4、换价格攻击 低价商品代替高价商品5、歧义攻击 iap支付之前的status0表示verify成功 而现在变为status0只能表示receipt合法 具体支付详情需要通过in_app字段决定 For iOS 6 style transaction receipts, the status code reflects the status of the specific transaction’s receipt.6、中间人攻击 伪造apple_server,如果用户支付就将劫持apple server攻击通过dns污染,让客户端通过假的apple_server进行verify,从而认为自己支付成功。这个主要针对**支付方式一**,如果是支付方式二,就没效果了。常见的iap hack软件iAPFree iAP Cracker 就是用的类似原理。重复验证攻击因为同一个receipt,如果第一次验证成功,那么之后每次验证都会成功。如果服务端没有判重机制,就会导致一个receipt被当做多次充值处理。为了预防这种情况,我们可以将receipt做一次md5得到receipt_md5, 每次发送充值请求的时候就按照receipt_md5判重,如果重复就停止商品发放。跨app攻击通过在别的app中拿到receipt,然后发送到我们app中。因为这个receipt是合法的而且apple不会验证请求的源,所以这个receipt是可以验证通过的。对于这种情况,我们可以判断apple verify的返回值apple_callback_data中对应的bundle_id和我们app的bundle_id是否一样来进行验证。换价格攻击在同一个app中,用低价商品的receipt伪造购买高价商品。这时候bundle_id和我们app的bundle_id是一致的。针对这种情况, 我们可以从apple verify的返回值apple_callback_data中拿到对应的PRoduct_id, 并按照product_id来进行充值。 **不要信任客户端的product_id**歧义攻击在iOS6的时候,status0表示此次支付成功,而现在变为status0只表示receipt**整体上**合法。所以,对iOS7即使是一个过期订单,也会返回status0,如果还按照iOS6的逻辑处理,就会导致假充值。针对iOS7,我们应该不只通过status,还要通过in_app中的内容,来决定如何发放商品。For iOS 6 style transaction receipts, the status code reflects the status of the specific transaction’s receipt.For iOS 7 style app receipts, the status code is reflects the status of the app receipt as a whole. For example, if you send a valid app receipt that contains an expired subscription, the response is 0 because the receipt as a whole is valid.中间人攻击伪造apple server,将我们的支付请求转发到真的apple_server,拿到合法的receipt,并弄个假的receipt给客户端。这样就拿到一个合法的凭证。利用这个合法的receipt,伪造别人充值的请求,从而达到帮别人充值的目的。针对中间人攻击,最重要的是保证a用户的支付receipt,不能被b用户使用。但是apple为了保护隐私,receipt中没有任何用户的个人信息,这就需要我们自己来保证。目前我们用加密的手段来做这个保证。iOS支付的详细流程客户端拿到apple的receipt 并发送到serverserver拿到这个receipt,向苹果验证得到apple_callback_data如果apple_callback_data的status是21007,说明是沙盒模式(不用花钱就可以购买) 要根据具体需求判断处理逻辑,需要注意的是,ios的审核在支付的时候就采用的沙盒模式。如果apple_callback_data的status是0,就要从apple_callback_data[‘receipt’][‘in_app’]这个list中拿到所有的记录,每一个进行充值。然后记录transaction_id和original_transaction_id来防止同一个transaction被重复使用。https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Restoring.htmlhttps://developer.apple.com/library/content/releasenotes/General/ValidateAppStoreReceipt/Chapters/ReceiptFields.html#//apple_ref/doc/uid/TP40010573-CH106-SW1 Original Transaction Identifier返回所有充值成功和重复的transaction_id, 有client来complete transaction总结支付作为核心模块,除了技术上的保证,商务也应该每周进行一次对账。如果发现apple上的收入和服务端记录的收入有比较大的差距,就应该抓紧查看原因。最后给出一个apple_callback_data的例子{status: 0,environment: Production,receipt: {download_id: 75017873837267,adam_id: 1149703708,request_date: 2017-01-13 06:57:20 Etc/GMT,app_item_id: 1149703708,original_purchase_date_pst: 2016-11-17 18:57:09 America/Los_Angeles,version_external_identifier: 820252187,receipt_creation_date: 2017-01-13 05:04:52 Etc/GMT,in_app: [{is_trial_period: false,purchase_date_pst: 2017-01-12 21:04:52 America/Los_Angeles,original_purchase_date_pst: 2017-01-12 21:04:52 America/Los_Angeles,product_id: com.lucky917.live.gold.1.555,original_transaction_id: 350000191094279,original_purchase_date: 2017-01-13 05:04:52 Etc/GMT,original_purchase_date_ms: 1484283892000,purchase_date: 2017-01-13 05:04:52 Etc/GMT,purchase_date_ms: 1484283892000,transaction_id: 350000191094279,quantity: 1}],original_purchase_date_ms: 1479437829000,original_application_version: 26,original_purchase_date: 2016-11-18 02:57:09 Etc/GMT,request_date_ms: 1484290640800,bundle_id: com.lucky917.ios.Live,receipt_creation_date_pst: 2017-01-12 21:04:52 America/Los_Angeles,application_version: 32,request_date_pst: 2017-01-12 22:57:20 America/Los_Angeles,receipt_creation_date_ms: 1484283892000,receipt_type: Production}}
