Làm cách nào để tránh sử dụng trái phép API?

Tôi phải thiết kế một "widget", một tập lệnh mà các đối tác sẽ nhúng vào trang web của họ để hiển thị một số UI và thực hiện các cuộc gọi tới API của chúng tôi.

Về cơ bản, nó sẽ hiển thị dữ liệu của chúng tôi trên các trang web này dựa trên một số ID mà chúng cung cấp trong các lệnh gọi API của chúng tôi. Điều chúng tôi muốn tránh là ai đó lạm dụng API và sử dụng nó để cạo toàn bộ danh mục của chúng tôi.

Mỗi đối tác nhúng tập lệnh của chúng tôi sẽ được cung cấp một khóa công khai phải được cung cấp khi gọi API. Một ý tưởng sẽ là yêu cầu họ nối thêm khóa này khi tải tập lệnh, ví dụ:

<script src="//initrode.com/widget/loader.js?key=xxxx"></script>

Bằng cách đó, yêu cầu cho tập lệnh có thể được sử dụng để đăng ký cặp IP khóa / nguồn và chỉ trả lời các cuộc gọi API tiếp theo nếu cặp khóa / IP khớp với một cặp đã đăng ký (với thời gian giới hạn và giới hạn yêu cầu mỗi ngày).

Tôi không chắc đó là một ý tưởng hay vì rõ ràng nó bảo mật thông qua obfuscation (ai đó tải lại tập lệnh sẽ hoàn toàn bỏ qua nó); nhưng tôi không thấy cách nào khác để hạn chế quyền truy cập. Tôi không thể cung cấp một khóa duy nhất cho mọi người dùng, chỉ cho các đối tác. Tôi không thể sử dụng hệ thống khóa riêng vì tất cả mã sẽ có sẵn cho bất kỳ ai. Về cơ bản, nó hạn chế quyền truy cập vào API công khai, nghĩa là mâu thuẫn trong định nghĩa của nó.

Bạn nghĩ gì về giải pháp này, và bạn sẽ làm gì với những hạn chế này?

Bạn cần một số loại bảo vệ.

Trước tiên , bạn cần ngăn khóa của Trang A không được sử dụng trên Trang B.

Về lý thuyết, nếu khóa được liên kết với một miền, bạn không thể phụ thuộc vào referertiêu đề, nhưng vì khách hàng của bạn đang nhúng tập lệnh trực tiếp, nên bạn có thể dựa một cách hợp lý document.locationvào phía máy khách. Gửi trực tiếp vị trí đó (hoặc một phần của nó) đến máy chủ là không đáng tin cậy; nhưng bạn có thể sử dụng nó để tạo khóa phiên:

1. Máy khách nhúng client_keyvào yêu cầu cho thư viện API.
2. Máy chủ xác định máy chủ có quyền truy cập API, nếu có.
3. Máy chủ chọn "muối" cho khóa phiên và gửi nó đến máy khách với thư viện [hoặc là một phần của một trao đổi tiền xác thực khác].
4. Khách hàng tính toán session_keysử dụng hash(document.location.host + session_salt).
5. Khách hàng sử dụng session_key+ client_keycho một cuộc gọi API.
6. Máy chủ xác nhận cuộc gọi bằng cách tra cứu client_keymáy chủ và "muối" trong phiên, tính toán hàm băm và so sánh với lệnh được cung cấp client_key.

Thứ hai , bạn cần cản trở Hacker Hank mở bảng điều khiển gỡ lỗi hoặc sử dụng ứng dụng khách được sửa đổi trên Trang web A để làm bất cứ điều gì anh ta muốn với API của bạn.

Tuy nhiên, xin lưu ý rằng điều đó rất khó, nếu không nói là không thể ngăn chặn hoàn toàn Hacker Hank lạm dụng API. Nhưng, bạn có thể làm cho nó khó khăn hơn. Và cách hợp lý nhất để cản trở Hank, mà tôi biết, là giới hạn tỷ lệ.

• Giới hạn số lượng yêu cầu / giây / phiên và yêu cầu / giờ / phiên. (Tăng đột biến trong hoạt động có thể là hợp lý, nhưng không duy trì lưu lượng trên mức trung bình từ một khách hàng.)
• Giới hạn số phiên / IP / giờ.
• Giới hạn số lượng yêu cầu / IP / giờ. Cho phép tăng đột biến, nhưng không duy trì lưu lượng lớn từ một IP duy nhất.

Thứ ba , như bạn có thể đã làm: mã hóa lưu lượng. Chắc chắn, NSA sẽ thấy nó; nhưng Hacker Hank ít có khả năng hơn.

Âm thanh như bạn đang làm ở đây làm cho các tệp javascript của bạn thành tài nguyên được bảo vệ. Và kết hợp nó với một loại tạo mã thông báo cùng một lúc. Nó thật thú vị.

Những kẻ bảo mật mà tôi làm việc thường loại bỏ địa chỉ IP ra khỏi tay vì IP là giả mạo. Nhưng nếu bạn đang sử dụng hạn chế IP kết hợp với SSL, thì đó thường là mẹo.

Nhưng bạn phải "đưa danh sách trắng" các địa chỉ IP, nếu không, bất kỳ hacker nào cũng có thể đến trước cửa.

Tôi đã hoài nghi, nhưng tôi thực sự nghĩ rằng chương trình của bạn hoạt động khá tốt. Nếu 1) tệp .js và các lệnh gọi API tiếp theo được thực hiện bằng TLS (tức là SSL hoặc https) và 2) thì IP sẽ được đưa vào danh sách trắng. Sau đó, tôi sẽ đưa ra tuyên bố táo bạo và nói rằng tôi nghĩ rằng bạn sẽ vượt qua đánh giá bảo mật, ngay cả đối với các tương tác PCI (thẻ tín dụng).

IMHO ... Nhưng nếu bạn chỉ cố gắng bảo vệ thông tin độc quyền của công ty thay vì thẻ tín dụng (PCI) hoặc thông tin cá nhân / riêng tư (PII), thì điều này có thể tốt ngay cả khi không có SSL, tùy thuộc vào mức độ bạn sẵn sàng mạo hiểm để lộ danh mục của bạn.

Hoặc đặt nó theo cách này: Với SSL, một hacker chuyên dụng không thể có được danh mục của bạn. (Trừ khi họ phá vỡ SSL, nhưng sau đó họ cũng có thể phá vỡ Amazon). Không có SSL, một hacker chuyên dụng có thể đánh hơi các cuộc gọi của bạn, giả mạo IP và kéo danh mục của bạn xuống. Vì vậy, đó là một loại phán quyết về rủi ro.

Tôi đang cố gắng nghĩ cách để phân phối với danh sách trắng IP bởi vì đó thường là một nỗi đau để quản lý;) mà không đi đến OAuth toàn diện. Tôi sẽ ăn mì về điều đó.