Lưu trữ an toàn dữ liệu bí mật trong ứng dụng web phía máy khách


11

Tôi có ứng dụng web này sẽ là tất cả công nghệ phía máy khách (HTML, CSS, JavaScript / AngularJS, v.v ...). Ứng dụng web này sẽ tương tác với API REST để truy cập và sửa đổi dữ liệu. Ngay bây giờ vẫn chưa quyết định loại hệ thống xác thực mà API REST sẽ sử dụng.

Theo hiểu biết của tôi, bất kỳ loại hệ thống xác thực API nào (Khóa API, OAuth 1/2, v.v ...) sẽ có một số dữ liệu nhất định cần được giữ bí mật nếu không quyền truy cập có thể bị xâm phạm. Đối với Khóa API, bản thân các khóa cần phải được giữ bí mật, đối với OAuth 2, mã thông báo khách hàng / mã thông báo truy cập / mã thông báo làm mới cần được giữ bí mật, tôi chắc chắn một vài trong số 4 khóa liên quan đến OAuth 1 cần được giữ bí mật (không phải quá nhiều kinh nghiệm với OAuth 1). Tôi đã cố gắng suy nghĩ liệu có cách nào để lưu trữ nội dung bí mật này trong một ứng dụng web phía máy khách thuần túy mà không có lớp giữa của các loại máy chủ.

Tôi đã cố gắng nghĩ về điều này và tôi không thể nghĩ ra nơi nào để làm điều đó. Ý tôi là tôi không thể lưu trữ nó trong javascript vì bất kỳ ai cũng có thể xem nguồn hoặc mở giao diện điều khiển và lấy dữ liệu. Tôi không chắc chắn 100% mức độ an toàn của localStorage và liệu người dùng có thể truy cập / sửa đổi dữ liệu đó hay không. Ngay cả khi lưu trữ cục bộ là an toàn, hai cách tôi có thể nghĩ về việc lấy dữ liệu vào đó là không. Một cách là chỉ lưu trữ dữ liệu trong mã nguồn javascript, đó là điều không an toàn nhất mà tôi có thể nghĩ đến. Bây giờ nếu tôi đang sử dụng một cái gì đó như OAuth 2 trong đó chính api còn lại sẽ cung cấp cho tôi mã thông báo, thì nó vẫn không an toàn (tốt hơn tùy chọn đầu tiên) bởi vì những mã thông báo đó sẽ được trả lại dưới dạng văn bản thuần túy mà bất kỳ ai cũng có thể nhìn thấy yêu cầu máy tính đang thực hiện có thể nhìn thấy.

Có cách nào để ứng dụng chạy hoàn toàn phía máy khách có thể lưu trữ các mẩu dữ liệu bí mật một cách an toàn mà không cần một lớp giữa nào đó ở phía máy chủ không?



Localst Storage dành riêng cho trình duyệt, nhưng lấy Opera trên Windows làm ví dụ, nó chỉ là một số tệp đĩa trong thư mục hồ sơ của người dùng, vì vậy về cơ bản nó không được bảo vệ.
Ross Patterson

Một cách sẽ là giữ bí mật trên máy chủ trong một db và chỉ có application_id trên máy khách. Sau đó thực hiện truy vấn oauth từ máy chủ, vì vậy đây là một số cách tiếp cận proxy.
Simon Polak

Câu trả lời:


9

Không, nó không bao giờ có thể hoàn toàn an toàn. Người dùng kiểm soát phần cứng và bạn đang cố gắng để thứ gì đó nằm ngoài tầm tay của họ. Cuối cùng, họ CÓ THỂ có được nó thông qua cách này hay cách khác. Vì bạn đang làm việc từ javascript, vị trí của bạn RẤT NHIỀU so với một ứng dụng máy tính thông thường, vì người dùng không chỉ kiểm soát phần cứng, họ còn kiểm soát hộp cát mà bạn đang chạy.

Bạn có thể giấu mọi thứ, và làm cho nó trở nên khó khăn để thu dọn, nhưng cuối cùng họ CÓ THỂ lấy nó ra, nếu họ cố gắng hết sức.


4
^ này Làm thế nào "bí mật" là dữ liệu bí mật, và bao nhiêu thời gian và tiền bạc bảo vệ nó thực sự có giá trị? Những nỗ lực "tiêu chuẩn công nghiệp" có thể là đủ.
DaveE

+1 Câu trả lời xuất sắc. Với trình gỡ lỗi JavaScript, tôi có thể thay đổi ứng dụng của bạn, xem các giá trị trung gian, v.v ... Nếu tôi muốn thông tin, tôi sẽ lấy nó.
Ross Patterson

2

Khi thiết kế hệ thống bảo mật, người ta luôn cần nghĩ về mô hình mối đe dọa. " Làm cho nó an toàn " là một yêu cầu ngớ ngẩn, không thể hành động hoặc kiểm chứng được. " Ngăn người dùng trích xuất mã thông báo truy cập từ ứng dụng " tốt hơn nhiều và xác định ranh giới của giải pháp. " Ngăn người khác lấy mã thông báo truy cập của người dùng " cũng tốt hơn và xác định không gian giải pháp hoàn toàn khác. Các giải pháp cho một người sẽ không nhất thiết phải giải quyết vấn đề khác ( ví dụ: giải pháp sau hoàn toàn yêu cầu SSL nếu WiFi có liên quan, nhưng điều đó sẽ không ảnh hưởng đến cái trước).


0

một tùy chọn là API REST cấp quyền truy cập hoặc không dựa trên thông tin đăng nhập của người dùng; nó có thể trả về mã thông báo dựa trên phiên (hướng dẫn, chuỗi băm, bất cứ điều gì bạn thích) có thể được chuyển đến các lệnh gọi API REST khác để xác thực quyền truy cập

nếu bạn lo lắng về việc lưu trữ thông tin đăng nhập của người dùng trên máy khách thì không, nhưng người dùng sẽ phải nhập thông tin tài khoản và mật khẩu mỗi lần

không quen thuộc với OAuth et al, nhưng tôi thấy không có lý do thuyết phục nào ở trên để lưu trữ thông tin xác thực liên tục cả ...


Về lý do, luôn có "sự thoải mái" rõ ràng là mối quan hệ của "an ninh" và "an toàn".
henon
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.