Có quá kỹ thuật không nếu tôi thêm sự bảo vệ chống lại hành vi sai trái có chủ ý của người dùng (nói một cách nhẹ nhàng), nếu tác hại mà người dùng có thể phải chịu không liên quan đến mã của tôi?
Để làm rõ, tôi đang phơi bày một dịch vụ JSON RESTful đơn giản như thế này:
GET /items - to retrieve list of user's items
PUT /items/id - to modify an item
POST /items - to add a new item
Bản thân dịch vụ này không có nghĩa là được sử dụng qua một trình duyệt, mà chỉ từ các ứng dụng của bên thứ ba, được kiểm soát bởi người dùng (như ứng dụng điện thoại, ứng dụng máy tính để bàn, v.v.). Ngoài ra, bản thân dịch vụ nên không trạng thái (tức là không có phiên).
Việc xác thực được thực hiện với Xác thực cơ bản qua SSL.
Tôi đang nói về một hành vi "có hại" như thế này:
Người dùng nhập url GET trong trình duyệt (không có lý do nào ngoài ...). Trình duyệt yêu cầu Auth cơ bản, xử lý nó và lưu trữ auth cho phiên duyệt hiện tại. Không đóng trình duyệt, người dùng truy cập trang web độc hại, có javascript CSRF / XSRF độc hại tạo POST cho dịch vụ của chúng tôi.
Kịch bản trên rất khó xảy ra và tôi biết rằng từ góc độ kinh doanh, tôi không nên quá lo lắng. Nhưng để cải thiện tình hình, bạn có nghĩ rằng nếu tên người dùng / mật khẩu được yêu cầu trong dữ liệu JSON POST cũng sẽ giúp ích?
Hoặc tôi nên bỏ Basic Auth hoàn toàn, loại bỏ GET và chỉ sử dụng POST / PUT với thông tin ủy quyền trong đó? Vì thông tin lấy được máng GET cũng có thể nhạy cảm.
Mặt khác, việc sử dụng các tiêu đề tùy chỉnh có được coi là triển khai REST thuần túy không? Tôi có thể thả Auth cơ bản và sử dụng các tiêu đề tùy chỉnh. Bằng cách đó, ít nhất có thể tránh được cuộc tấn công CSRF từ trình duyệt và các ứng dụng sử dụng dịch vụ sẽ đặt tên người dùng / mật khẩu trong thạch cao tùy chỉnh. Điều tồi tệ cho phương pháp này là, hiện tại dịch vụ không thể được sử dụng từ trình duyệt.