2012-11-10 37 views
22

Gần đây tôi đã khám phá ra cách thức hữu ích và dễ dàng parse.com là. Nó thực sự tăng tốc độ phát triển và cung cấp cho bạn một cơ sở dữ liệu sẵn có để lưu trữ tất cả dữ liệu đến từ ứng dụng web/di động của bạn.an ninh parse.com

Nhưng mức độ an toàn như thế nào? Từ những gì tôi hiểu, bạn phải nhúng khóa riêng tư của ứng dụng vào mã, do đó cấp quyền truy cập vào dữ liệu.

Nhưng nếu ai đó có thể khôi phục khóa từ ứng dụng của bạn thì sao? Tôi đã thử nó. Tôi mất 5 phút để tìm khóa riêng tư từ một APK chuẩn và cũng có khả năng xây dựng một ứng dụng web với khóa riêng được mã hóa cứng trong số javascript source của bạn, nơi hầu như mọi người đều có thể nhìn thấy nó.

Cách duy nhất để bảo mật dữ liệu tôi đã tìm thấy là ACL (https://www.parse.com/docs/data), nhưng điều này vẫn có nghĩa là bất kỳ ai cũng có thể giả mạo dữ liệu có thể ghi.

Ai đó có thể khai sáng cho tôi không?

+0

Điều này cũng liên quan đến tôi. Tôi đã tìm thấy một vài liên kết (https://parse.com/questions/prohibit-user-from-changing-their-own-game-score và https://parse.com/questions/javascript-sdk-security). Tôi nghĩ rằng hệ thống ACL của Parse có thể đủ an toàn cho các nhu cầu của ứng dụng cụ thể của tôi, nhưng tôi nghĩ rằng đối với một số ứng dụng khác, tôi cần phải tìm hiểu thêm các phương pháp bảo mật để cố gắng khóa các thứ. – Ryan

Trả lời

18

Giống như với bất kỳ máy chủ phụ trợ nào khác, bạn phải bảo vệ chống lại các khách hàng tiềm ẩn độc hại. Phân tích cú pháp có nhiều cấp độ bảo mật để giúp bạn.

Bước đầu tiên là ACLs, như bạn đã nói. Bạn cũng có thể thay đổi permissions trong Trình duyệt dữ liệu để vô hiệu hóa các ứng dụng khách không được phép tạo các lớp mới hoặc thêm hàng hoặc cột vào các lớp hiện có.

Nếu mức độ bảo mật đó không thỏa mãn bạn, bạn có thể ủy quyền truy cập dữ liệu của mình thông qua Cloud Functions. Điều này giống như việc tạo một máy chủ ứng dụng ảo để cung cấp một lớp điều khiển truy cập giữa các máy khách và kho lưu trữ dữ liệu phụ trợ của bạn.

+1

Nó chắc chắn là một mô hình khác với ol 'truyền thống', đây là một khóa bí mật bạn có thể ẩn trong mã phía máy chủ của bạn cho phép bạn làm bất cứ điều gì, "mà không làm việc cho các ứng dụng JavaScript. Ý tưởng chung mà @bklimt đề cập ở đây là "Người dùng ứng dụng thân mến, bạn không thể làm gì cho đến khi bạn đăng nhập và khi bạn đăng nhập vào Parse sẽ hạn chế hoạt động của bạn dựa trên chính sách (ACL và quyền) mà chúng tôi có tài khoản của bạn." – Seth

+0

Đây là lý do tại sao tôi yêu Cloud Function! Bạn có thể lọc tất cả các yêu cầu và thực hiện nhiều hơn nữa. –

3

Tôi đã thực hiện phương pháp tiếp cận sau trong trường hợp tôi chỉ cần hiển thị một chế độ xem nhỏ dữ liệu người dùng cho ứng dụng web.

a. Tạo một đối tượng phụ chứa một tập con của các trường đối tượng an toàn.

b. Sử dụng ACL, làm cho đối tượng an toàn chỉ có thể truy cập từ thông tin đăng nhập thích hợp

c. Đặt đối tượng phụ công khai đọc

d. Viết trình kích hoạt để giữ cho đối tượng thứ cấp được đồng bộ hóa với các bản cập nhật cho chính.

Tôi cũng sử dụng nhiều chức năng đám mây nhưng kỹ thuật này rất hữu ích khi bạn cần sự linh hoạt và có thể đơn giản hơn chức năng đám mây nếu đối tượng phụ là chế độ xem qua nhiều đối tượng an toàn.

0

Điều tôi đã làm là như sau.

  1. Hạn chế đọc/ghi công khai cho tất cả các lớp. Cách duy nhất để truy cập dữ liệu lớp sẽ là thông qua mã đám mây.
  2. Xác minh rằng người dùng là người dùng đã đăng nhập bằng thông số request.user và nếu phiên người dùng là null và nếu id đối tượng là hợp pháp.
  3. Khi người dùng được xác minh thì tôi sẽ cho phép dữ liệu được truy xuất bằng khóa chính.
0

Chỉ cần kiểm soát chặt chẽ các tùy chọn Bảo mật cấp độ chung của bạn (tạo lớp ứng dụng khách, v.v ...)), Các tùy chọn Bảo mật Cấp Lớp (ví dụ, bạn có thể vô hiệu hóa các máy khách đang xóa các mục _Installation. Nó cũng phổ biến để vô hiệu hóa việc tạo trường cho tất cả các lớp.), Và quan trọng nhất là tìm ra các ACL.

Thông thường tôi sử dụng bộ kích hoạt trướcSave để đảm bảo ACL luôn chính xác. Vì vậy, ví dụ, đối tượng _User là nơi đặt email khôi phục. Chúng tôi không muốn người dùng khác có thể xem email khôi phục của nhau, vì vậy tất cả các đối tượng trong lớp _User phải có đọc và ghi được đặt cho người dùng chỉ (với công khai đọc sai và ghi công khai sai).

Bằng cách này, bản thân người dùng chỉ có thể giả mạo hàng của chính họ. Những người dùng khác thậm chí sẽ không nhận thấy hàng này tồn tại trong cơ sở dữ liệu của bạn.

Một cách để giới hạn hơn nữa trong một số trường hợp, là sử dụng các chức năng đám mây. Giả sử một người dùng có thể gửi tin nhắn cho người dùng khác. Bạn có thể thực hiện điều này như là một tin nhắn lớp học mới, với nội dung của tin nhắn, và con trỏ đến người dùng đã gửi tin nhắn và cho người dùng sẽ nhận được tin nhắn.

Vì người dùng đã gửi tin nhắn phải có khả năng hủy tin nhắn và vì người dùng nhận được tin nhắn phải có khả năng nhận tin nhắn, cả hai đều cần đọc được hàng này (vì vậy ACL phải có quyền đọc cho cả hai người). Tuy nhiên, chúng tôi không muốn một trong số họ giả mạo nội dung của tin nhắn. Vì vậy, bạn có hai lựa chọn thay thế: hoặc bạn tạo trình kích hoạt beforeSave kiểm tra xem các sửa đổi mà người dùng đang cố thực hiện cho hàng này có hợp lệ hay không trước khi cam kết hoặc bạn đặt ACL của thư để không ai có quyền ghi và bạn tạo các chức năng đám mây để xác thực người dùng và sau đó sửa đổi thông báo bằng cách sử dụng phím chính.

Điểm là, bạn phải thực hiện những cân nhắc này cho mọi phần trong ứng dụng của mình. Theo như tôi biết, không có cách nào xung quanh việc này.

Các vấn đề liên quan