Почему запись в буфер обмена в JS считается дырой в безопасности?

Кажется, что в настоящее время нет чистого метода JavaScript для доступа к системному буферу, использующего большинство современных браузеров, что является исключением Internet Explorer. Во многих других вопросах (например, Доступ к буферам обмена с использованием Javascript - sans Flash?) он объяснил, что это ограничение является преднамеренной мерой безопасности для защиты от веб-сайтов, считывающих пароли или другие важные данные из буфера обмена.

Хотя кажется очевидным, что чтение из буфера обмена представляет собой огромный риск для безопасности, мне непонятно, зачем писать в буфер обмена. Каким сценарием, если таковые имеются, являются браузеры, защищающие от этого, запрещая JS возможность копировать данные в буфер обмена?

Ответ 1

Запись в буфер обмена - это способ для вредоносных веб-сайтов (или другого кода, запущенного на сайтах, например, на основе флэш-рекламы), чтобы обмануть пользователей в распространении вредоносных программ. Это произошло несколько лет назад с помощью флеш-объявлений, которые скопировали URL-адрес вредоносного ПО в буфер обмена, в надежде, что пользователи вставляют его, когда они намереваются вставить что-то еще, таким образом загрязняя такие вещи, как facebook-сообщения, форумы и электронная почта. Вместо ссылки на фотографию тети Тилли, вы вставляете ссылку на некоторые вредоносные программы. Обычно это были "вы были заражены вирусом, заплатите нам 50 долларов за программное обеспечение для удаления" поддельные антивирусные мошенничества. Я провел некоторое исследование по этому вопросу, так как многие клиенты ClipMate спрашивали, почему эти неприятные URL-адреса внезапно появляются в ClipMate. Во время исследования меня атаковали флеш-объявления на MSNBC и DIGG. Буфер обмена впоследствии заблокирован во Flash 10. Вы можете узнать больше о моей саге здесь: http://www.clipboardextender.com/defective-apps/clipboard-virus-not-exactly-but-still-dangerous

Я ожидаю, что ограничение JavaScript должно предотвратить подобные события.

Ответ 2

Что делать, если пользователь не хочет перезаписывать буфер обмена?

Ответ 3

Если пользователь ожидает, что их буфер обмена содержит одну вещь, но скрытно он был заменен другим, даже это потенциальная проблема безопасности, а не просто раздражение.

Несмотря на маловероятный вектор атаки, неразумно думать о чем-то, о чем можно мечтать, что связано с социальной инженерией: убедите пользователя вставить скрытно измененную информацию в поле пароля на целевом ресурсе. Тогда этот ресурс будет защищен паролем, известным злоумышленнику.

Ответ 4

Помимо вышеперечисленных проблем с уязвимостью существует, по крайней мере, один сценарий, при котором внедрение API javascript-буфера обмена может вызвать некоторые проблемы с безопасностью.

В настоящее время у нас есть новые API для установления соединения между отдельными окнами без вызова серверной стороны, например postMessage, MessageChannel или, скажем, BroadcastChannel, недавно представленный в Firefox. Эти API имеют разный уровень поддержки браузеров, но все они рассматривают проблемы с перекрестным происхождением. То есть, было бы невозможно получить сообщение из окна на другом хосте, если это окно действительно явно не разрешает его.

Это не выполняется с помощью API буфера обмена. Представьте, что некоторый код на странице вставляет код в буфер обмена, и этот буфер обмена проверяется каким-либо другим окном. Это очень странный и высоко гипотетический сценарий, зависящий от некоторых довольно странных и экзотических предположений, но стоит упомянуть об этом.