Đảm bảo yêu cầu AJAX qua GUID

Question

Tôi đang viết một ứng dụng web sẽ gửi yêu cầu qua AJAX và muốn khóa các cuộc gọi đó. Sau một nghiên cứu nhỏ, tôi đang xem xét sử dụng một số dạng mã thông báo ngẫu nhiên (chuỗi) để được trả lại cùng với yêu cầu (GUID?). Dưới đây là các phần quan trọng trong thuật toán của tôi:

1. Chỉ định mã thông báo cho biến JavaScript (phía máy chủ được tạo).
2. Ngoài ra, lưu trữ mã thông báo đó trong một DB và cung cấp cho nó một khoảng thời gian hợp lệ (tức là 10 phút).
3. Nếu mã thông báo vẫn chưa được sử dụng và nằm trong khoảng thời gian hợp lệ, hãy cho phép cuộc gọi.
4. Trả lại thông tin được yêu cầu nếu hợp lệ, nếu không, hãy ghi lại yêu cầu và bỏ qua nó.

Với con mắt hướng tới bảo mật, điều này có hợp lý không? Đối với mã thông báo, GUID có hoạt động không - nó có phải là thứ gì khác không? Có cách nào tốt để mã hóa các biến trong yêu cầu không?

EDIT:

Tôi hiểu rằng những yêu cầu AJAX sẽ không thực sự "an toàn" nhưng tôi muốn thêm an ninh cơ bản theo nghĩa mà tôi muốn để ngăn chặn người khác sử dụng dịch vụ tôi có ý định viết. Mã thông báo ngẫu nhiên này sẽ là một hàng phòng thủ cơ bản, chống lại các cuộc gọi lạm dụng. Dữ liệu sẽ được yêu cầu (và thậm chí được gửi để tạo dữ liệu như vậy) sẽ KHÔNG được lặp lại nhiều lần.

Có thể tôi đã sai khi sử dụng GUID ... làm thế nào về một chuỗi được tạo ngẫu nhiên (mã thông báo)?

Answer 1

Nếu bạn đang thực hiện điều này để tin cậy mã mà bạn đã gửi tới trình duyệt của khách hàng, sau đó thay đổi hướng. Bạn thực sự không muốn tin tưởng đầu vào của người dùng, bao gồm các cuộc gọi từ js mà bạn đã gửi tới trình duyệt. Các logic trên máy chủ nên được thực hiện để không có gì sai có thể được thực hiện thông qua đó. Điều đó nói rằng, asp.net sử dụng một lĩnh vực đã ký kết, bạn có thể muốn đi theo cách đó nếu thật sự cần thiết.

Mở rộng một bit: Asp.net giả mạo chứng minh viewstate, được gửi dưới dạng trường ẩn html (tùy thuộc vào cấu hình). Tôi chắc chắn có các liên kết tốt hơn làm tài liệu tham khảo, nhưng ít nhất nó được đề cập trong tài liệu này: http://msdn.microsoft.com/en-us/library/ms998288.aspx

xác nhận. Điều này quy định thuật toán băm được sử dụng để tạo HMACs để tạo ViewState và các biểu mẫu chứng thực bằng chứng giả mạo. Thuộc tính này cũng được sử dụng để chỉ định thuật toán mã hóa được sử dụng cho mã hóa ViewState . Đây thuộc tính hỗ trợ các tùy chọn sau:

• SHA1-SHA1 được sử dụng để can thiệp vào bằng chứng ViewState, và nếu cấu hình, hình thức vé xác thực. Khi SHA1 được chọn để xác thực thuộc tính , thuật toán được sử dụng là HMACSHA1.

Liên kết cho lớp .net cho thuật toán đó http://msdn.microsoft.com/en-us/library/system.security.cryptography.hmacsha1.hmacsha1.aspx.

Cập nhật 2: Để chống giả mạo bạn muốn ký dữ liệu (không mã hóa dữ liệu). Lưu ý rằng khi sử dụng mật mã nói chung, bạn thực sự nên tránh sử dụng triển khai hoặc thuật toán tùy chỉnh. Về các bước, tôi sẽ tuân theo:

• Chỉ định mã thông báo cho biến JavaScript (phía máy chủ được tạo). Bạn bao gồm thông tin để xác định yêu cầu và ngày chính xác & thời điểm nó được phát hành. Chữ ký sẽ xác thực ứng dụng phía máy chủ đã phát hành dữ liệu.
• Xác định các lần gửi đôi nếu thích hợp.

Điều đó cho biết, lý do asp.net xác thực chế độ xem theo mặc định, là vì người dev dựa vào thông tin đến trong đó vì chỉ được ứng dụng xử lý khi họ không nên. Điều tương tự có thể áp dụng cho kịch bản của bạn, không dựa vào cơ chế này. Nếu bạn muốn đánh giá liệu ai đó có thể làm điều gì đó sử dụng xác thực + ủy quyền hay không. Nếu bạn muốn biết cuộc gọi ajax chỉ gửi các tùy chọn hợp lệ, hãy xác thực chúng. Không hiển thị API ở cấp độ chi tiết hơn cấp độ mà bạn có thể ủy quyền thích hợp cho các hành động. Cơ chế này chỉ là một biện pháp bổ sung, trong trường hợp một cái gì đó bị trượt, không phải là một sự bảo vệ thực sự.

Ps. với HMACSHA1 ở trên, bạn sẽ khởi tạo nó bằng một khóa cố định

Answer 2

"Bảo mật" là một thuật ngữ mơ hồ. Chính xác thì bạn đang cố đạt được điều gì? Sử dụng GUID là cách hoàn toàn tốt để ngăn các lần gửi trùng lặp của cùng một yêu cầu, nhưng đó là tất cả.

Nếu thông tin được truyền giữa máy khách và máy chủ thực sự nhạy cảm, bạn nên làm điều đó qua HTTPS. Đó thực sự là câu trả lời duy nhất cho đến khi đảm bảo sự liên lạc thực sự được quan tâm.

Chỉnh sửa: Để trả lời câu hỏi của bạn về việc liệu GUID có phải là "đúng" không - không có cách nào đúng để thực hiện những gì bạn đang đề xuất. Sử dụng bất kỳ mã thông báo nào, dù đó là GUID hay một thứ gì đó do chính bạn tạo ra, sẽ không có bất kỳ tác động nào khác ngoài việc ngăn chặn các lần gửi trùng lặp của cùng một yêu cầu. Đó là nó.

Answer 3

Nó thực sự phụ thuộc vào những gì bạn đang cố gắng thực hiện bằng bảo mật. Nếu bạn muốn ngăn chặn việc sử dụng trái phép các điểm cuối HTTP, bạn có thể thực hiện rất ít việc này vì người dùng sẽ có toàn quyền truy cập vào HTML và JavaScript được sử dụng để thực hiện các cuộc gọi.

Nếu bạn muốn ngăn không cho ai đó đánh cắp dữ liệu trong các yêu cầu AJAX thì tôi sẽ chỉ sử dụng SSL.

GUID được sử dụng theo cách bạn đang đề xuất thực sự chỉ là phát minh lại cookie id phiên.