Bảo mật các lược đồ xác thực REST

Lý lịch:

Tôi đang thiết kế sơ đồ xác thực cho dịch vụ web REST. Điều này không "thực sự" cần phải được bảo mật (đó là một dự án cá nhân) nhưng tôi muốn làm cho nó an toàn nhất có thể như một trải nghiệm tập thể dục / học tập. Tôi không muốn sử dụng SSL vì tôi không muốn rắc rối và chủ yếu là chi phí thiết lập nó.

Những câu hỏi SO này đặc biệt hữu ích để giúp tôi bắt đầu:

• Xác thực RESTful
• Thực tiễn tốt nhất để bảo mật API REST / dịch vụ web
• Ví dụ về API web SOAP / REST / RPC tốt nhất? Và tại sao bạn thích chúng? Và có chuyện gì với họ vậy?

Tôi đang nghĩ đến việc sử dụng phiên bản xác thực đơn giản của Amazon S3 (tôi thích OAuth nhưng có vẻ quá phức tạp đối với nhu cầu của tôi). Tôi đang thêm một nonce được tạo ngẫu nhiên , được cung cấp bởi máy chủ, vào yêu cầu, để ngăn chặn các cuộc tấn công phát lại.

Để có được câu hỏi:

Cả S3 và OAuth đều dựa vào việc ký URL yêu cầu cùng với một vài tiêu đề được chọn. Không ai trong số họ ký tên cơ quan yêu cầu cho các yêu cầu POST hoặc PUT. Đây không phải là dễ bị tấn công giữa chừng, mà giữ url và tiêu đề và thay thế cơ thể yêu cầu với bất kỳ dữ liệu nào kẻ tấn công muốn?

Có vẻ như tôi có thể bảo vệ chống lại điều này bằng cách đưa vào hàm băm của thân yêu cầu trong chuỗi được ký. Điều này có an toàn không?

Một câu trả lời trước đây chỉ đề cập đến SSL trong bối cảnh truyền dữ liệu và không thực sự bao gồm xác thực.

Bạn thực sự đang hỏi về việc xác thực an toàn các ứng dụng khách API REST. Trừ khi bạn đang sử dụng xác thực khách hàng TLS, SSL mình KHÔNG phải là một cơ chế xác thực khả thi cho một REST API. SSL không có máy khách authc chỉ xác thực máy chủ , điều này không liên quan đến hầu hết các API REST vì bạn thực sự muốn xác thực ứng dụng khách .

Nếu bạn không sử dụng xác thực ứng dụng khách TLS, bạn sẽ cần sử dụng một cái gì đó như sơ đồ xác thực dựa trên tiêu hóa (như lược đồ tùy chỉnh của Dịch vụ web của Amazon) hoặc xác thực OAuth 1.0a hoặc thậm chí HTTP (chỉ qua SSL).

Những kế hoạch này xác thực rằng yêu cầu đã được gửi bởi ai đó dự kiến. TLS (SSL) (không có xác thực ứng dụng khách) đảm bảo rằng dữ liệu được gửi qua dây vẫn không bị giả mạo. Chúng là riêng biệt - nhưng bổ sung - mối quan tâm.

Đối với những người quan tâm, tôi đã mở rộng câu hỏi SO về Lược đồ xác thực HTTP và cách chúng hoạt động .

REST có nghĩa là làm việc với các tiêu chuẩn của web và tiêu chuẩn để chuyển "an toàn" trên web là SSL. Bất cứ điều gì khác sẽ trở nên thú vị và đòi hỏi nỗ lực triển khai thêm cho khách hàng, sẽ phải có sẵn các thư viện mã hóa.

