10
CẬP NHẬT: GWT 2.3 giới thiệu cơ chế tốt hơn để chống lại các cuộc tấn công XSRF. Xem http://code.google.com/webtoolkit/doc/latest/DevGuideSecurityRpcXsrf.htmlGWT RPC - Liệu nó có đủ để bảo vệ chống lại CSRF không?
cơ chế RPC GWT của làm những điều sau đây trên tất cả các yêu cầu HTTP -
- Sets hai yêu cầu tùy chỉnh tiêu đề - X-GWT-hoán vị và X-GWT-Module-Base
- Sets loại nội dung dưới dạng văn bản/x-gwt-rpc; charset = utf-8
Yêu cầu HTTP luôn là POST và phía máy chủ Phương thức GET ném ngoại lệ (phương pháp không được hỗ trợ).
Ngoài ra, nếu các tiêu đề này không được đặt hoặc có giá trị sai, máy chủ không xử lý ngoại lệ "có thể là CSRF?" Hoặc một cái gì đó để có hiệu lực.
Câu hỏi là: Điều này có đủ để ngăn chặn CSRF không? Có cách nào để đặt tiêu đề tùy chỉnh và thay đổi loại nội dung trong phương thức giả mạo yêu cầu chéo trang web thuần túy không?
XmlHttpRequest, Flash và một loạt các công nghệ khác có thể đặt tiêu đề trình duyệt tùy chỉnh - nhưng chính sách có nguồn gốc giống nhau và sẽ ngăn một trang web khác đưa ra yêu cầu. Trừ khi máy chủ có một crossdomain.xml khoan dung, hoặc đang trả về Access-Control-Allow-Origin cho các trang web tùy ý, yêu cầu sẽ hoạt động như thế nào? Điều đó chỉ để lại cho chúng tôi các biểu mẫu/hình ảnh/iframe và các loại tương tự, trong đó chính sách gốc không áp dụng. Nhưng tôi không biết cách mà họ có thể đặt tiêu đề http tùy chỉnh. Vì vậy, nó dễ bị tổn thương như thế nào? –
.. và có, tôi đồng ý mã thông báo dựa trên CSRF bảo vệ là cách tốt nhất, nhưng tôi muốn hiểu lỗ hổng với cách tiếp cận của họ. –
@sri Câu hỏi rất hay. Để rút ra sự khai thác này, bạn phải tận dụng lợi thế của một thuộc tính ít được biết đến của flash. Tôi đã đăng 2 khai thác làm những gì tôi đang mô tả, tôi khuyến khích bạn sử dụng chúng. (Nếu bạn không có phần mềm dễ bị tổn thương ở mức tối thiểu, bạn có thể thấy rằng yêu cầu POST đang được gửi đến một miền khác, nhưng tập lệnh không thể "xem" phản hồi do SOP) – rook