JSONP có an toàn để sử dụng không?

Question

Có vấn đề bảo mật nào cần được xem xét khi sử dụng JSONP không?

Answer 1

Cập nhật: JSONP là một hack phổ biến để thực hiện yêu cầu miền chéo. Các trình duyệt hiện đại giờ đây có Cross Resource Resource Sharing, và IE8 + có XDomainRequest tương tự. Xem http://enable-cors.org/ để biết thêm thông tin.

JSONP chỉ là một tập lệnh bao gồm cho phép bạn sử dụng gọi lại. Tuy nhiên, bạn nên biết về Cross-site request forgery (CSRF).

Miễn là bạn kiểm soát tập lệnh và máy chủ, JSONP không còn không an toàn so với tập lệnh bao gồm. Trừ khi bạn có một dịch vụ JSONP trả về dữ liệu nhạy cảm cho người dùng đã đăng nhập. Một trang web độc hại có thể gửi yêu cầu đến dịch vụ (hy vọng rằng người dùng đã đăng nhập trên trang web của bạn) và truy xuất dữ liệu. Dịch vụ có thể kiểm tra liên kết giới thiệu của yêu cầu nhưng có thể giả mạo liên kết giới thiệu bằng flash (cảm ơn Chris Moschini).

Hãy tưởng tượng senario này: - Người dùng đăng nhập vào tài khoản ngân hàng internet của mình. Lưu trữ cookie phiên trong trình duyệt của người dùng. Trang web này có dịch vụ jsonp với thông tin nhạy cảm về người dùng và tài khoản của anh ấy. - Các trang web khác sẽ không biết rằng người dùng đã đăng nhập, nhưng họ có thể đoán ngẫu nhiên và cố truy cập dịch vụ jsonp. Vì người dùng có cookie phiên, trình duyệt sẽ nhận được phản hồi và không có gì ngăn trang web thực hiện bài đăng ajax để lưu dữ liệu nhạy cảm trên máy chủ của họ.

Cập nhật 28 tháng 6 năm 2012: Nếu bạn muốn bảo vệ chống CSRF tấn công bạn nên đọc này trong bài đăng blog sâu bởi một chuyên gia bảo mật: http://erlend.oftedal.no/blog/?blogid=130

Answer 2

Có, bạn cần phải cẩn thận, nhưng khi sử dụng đúng cách với dịch vụ đáng tin cậy nó tương đối an toàn.

Dưới đây là một bản tóm tắt các vấn đề an ninh với JSONP, như tôi hiểu nó:

Từ quan điểm của người tiêu dùng:

• Bạn phải tin tưởng vào nhà cung cấp để không trở về JavaScript độc hại thay cho JSON dự kiến ​​bọc trong hàm gọi lại JSONP mà bạn chỉ định.
• Điều tương tự cũng đúng với bất kỳ tiện ích nhúng JavaScript nào của bên thứ ba, chẳng hạn như Google Analytics.
• Nó chỉ tương tự như các cuộc tấn công XSS ở chỗ nó cho phép bên thứ ba thực thi JavaScript tùy ý trong ứng dụng của bạn, tuy nhiên, trước tiên bạn phải chọn tin tưởng bên thứ ba đó bằng cách thực hiện yêu cầu ngay từ đầu.

Từ góc nhìn của nhà cung cấp:

• Bạn không phải thừa nhận rằng mặc dù cookie của khách hàng (s) có mặt trong yêu cầu mà người tiêu dùng là một trang web dưới sự kiểm soát của bạn. Kiểm tra tiêu đề Người giới thiệu dựa trên danh sách trắng các URL được ủy quyền và/hoặc không dựa vào xác thực dựa trên cookie.
• Tương tự như một cuộc tấn công phó CSRF/bối rối.

Answer 3

Có vấn đề bảo mật cho cả hai bên. Điều nghiêm trọng nhất là cho trang web bao gồm JSONP.

Nếu bạn đang bao gồm từ một miền khác (mà bạn không kiểm soát), tên miền đó có thể thay đổi tập lệnh bất kỳ lúc nào. Họ có thể làm cho javascript làm bất cứ điều gì trong bối cảnh của trang web của bạn, mà javascript của riêng bạn có thể làm. Không có cách nào xung quanh điều này nếu bạn sử dụng JSONP. Bạn nên nhìn vào giao tiếp tên miền chéo bằng cách sử dụng iframe, được thực hiện tốt nhất bởi thư viện EasyDXM xuất sắc.

Nếu bạn đang cung cấp dịch vụ web xử lý JSONP, bạn phải bảo vệ khỏi Yêu cầu qua trang web giả mạo (CSRF). Đây là nơi webservice của bạn trả về thông tin nhạy cảm cho người dùng đã đăng nhập. Nếu người dùng đã đăng nhập vào trang web của bạn, bất kỳ trang web nào khác có thể tạo yêu cầu GET cho dịch vụ JSONP và cookie của miền của bạn được gửi cùng với yêu cầu - về bản chất, xác thực người dùng đã đăng nhập - ngoại trừ bây giờ, điều khiển từ xa miền nhận được phản hồi và có thể đọc dữ liệu nhạy cảm!

Cách tốt nhất để bảo vệ chống lại CSRF là tạo ra một nonce (một số khó đoán, được tạo ngẫu nhiên) và lưu nó trong phiên. Xuất ra nonce này trong tất cả các biểu mẫu của bạn trên các trang web CỦA BẠN, và bao gồm nó trong tất cả các yêu cầu JSONP trên các trang CỦA BẠN. Trên máy chủ, đảm bảo rằng nonce có mặt và chính xác trong yêu cầu (cho dù đó là GET, POST, v.v.) Các miền khác sẽ không thể đoán được nonce này và do đó không thể nhận được thông tin nhạy cảm, mặc dù cookie đang được gửi.

Cuối cùng, có một loại vấn đề bảo mật khác: JSONP đơn giản không hỗ trợ xác thực người dùng trong trình duyệt, loại có thể với OAuth. Bạn có thể, tất nhiên, có máy chủ nhận được một số loại mã thông báo truy cập (như với OAuth) và sử dụng nó. Tuy nhiên, nếu bạn muốn thực hiện xác thực hoàn toàn trong trình duyệt, bạn phải sử dụng giao tiếp tên miền chéo với iFrames. Tôi nghĩ đây là cách OAuth 2.0 thực hiện nó. Dưới đây là cách bạn thiết lập: các trang được lưu trữ trên trang web của bạn có toàn quyền truy cập vào máy chủ của bạn. Có một thư viện javascript tải EasyDXM và sử dụng nó để thiết lập một khung nội tuyến ẩn cho trang web của bạn, và nói chuyện với nó bằng cách sử dụng đó.

Answer 4

giải pháp! dung dịch!

Tôi nhận được suy nghĩ này rằng có một tên miền chéo hack tên miền mà không thực thi mã đến, nhưng cho phép bạn vượt qua một biến. Tại sao không sử dụng nó để quấn xung quanh vì sự an toàn? ...

Và vâng, ai đó có ý tưởng này lần đầu tiên, như thường lệ :)

http://beebole.com/blog/general/sandbox-your-cross-domain-jsonp-to-improve-mashup-security/

Và cũng là window.postMessage, đó là an toàn và không hacky