Khi bạn cam kết với SSL, về nguyên tắc thực sự không có gì cần thiết để xác thực. Bạn có thể một lần nữa đi với các tiêu chuẩn web và sử dụng HTTP Basic auth (tên người dùng và mã thông báo bí mật được gửi cùng với mỗi yêu cầu) vì nó đơn giản hơn nhiều so với giao thức ký phức tạp và vẫn hiệu quả trong bối cảnh kết nối an toàn. Bạn chỉ cần chắc chắn rằng mật khẩu không bao giờ đi qua văn bản đơn giản; vì vậy nếu mật khẩu được nhận qua kết nối văn bản đơn giản, bạn thậm chí có thể vô hiệu hóa mật khẩu và gửi thư cho nhà phát triển. Bạn cũng nên đảm bảo thông tin đăng nhập không được ghi lại ở bất cứ đâu khi nhận, giống như bạn sẽ không đăng nhập mật khẩu thông thường.

HTTP Digest là một cách tiếp cận an toàn hơn vì nó ngăn chặn mã thông báo bí mật được truyền qua; thay vào đó, nó là một hàm băm mà máy chủ có thể xác minh ở đầu bên kia. Mặc dù có thể quá mức cho các ứng dụng ít nhạy cảm hơn nếu bạn đã thực hiện các biện pháp phòng ngừa được đề cập ở trên. Rốt cuộc, mật khẩu của người dùng đã được truyền bằng văn bản thuần khi họ đăng nhập (trừ khi bạn thực hiện một số mã hóa JavaScript ưa thích trong trình duyệt) và tương tự như vậy cookie của họ theo từng yêu cầu.

Lưu ý rằng với API, khách hàng nên chuyển mã thông báo - các chuỗi được tạo ngẫu nhiên - thay vì mật khẩu mà nhà phát triển đăng nhập vào trang web. Vì vậy, nhà phát triển sẽ có thể đăng nhập vào trang web của bạn và tạo mã thông báo mới có thể được sử dụng để xác minh API.

Lý do chính để sử dụng mã thông báo là nó có thể được thay thế nếu nó bị xâm phạm, trong khi nếu mật khẩu bị xâm phạm, chủ sở hữu có thể đăng nhập vào tài khoản của nhà phát triển và làm bất cứ điều gì họ muốn với nó. Một lợi thế nữa của mã thông báo là bạn có thể phát hành nhiều mã thông báo cho cùng một nhà phát triển. Có lẽ vì họ có nhiều ứng dụng hoặc vì họ muốn mã thông báo với các cấp truy cập khác nhau.

(Được cập nhật để bao hàm ý nghĩa của việc tạo kết nối chỉ SSL.)

Hoặc bạn có thể sử dụng giải pháp đã biết cho vấn đề này và sử dụng SSL. Certs tự ký là miễn phí và đó là một dự án cá nhân phải không?

Nếu bạn yêu cầu hàm băm của cơ thể là một trong các tham số trong URL và URL đó được ký thông qua khóa riêng, thì một cuộc tấn công trung gian sẽ chỉ có thể thay thế nội dung bằng nội dung sẽ tạo ra nội dung cùng băm. Dễ dàng thực hiện với các giá trị băm MD5 ngay bây giờ ít nhất và khi SHA-1 bị hỏng, tốt, bạn sẽ có được hình ảnh.

Để bảo vệ cơ thể khỏi sự giả mạo, bạn sẽ cần phải có chữ ký của cơ thể, điều mà một cuộc tấn công giữa chừng sẽ ít có khả năng phá vỡ vì họ sẽ không biết khóa riêng tạo ra chữ ký .

Trên thực tế, auth S3 gốc không cho phép nội dung được ký, mặc dù có chữ ký MD5 yếu. Bạn chỉ có thể thực thi thực hành tùy chọn của họ bao gồm tiêu đề Content-MD5 trong HMAC (chuỗi được ký).

http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html

Chương trình xác thực v4 mới của họ an toàn hơn.

http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html

Hãy nhớ rằng các đề xuất của bạn làm cho khách hàng khó giao tiếp với máy chủ. Họ cần hiểu giải pháp sáng tạo của bạn và mã hóa dữ liệu phù hợp, mô hình này không tốt cho API công khai (trừ khi bạn là amazon \ yahoo \ google ..).

Dù sao, nếu bạn phải mã hóa nội dung cơ thể, tôi sẽ đề nghị bạn kiểm tra các tiêu chuẩn và giải pháp hiện có như:

Mã hóa XML (tiêu chuẩn W3C)

Bảo mật XML