2012-01-21 35 views
16

Tôi đã tạo một ứng dụng web bằng cách sử dụng Java EE 6 (sử dụng các triển khai tham chiếu) và tôi muốn hiển thị nó dưới dạng dịch vụ web REST.Cách bảo mật dịch vụ web REST trong Java EE 6

Nền là tôi muốn có thể truy xuất dữ liệu từ ứng dụng web đến ứng dụng iOS mà tôi đã tạo. Câu hỏi đặt ra là làm cách nào để tôi bảo mật ứng dụng? Tôi chỉ muốn ứng dụng của tôi sử dụng dịch vụ web. Điều đó có khả thi không và tôi sẽ làm như thế nào? Tôi chỉ cần biết những gì tôi nên tìm kiếm và đọc và không phải là mã thực tế.

+10

tại sao trên Trái đất bất cứ ai sẽ bỏ phiếu để đóng này? –

+2

Chăm sóc để giải thích downvoter? – LuckyLuke

Trả lời

8

Thật không may, webservice của bạn sẽ không bao giờ hoàn toàn an toàn nhưng đây là một vài trong số những điều cơ bản bạn có thể làm:

  • Sử dụng SSL
  • Bọc tất cả của bạn (ứng dụng) trọng tải outbound trong POST yêu cầu. Điều này sẽ ngăn chặn việc tìm kiếm thông thường để tìm ra cách hoạt động của các dịch vụ web của bạn (để đảo ngược giao thức).
  • Bằng cách nào đó xác thực người dùng ứng dụng của bạn. Lý tưởng nhất điều này sẽ liên quan đến OAUTH ví dụ bằng cách sử dụng thông tin đăng nhập của Google, nhưng bạn sẽ có được ý tưởng.

Bây giờ tôi sẽ chỉ ra lý do tại sao này sẽ không hoàn toàn an toàn:

  • Nếu ai đó có được một tổ chức của ứng dụng của bạn và đảo ngược kỹ sư nó, tất cả mọi thứ bạn chỉ cần làm ra ngoài cửa sổ. Điều duy nhất sẽ giữ là xác thực người dùng của bạn.
  • Nhúng chứng chỉ ứng dụng khách (như những người khác đã chỉ ra) không có gì để giúp bạn trong trường hợp này. Nếu tôi vừa đảo ngược ứng dụng của bạn, tôi cũng có chứng chỉ ứng dụng khách của bạn.

Điều gì có thể bạn làm gì?

  • Xác thực tài khoản trên chương trình phụ trợ của bạn và theo dõi chúng để sử dụng bất thường.

Tất nhiên điều này tất cả đi ra ngoài cửa sổ khi ai đó đến, đảo ngược kỹ sư ứng dụng của bạn, xây dựng ứng dụng khác để bắt chước ứng dụng và bạn sẽ không (thường) biết rõ hơn. Đây là tất cả những điểm cần ghi nhớ.

Edit: Ngoài ra, nếu đó là chưa rõ ràng, sử dụng POST (hoặc GET) yêu cầu cho tất cả truy vấn ứng dụng (máy chủ của bạn). Điều này, kết hợp với SSL nên ngăn chặn những kẻ lừa đảo bình thường của bạn.

Edit2: Có vẻ như nếu tôi sai lại: POSThơn an toàn hơn GET. This câu trả lời là khá hữu ích trong việc chỉ ra rằng. Vì vậy, tôi cho rằng bạn có thể sử dụng GET hoặc POST thay thế cho nhau ở đây.

+0

Tôi thấy, tôi không cần phải làm cho nó an toàn như một ngân hàng :) Tôi chỉ muốn ít nhất là giới hạn hoặc ngăn chặn cách đáng sợ nhất mà mọi người có thể sử dụng API. – LuckyLuke

+0

@Pjotr ​​Sau đó, có, SSL và gói tất cả các tải trọng của bạn trong yêu cầu 'POST' nên làm những gì bạn cần. Tôi chỉ muốn chỉ ra nơi nó đi sai. –

+0

POST bằng bất kỳ cách nào an toàn hơn GET? –

4

Phụ thuộc vào mức độ an toàn bạn muốn thực hiện.

  • Nếu bạn không thực sự quan tâm, chỉ cần nhúng một từ bí mật vào ứng dụng của bạn và bao gồm tất cả các yêu cầu.
  • Nếu bạn quan tâm nhiều hơn một chút, hãy làm như vậy và chỉ tiếp xúc với dịch vụ qua https.
  • Nếu bạn muốn bảo mật, hãy cấp chứng chỉ ứng dụng khách cho ứng dụng của bạn và yêu cầu phải có chứng chỉ ứng dụng khách hợp lệ khi dịch vụ được truy cập.
+0

Tôi chỉ cần một số bảo mật cơ bản :) Vì vậy, những gì bạn nói là tôi chỉ có thể gửi một tham số như thế này: "MyMagicKey": "MagicNumber030349" từ ứng dụng iOS và kiểm tra xem nó có khớp với ứng dụng web của tôi không? – LuckyLuke

+0

Có. Nhưng điều này chỉ cung cấp mức độ bảo mật rất cơ bản, tất nhiên, vì nó là tầm thường để thu thập các yêu cầu này. Nếu bạn sử dụng https nó sẽ khó khăn hơn nhiều (nhưng vẫn còn rất nhiều khả năng, chỉ yêu cầu các kỹ năng trung bình trên) để tìm ra. –

0

Tạo quy tắc trên máy lưu trữ Dịch vụ web của bạn để chỉ cho phép ứng dụng truy cập thông qua một số cổng. Trong Amazon EC2, điều này được thực hiện khi tạo một quy tắc trong nhóm bảo mật cá thể.

1

gợi ý của tôi là:

  1. sử dụng https thay vì http. có chứng chỉ ssl miễn phí có sẵn, lấy một và cài đặt.
  2. sử dụng đường dẫn phức tạp như 4324234AA_fdfsaf/làm điểm cuối gốc.

do bản chất của giao thức http, phần đường dẫn là được mã hóa trong yêu cầu https. do đó nó rất an toàn. có nhiều cách để giải mã yêu cầu thông qua tấn công man-in-the-middle nhưng nó đòi hỏi toàn quyền kiểm soát thiết bị khách bao gồm cài đặt chứng chỉ ssl. nhưng, tôi dành nhiều thời gian hơn cho ứng dụng của mình để làm cho nó thành công.

+0

trong toàn bộ yêu cầu https được mã hóa, không chỉ url. –

+1

không, tên máy chủ và/hoặc địa chỉ ip không. – wangii

+0

um ... rõ ràng là có, địa chỉ bạn kết nối không được mã hóa. –

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