Tại sao viết vào clipboard trong JS được coi là một lỗ hổng bảo mật?

Question

Dường như hiện tại không có phương pháp JavaScript thuần túy để truy cập vào khay nhớ tạm thời của hệ thống bằng cách sử dụng hầu hết các trình duyệt hiện đại, Internet Explorer là một ngoại lệ. Trên nhiều câu hỏi Stack Overflow khác (ví dụ: Clipboard access using Javascript - sans Flash?), giải thích rằng giới hạn này là biện pháp bảo mật có chủ ý để bảo vệ chống lại các trang web đọc mật khẩu hoặc dữ liệu nhạy cảm khác từ khay nhớ tạm.

Mặc dù có vẻ như rõ ràng rằng đọc từ khay nhớ tạm sẽ là một rủi ro bảo mật rất lớn, không rõ lý do tại sao viết vào khay nhớ tạm. Kịch bản nào, nếu có, là các trình duyệt bảo vệ chống lại bằng cách từ chối JS khả năng sao chép dữ liệu vào clipboard?

Answer 1

Ghi vào khay nhớ tạm là cách để các trang web độc hại (hoặc mã khác chạy trong các trang web, chẳng hạn như quảng cáo dựa trên flash) lừa người dùng lây lan phần mềm độc hại. Điều này xảy ra một vài năm trước với quảng cáo dựa trên flash đã sao chép URL phần mềm độc hại vào khay nhớ tạm, với hy vọng người dùng sẽ dán nó khi họ định dán thứ gì đó khác, làm ô nhiễm những thứ như bài đăng trên facebook, diễn đàn và e-mail. Thay vì một liên kết đến một bức ảnh của con mèo của Dì Tilly, bạn sẽ dán một liên kết đến một số phần mềm độc hại do ổ đĩa. Thông thường đây là những "bạn đã bị nhiễm virus, trả cho chúng tôi 50 đô la cho phần mềm xóa" lừa đảo chống vi-rút giả mạo. Tôi đã làm một số nghiên cứu về nó, như rất nhiều khách hàng ClipMate của tôi đã hỏi tại sao những URL khó chịu này đột nhiên xuất hiện trong ClipMate. Trong khi nghiên cứu, tôi đã bị tấn công bởi các quảng cáo dựa trên flash trên MSNBC và DIGG. Clipboard sau đó đã bị khóa lại trong Flash 10. Bạn có thể đọc thêm về saga của tôi tại đây: http://www.clipboardextender.com/defective-apps/clipboard-virus-not-exactly-but-still-dangerous

Tôi kỳ vọng rằng hạn chế JavaScript là để ngăn chặn những điều tương tự xảy ra.

Answer 2

Điều gì sẽ xảy ra nếu người dùng không muốn ghi đè clipboard của mình?

Answer 3

Nếu người dùng mong rằng khay nhớ tạm của họ chứa một thứ, nhưng bí mật nó được thay thế bằng một thứ khác, ngay cả đó là vấn đề bảo mật tiềm ẩn, không chỉ là một sự phiền toái.

Mặc dù một vector tấn công không chắc, nhưng không phải là điều không hợp lý khi nghĩ đến điều gì đó liên quan đến kỹ thuật xã hội: thuyết phục người dùng dán thông tin bị thay đổi bí mật vào trường mật khẩu trên tài nguyên đích. Tài nguyên đó sau đó sẽ được bảo vệ bằng mật khẩu được biết đến với kẻ tấn công.

Answer 4

Ngoài các vấn đề về lỗ hổng nêu trên, có ít nhất một tình huống trong đó việc triển khai API clipboard tạm thời của IMP có thể làm tăng một số vấn đề bảo mật. Ngày nay, chúng tôi có các API mới để thiết lập kết nối giữa các cửa sổ riêng biệt mà không cần gọi phía máy chủ, như postMessage, MessageChannel hoặc, giả sử, BroadcastChannel gần đây được giới thiệu với Firefox. Các API này có mức hỗ trợ trình duyệt khác nhau nhưng tất cả chúng đều đang xem xét các vấn đề liên quan đến nguồn gốc. Đó là, nó sẽ không thể nhận được một tin nhắn từ một cửa sổ trên một máy chủ khác nhau, trừ khi cửa sổ này thực sự rõ ràng cho phép nó.

Điều này không giữ với API khay nhớ tạm. Hãy tưởng tượng rằng một số mã trên trang dán mã vào clipboard và khay nhớ tạm này được quét bởi một số cửa sổ khác. Đây là một số kịch bản rất kỳ lạ và có tính thuyết phục cao, phụ thuộc vào một số giả định khá kỳ lạ và kỳ lạ, nhưng đáng nói đến nó.