Cách bảo vệ phần 'công khai' của dịch vụ REST khỏi spam?

Question

Tôi có dịch vụ REST hoàn toàn hợp lý và sẽ được sử dụng với ứng dụng iOS. Nó được xây dựng bằng Ruby/Sinatra nhưng tôi không nghĩ điều đó thực sự quan trọng ở đây.

Tôi đang sử dụng Xác thực cơ bản HTTP qua SSL cho các điểm cuối khác nhau và phần đó đang hoạt động rất tốt.

Câu hỏi là: Làm cách nào để ngăn những người gửi spam ... gọi các phần của dịch vụ REST không được bảo vệ qua Xác thực cơ bản HTTP?

Ví dụ: User Registration

Giả sử các cuộc gọi REST là (POST).../register_account đi qua một đối tượng JSON trong cơ thể.

Vì lý do hiển nhiên, cuộc gọi này không thể mong đợi tên người dùng/mật khẩu được liên kết với tài khoản người dùng.

Ý tưởng là:

1) Ứng dụng có nó 'username' riêng/mật khẩu và một số cuộc gọi sẽ kiểm tra các ứng dụng thông tin. Sự cố: Khởi động thiết bị, v.v. có thể khai quật những thông tin đăng nhập đó.

2) Ứng dụng chuyển mã thông báo bí mật qua tiêu đề HTTP tới Dịch vụ REST cho các cuộc gọi đó. Sự cố: Tương tự như (1)

Có bất kỳ kỹ thuật nào thường được sử dụng để ngăn chặn các cuộc gọi spam đó không? Tôi đang nghĩ có thể giới thiệu id thiết bị của iPhone trong hỗn hợp nhưng chưa xác định được một cách tiếp cận xác định nào.

Cảm ơn

Answer 1

Trong khi mã dành riêng cho ứng dụng là ý tưởng hay cho hàng phòng thủ đầu tiên chống lại spam, bạn vẫn nên triển khai một số giới hạn tốc độ đối với bất kỳ dịch vụ nào mà bạn quan tâm.

Ví dụ: nếu bạn sử dụng các phiên trên dịch vụ REST của mình, bạn có thể dễ dàng định mức giới hạn số lượng cuộc gọi mà bạn xử lý từ một phiên duy nhất. Phiên không nhất thiết phải được xác thực và chỉ được sử dụng để xác định một khách hàng duy nhất trong khi họ đang thực hiện các yêu cầu. Chuyển hướng đơn giản trở lại dịch vụ được yêu cầu nếu họ cố gắng kết nối mà không cần phiên mở là tất cả những gì cần thiết và hầu như tất cả các khung công tác web hoặc ngăn xếp đều được tích hợp sẵn.

Bạn cũng có thể xếp hạng giới hạn cho các thuộc tính khác, chẳng hạn như IP hoặc dấu vân tay của tác nhân người dùng, nhưng chúng ít đáng tin cậy hơn so với phương pháp dựa trên phiên.

Answer 2

Bạn thể địa chỉ theo dõi ip sử dụng request.ip và viết một số logic xung quanh đó.

Answer 3

Nói chung, cách tiếp cận chung là Khóa API, giống như mã bí mật bạn mô tả ở trên. Bạn có thể hardcode này vào ứng dụng của bạn và làm cho nó khó khăn cho một người nào đó để đảo ngược nó (ẩn nó, xây dựng nó từ các phần khác nhau được lưu trữ ở những nơi khác nhau trong ứng dụng của bạn, vv). Bạn chính xác trong đó kẻ tấn công xác định sẽ có thể khôi phục khóa (nếu ứng dụng của bạn có thể làm như vậy, người khác có quyền truy cập vào ứng dụng của bạn có thể) ... nhưng bạn có thể làm cho nó khó khăn hơn ở đâu, hy vọng, nó sẽ không không xứng đáng với thời gian và công sức để làm như vậy.

Bạn cũng có thể xem triển khai SSL được xác thực lẫn nhau, để máy chủ của bạn sẽ chỉ chấp nhận các kết nối đến từ ứng dụng của bạn và ứng dụng của bạn sẽ chỉ liên lạc với máy chủ của bạn.

Đây là cách tiếp cận cấp cao. Tạo chứng chỉ SSL máy chủ tự ký và triển khai trên máy chủ web của bạn. Sau đó, tạo một ứng dụng khách tự ký và triển khai ứng dụng đó trong ứng dụng của bạn dưới dạng tài nguyên. Cấu hình máy chủ để yêu cầu xác thực SSL phía máy khách và chỉ chấp nhận chứng chỉ ứng dụng khách mà bạn đã tạo. Định cấu hình ứng dụng khách để sử dụng chứng chỉ phía máy khách đó để xác định chính nó và chỉ chấp nhận chứng chỉ phía máy chủ mà bạn đã cài đặt trên máy chủ của mình cho phần đó.

Nếu ai đó/ứng dụng khác cố gắng kết nối với máy chủ của bạn, kết nối SSL sẽ không được tạo vì máy chủ sẽ từ chối kết nối SSL đến không xuất trình chứng chỉ ứng dụng khách mà bạn đã đưa vào ứng dụng của mình.