Khóa API dịch vụ Web và Ajax - Bảo vệ khóa

Question

Đây có thể là câu hỏi bảo mật chung, nhưng tôi nghĩ tôi muốn hỏi trong lĩnh vực những gì tôi đang phát triển.

Kịch bản là: Dịch vụ web (WCF Web Api) sử dụng Khóa API để xác thực và cho tôi biết người dùng là ai, và kết hợp jQuery và ứng dụng trên giao diện người dùng.

Mặt khác, lưu lượng truy cập có thể là https nên không thể kiểm tra, nhưng nếu tôi sử dụng cùng một khóa cho mỗi người dùng (nói một guid) và tôi đang sử dụng nó ở cả hai thì có thể lấy được và ai đó có thể mạo danh người dùng.

Nếu tôi thực hiện điều gì đó tương tự như OAuth, thì người dùng và khóa ứng dụng được tạo và điều đó có thể hoạt động - nhưng vẫn cho phía jQuery, tôi sẽ cần khóa API ứng dụng trong javascript.

Điều này sẽ chỉ là vấn đề nếu ai đó ở trên máy tính thực tế và đã có chế độ xem.

Tôi nên làm gì?

1. md5 hoặc mã hóa khóa bằng cách nào đó?
2. Đặt khóa trong biến phiên, sau đó khi sử dụng ajax, hãy truy xuất nó?
3. Vượt qua nó, nó không phải là một vấn đề lớn.

Tôi chắc chắn đây có thể là vấn đề phổ biến - vì vậy mọi con trỏ sẽ được chào đón.

Để làm cho điều này rõ ràng hơn - đây là API của tôi mà tôi đã viết rằng tôi đang truy vấn, chứ không phải google, v.v. Vì vậy, tôi có thể thực hiện theo mã thông báo phiên, v.v. cách để bảo mật mã thông báo/khóa phụ của khách hàng mà tôi sẽ sử dụng.

Tôi hơi quá thận trọng ở đây, nhưng chỉ cần sử dụng tính năng này để tìm hiểu.

Answer 1

thấy http://blogs.msdn.com/b/rjacobs/archive/2010/06/14/how-to-do-api-key-verification-for-rest-services-in-net-4.aspx để biết thêm thông tin (Làm thế nào để làm API chính xác cho Văn Dịch vụ trong .NET 4)

Answer 2

Nói chung trong những trường hợp như thế này mặc dù bạn ủy quyền yêu cầu thông qua các máy chủ sử dụng 'AJAX' mà xác minh làm trình duyệt yêu cầu được phép làm như vậy. Nếu bạn muốn gọi dịch vụ trực tiếp từ JavaScript, thì bạn cần một số loại hệ thống mã thông báo như JSON Web Tokens (JWT) và bạn sẽ phải tìm ra các vấn đề về tên miền chéo nếu dịch vụ được đặt ở một nơi nào đó ngoài miền hiện tại.

Answer 3

Cách sử dụng jQuery để gọi mã phía máy chủ xử lý giao tiếp với API. Nếu bạn đang sử dụng MVC, bạn có thể gọi một hành động điều khiển có thể chứa mã và khóa API để truy cập dịch vụ của bạn và trả lại một phần xem (hoặc thậm chí JSON) cho UX của bạn. Nếu bạn đang sử dụng biểu mẫu web, bạn có thể tạo trang aspx sẽ thực hiện giao tiếp API trong mã phía sau và sau đó viết nội dung vào luồng phản hồi để UX của bạn sử dụng. Sau đó, mã UX của bạn chỉ có thể chứa một số lệnh $ .post() hoặc $ .load() tới mã phía máy chủ của bạn và cả khóa API và điểm cuối của bạn sẽ được bảo vệ.

Answer 4

Phụ thuộc vào cách sử dụng khóa API. Các khóa API như được cung cấp bởi Google được gắn với URL của trang web có nguồn gốc yêu cầu; nếu bạn thử và sử dụng khóa trên một trang web có URL thay thế thì dịch vụ sẽ bị ném và lỗi, do đó loại bỏ sự cần thiết phải bảo vệ khóa ở phía máy khách.

Tuy nhiên, một số API cơ bản được liên kết với khách hàng và có thể được sử dụng trên nhiều miền, vì vậy trong trường hợp này, trước đây tôi đã thực hành gói API này trong mã phía máy chủ và đặt một số hạn chế về cách khách hàng có thể giao tiếp với dịch vụ địa phương và bảo vệ dịch vụ. Tuy nhiên, khuyến nghị chung của tôi là áp dụng các hạn chế đối với API Web xung quanh cách sử dụng các khóa và do đó loại bỏ các biến chứng và sự cần thiết của việc cố gắng bảo vệ chúng trên máy khách.

Answer 5

(Tôi đề nghị gắn thẻ bài đăng này là "bảo mật".)

Trước tiên, bạn nên rõ ràng về những gì bạn đang bảo vệ chống lại. Bạn có thể tin tưởng khách hàng chút nào không? Một người dùng xảo quyệt có thể dính vào tập lệnh Greasemonkey trên trang của bạn và gọi chính xác mã mà giao diện người dùng của bạn gọi để gửi yêu cầu. Ẩn tất cả mọi thứ trong một đóng cửa Javascript chỉ có nghĩa là bạn cần một trình gỡ lỗi; nó không làm cho một cuộc tấn công không thể. Firebug có thể theo dõi các yêu cầu HTTPS. Cũng xem xét một khách hàng bị xâm nhập: có một keylogger được cài đặt không? Có phải toàn bộ hệ thống đã bí mật chạy ảo hóa sao cho kẻ tấn công có thể kiểm tra bất kỳ phần nào của bộ nhớ bất cứ lúc nào khi họ rảnh rỗi? An ninh khi bạn được tiếp xúc như một webapp là thực sự khó khăn.

Tuy nhiên, dưới đây là một vài điều để bạn có thể xem xét:

1. xem xét không thực sự sử dụng các phím mà là HMAC băm của, ví dụ, một dấu hiệu cho bạn ngay khi xác thực.

2. Bộ nhớ DOM có thể hơi khó khăn hơn để thu thập dữ liệu hơn cookie.

3. Hãy xem Google's implementation of OAuth 2 để biết mô hình bảo mật mẫu. Về cơ bản, bạn sử dụng mã thông báo chỉ hợp lệ trong một thời gian giới hạn (và có thể cho một địa chỉ IP duy nhất). Bằng cách đó, ngay cả khi mã thông báo bị chặn hoặc nhân bản, nó chỉ hợp lệ trong một khoảng thời gian ngắn. Tất nhiên bạn cần phải cẩn thận về những gì bạn làm khi mã thông báo hết; kẻ tấn công có thể làm điều tương tự với mã của bạn và nhận mã thông báo hợp lệ mới không?

Đừng bỏ bê an ninh server-side: ngay cả khi khách hàng của bạn nên đã kiểm tra trước khi trình các yêu cầu, kiểm tra lại trên máy chủ nếu người dùng thực sự có quyền làm những gì họ đang yêu cầu. Trong thực tế, lời khuyên này có thể làm giảm hầu hết những điều trên.