Phần không đồng bộ của bộ điều khiển xác minh mới của Apple có cần thiết không?

Question

Tôi đang xem qua bản vá Bộ điều khiển xác minh của Apple để mua ứng dụng tại đây: https://developer.apple.com/library/ios/#releasenotes/StoreKit/IAP_ReceiptValidation/_index.html

Tôi đã lên kế hoạch triển khai xác thực máy chủ nhưng không cần phản hồi ngay lập tức.

Phần không đồng bộ của mã mới hoàn toàn cần thiết hay không. Liệu nó cung cấp bất kỳ lợi thế hơn một xác nhận phía máy chủ ngây thơ?

Nếu tôi chỉ có thể sử dụng phân tích cú pháp ngay lập tức và kiểm tra và nhận được lợi ích, điều đó sẽ tuyệt vời.

Cảm ơn!

EDIT: Câu hỏi này cảm thấy một chút trống rỗng mà không cần một số mã:

Tôi đang nói cụ thể về việc thay đổi chức năng verifyPurchase chính để chỉ chứa:

- (BOOL)verifyPurchase:(SKPaymentTransaction *)transaction; 
{ 
    return [self isTransactionAndItsReceiptValid:transaction]; 
} 

... và thoát khỏi khách hàng -> bài đăng trên máy chủ. Liệu tôi có còn dễ bị tổn thương trước các hacks gần đây không?

Answer 1

Câu hỏi của bạn có ý nghĩa hơn sau khi xem mã.

Cuộc tấn công được đề cập là người nào đó trình bày biên nhận hợp lệ khác của người khác là. Có vẻ như không có bất kỳ thứ gì trong dữ liệu biên nhận liên kết với thiết bị/người mua. Bạn có thể giảm thiểu điều này ở một mức độ nào đó bằng cách kiểm tra ngày mua hàng (nhưng chỉ nếu thiết bị có thời gian chính xác, dưới sự kiểm soát của người dùng).

(Tấn công này sẽ không hoạt động nếu khách hàng tạo ra một nonce 256 bit ngẫu nhiên phải khớp với biên nhận. Một kẻ tấn công rõ ràng có thể hack nhị phân/PRNG, nhưng trong cả hai trường hợp bạn đã mất.)

Ngẫu nhiên, các mã có một loạt các vấn đề:

• Vui lòng cung duy nhất của máy chủ cert là nó là một EV cert. Điều này sẽ dễ dàng giả mạo, vì kẻ tấn công có toàn quyền kiểm soát CA.
• ID giao dịch được thêm vĩnh viễn vào danh sách giao dịch "đã xem" trong -isTransactionAndItsReceiptValid: trước khi kiểm tra mạng kết thúc, nhưng nội dung chỉ được mở khóa sau khi mạng trả về. Biên lai không bao giờ có thể được xác minh lại nếu kết nối không thành công, do đó, tiền của người dùng sẽ có hiệu quả đi vào một lỗ đen.
• Dự kiến ​​giao dịch sẽ xảy ra trên cùng một thiết bị đang xác minh nó.
• Dự kiến ​​ITC_CONTENT_PROVIDER_SHARED_SECRET được nhúng trong tệp thực thi (tầm thường để giải mã bằng thiết bị đã bẻ khóa).
• Giả định rằng -connection:didReceiveData: trả về dữ liệu nhận đầy đủ (điều này có thể không phải do trường hợp phân mảnh, nhưng có thể được đảm bảo vì Apple kiểm soát việc triển khai máy chủ).