Trong mô-đun BillingService, những gì cần phải được sửa đổi để tăng cường bảo mật?

Question

Các bình luận cho lớp BillingService khuyến cáo rằng:

Bạn nên sửa đổi và xáo trộn mã này trước khi sử dụng nó.

OK, nhưng phải sửa đổi gì?

Tên lớp học? TAG được sử dụng để đăng nhập? Tên phương thức và thành viên dữ liệu? Luồng logic và chương trình chính nó? Khác?

Nói cách khác, tôi có thể hiểu sự cần thiết phải làm phiền, nhưng làm cách nào tôi có thể thực hiện đề xuất mà không cần viết lại mọi thứ từ đầu (có khả năng có lỗi tồi tệ hơn là không sửa đổi bất kỳ thứ gì)?

Answer 1

Tôi đang làm việc về vấn đề này tại thời điểm này và cách tiếp cận của tôi, cho đến nay, là như sau:

1. Tôi đang sử dụng BillingReceiver, dịch vụ thanh toán, PurchaseObserver và ResponseHandler.
2. Tôi đã chuyển tất cả các hằng số vào lớp Constants của riêng tôi và tất cả các lớp ở trên được bao gồm trong gói của riêng tôi.
3. Tôi đã làm việc với lớp PurchaseDatabase và các phần tích hợp của nó vào cơ sở dữ liệu SQLite, DBAdapter và các lớp truy cập dữ liệu của riêng tôi.
4. Tôi đã thay đổi CatalogEntry thành đối tượng mô hình của riêng mình và giao diện người dùng của tôi sẽ hoàn toàn khác với ví dụ, ví dụ: Nhóm RadioButton thay vì Spinner cho các mục sản phẩm (Tôi chỉ có 4).
5. Nó nói trong lớp Bảo mật 'Để thực hiện an toàn, tất cả mã này nên được triển khai trên máy chủ giao tiếp với ứng dụng'. Tôi 'may mắn' rằng ứng dụng của tôi phải liên hệ với máy chủ của tôi, vì vậy tôi sẽ triển khai các biện pháp bảo mật này trên máy chủ và tôi sẽ thực hiện xác thực thông tin mua hàng của mình được chuyển đến máy chủ. Tôi đang tìm cách để bảo đảm một phần của các comms bằng cách sử dụng SSL và tôi đã yêu cầu một tên người dùng/mật khẩu trước (băm và muối) được lưu trữ trên máy chủ của tôi.
6. Tôi đang cắt bỏ bất kỳ mã thừa nào khác mà tôi không sử dụng, ví dụ: chỉnh sửa tải trọng.
7. Một số phương pháp có 5 hoặc 6 tham số trong chữ ký của họ, ví dụ: onPurchasestateChanged() - Tôi đã suy nghĩ về việc kết hợp chúng thành một đối tượng bao bọc đơn (nhưng vẫn chưa thực hiện).
8. Tôi đang thử nghiệm từ từ và kỹ lưỡng để tôi hiểu điều gì đang diễn ra và thực hiện theo các đề xuất. Tôi đã sử dụng mẫu hoàn chỉnh lúc đầu để đảm bảo nó hoạt động và kiểm tra các phản hồi tĩnh. Sau đó, tôi bắt đầu thực hiện các thay đổi của riêng mình trong khi vẫn thực hiện thử nghiệm tĩnh. Tôi vẫn đang thử nghiệm với các phản hồi tĩnh và tôi sẽ theo dõi luồng thông điệp để hiểu các giao điểm đang diễn ra. Một khi tôi hài lòng với điều này tôi sẽ kiểm tra với sản phẩm của riêng tôi Id và cố gắng và đáp ứng bản thân mình trên dữ liệu và bảo mật của nó.
9. Tôi đã nghĩ chuỗi developerPayload cũng có thể được ký và mã hóa và khi được trả về máy chủ của tôi, được giải mã và kiểm tra tính toàn vẹn.
10. Cuối cùng, tôi sẽ làm xáo trộn mã bằng cách sử dụng ProGuard và làm theo một số mẹo để làm như vậy có sẵn trên StackOverflow.

Hy vọng điều này sẽ hữu ích.

Answer 2

Họ giải thích nó như sau:

Các trong ứng dụng ứng dụng mẫu thanh toán được công khai phân phối và có thể được tải bởi bất cứ ai, có nghĩa là nó là tương đối dễ dàng cho kẻ tấn công thiết kế đối chiếu ứng dụng của bạn nếu bạn sử dụng mã mẫu chính xác như được xuất bản. Ứng dụng mẫu dành cho chỉ được sử dụng làm ví dụ. Nếu bạn sử dụng bất kỳ phần nào của ứng dụng mẫu , bạn phải sửa đổi nó trước khi xuất bản hoặc phát hành nó như là một phần của một ứng dụng sản xuất.

Cụ thể, kẻ tấn công tìm kiếm các điểm vào và điểm xuất cảnh đã biết trong một ứng dụng, vì vậy điều quan trọng là bạn sửa đổi các phần này của mã của bạn giống với ứng dụng mẫu.

Điều đó có nghĩa là không sử dụng mã như được cung cấp, thay đổi một số phần của nó để tin tặc sẽ không thể biết mã bạn sử dụng.

Về cơ bản, tôi không nghĩ rằng chúng có nghĩa là chính BillingService, nhưng cách bạn sử dụng nó trong ứng dụng của mình.

Answer 3

Không có tin tốt ở đây: Bạn cần phải thay đổi bất cứ điều gì bạn có thể, ngoài việc sử dụng Proguard. Điều này bao gồm việc sáp nhập các lớp học, tách họ, di chuyển phương pháp nhất định từ một mô-đun khác, và đặc biệt là mã hóa thông tin mua hàng được lưu trữ vào cơ sở dữ liệu, như mô tả cho lớp PurchaseDatabase gợi ý:

Bạn nên sử dụng một obfuscator trước khi lưu trữ mọi thông tin đến bộ nhớ liên tục. Bộ obfuscator nên sử dụng khóa cụ thể là cho thiết bị và/hoặc người dùng. Nếu không, kẻ tấn công có thể sao chép cơ sở dữ liệu đầy đủ các giao dịch mua hợp lệ và phân phối nó cho người khác.

Lý do là với các công cụ như AntiLVL, rất dễ so sánh mã bị biên dịch (bị xáo trộn!) Với mẫu ban đầu và khấu trừ từ bất kỳ thứ gì cần thiết để thỏa hiệp. Nó là không thể ngăn chặn hoàn toàn nứt, nhưng bạn nên cố gắng làm cho nó khó khăn nhất có thể.