В Chrome внесено изменение, допускающее запись в буфер обмена без действий пользователя

В недавних выпусках движка Chromium изменено поведение, связанное с записью в буфер обмена. Если в Firefox, Safari и старых выпусках Chrome запись в буфер обмена допускалась только после явных действий пользователя, то в новых выпусках для записи достаточно просто открыть сайт. Изменение поведения в Chrome объясняется необходимостью чтения данных из буфера обмена при выполнении теста, проверяющего работу заставки Google Doodle на странице открытия новой вкладки. Вместо специфичной обработки данной ситуации, в Chromium просто разрешили всем сайтам обращаться к буферу обмена (читать и записывать) без необходимости предварительных действий со стороны пользователя.

Возможность записи работает при вызове методов navigator.clipboard.write (пример) и navigator.clipboard.writeText (пример), которые теперь не учитывают активность пользователя на странице. Например, для записи в буфер обмена сразу после открытия сайта достаточно выполнить следующий JavaScript-код:

navigator.clipboard.writeText('Hello from the web page.');

  let type = 'text/plain';

  let blob = new Blob(['Hello from web page'], { type });

  let item = new ClipboardItem({ [type]: blob });

  navigator.clipboard.write([item]);

@Melonom
28.08.2022 19:55 UTC
Первоисточник

Комментарии

@pae174
28.08.2022 15:18 UTC
+26

Вангую появление нового вида рекламы в интернетах.

@freeExec
28.08.2022 15:21 UTC
+34

Ну это помимо воровства паролей

28.08.2022 16:13 UTC
0
НЛО прилетело и опубликовало эту надпись здесь
28.08.2022 16:48 UTC
+5

Так доступ только на запись, а не на чтение

28.08.2022 17:07 UTC
+8

Это не сильно утешает, если писать будут что-то вроде строки "rm -rf / \n"

28.08.2022 17:14 UTC
+2

Вот же, прям в тексте новости, что читать тоже.

29.08.2022 04:07 UTC
0

Читать без разрешения пользователя никто не даст. Вероятно теперь можно читать без действий пользователя на странице (клика по кнопке) сайту, которому и так можно читать.

@Latrommy
03.09.2022 17:06 UTC
0

Это цветочки. Скоро появится фича, позволяющая случайно копипастить буфер обмена в /dev/mind.
Но мы об этом не узнаем...................

@drinkmaker
28.08.2022 15:35 UTC
+16

Ну как так то?

@apro
28.08.2022 15:54 UTC
+48

Ну судя по первой ссылке в статье:

  1. У разработчика не прошли тесты использующие буфер обмена и чтобы не усложнять себе жизнь и заниматься эмулировать нажатие Ctrl+C/V он просто убрал ограничение что работа с буфером обмена должна быть инициирована пользователем

  2. Патч прошел ревью без каких-либо проблем и был замерджен в главную ветку,

    прямо как скетче про ревью кода: https://www.youtube.com/watch?v=rR4n-0KYeKQ

@CoolCmd
28.08.2022 16:17 UTC
+31

пикантная деталь: у разработчика, сделавшего гениальное изменение, адрес miscrosoft.com и имя, похожее на индусское. (обычно у разработчиков почта chromium.org). делайте выводы.


в связи с поднятой волной, в issue зашли нормальные разработчики и повысили приоритет, так что косяк до релиза скорее всего не дойдет. запись текста не слишком напрягает, а вот чтение...

28.08.2022 16:44 UTC
+22

We should not be removing the user gesture requirement just for tests to pass

Не ожидал такую прописную истину встретить в обсуждении такого проекта как chrome

28.08.2022 21:58 UTC
+2

Потом вопросы у людей почему такого говеного качества хром и винда...вот потому что такое головотяпы индусские пишут.

28.08.2022 22:30 UTC
+3

Закоммитил один индус из Microsoft, отревьюил другой индус из Microsoft. Нуачо, тесты теперь passed.

Typical.

Надеюсь, до релиза откатят.

29.08.2022 01:27 UTC
+1

Не, один из ревьюеров таки из Гугла, аж два года как выпустился из института.

https://www.linkedin.com/in/austin-sullivan

@ThePaleEmperor
28.08.2022 15:53 UTC
+5

в Chromium просто разрешили всем сайтам обращаться к буферу обмена (читать и записывать)

Новый вид слежки и кражи паролей.

@dartraiden
28.08.2022 16:19 UTC
0
Впрочем, если у пользователя неопределенное время болтаются пароли в буфере обмена, то возможность их кражи его явно не сильно беспокоит.
28.08.2022 16:55 UTC
+2

А не надо неопределённое, если раз в секунду его проверять. Довод в пользу использования менеджеров паролей.

28.08.2022 17:11 UTC
+5

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

28.08.2022 18:24 UTC
+1

KeePass оригинальный умеет в принудительную очистку буфера обмена. По таймеру сразу после копирования пароля. Не панацея, конечно, но уже поспокойнее.

KeePass как плагин для браузера - это... не совсем официальная его реализация. Которая априори не может многого функционала из оригинальной версии (и априори х2 небезопасна, если не заморачиваться с установкой как-то по-хитрому).

29.08.2022 06:23 UTC
0

А вот что подумалось, браузер "видит" второй буфер обмена некоторых LINUX оболочек, в который попадает выделенный текст и который можно извлечь по миддлклику?

29.08.2022 10:29 UTC
0

Ну, я скорее про KeePassXC. Очистку буфера он тоже умеет, просто по таймеру (делали paste или нет и сколько раз до срабатывания таймера он не контролирует).

Плагин вполне официальный (для KeePassXC). И он вполне безопасен, насколько это вообще возможно. Установка не то, чтобы прям хитрая: включить интеграцию с нужным браузером в KeePassXC, инициировать подключение из браузерного плагина, одобрить подключение в KeePassXC. Насколько я понимаю, при этом создаётся аутентифицированный канал между плагином и KeePassXC, и другие плагины или десктопные приложения через этот канал доступ к данным KeePassXC получить не могут.

29.08.2022 11:25 UTC
0

Истины ради и справедливости для, я веду речь о том KeePass, который тут: https://keepass.info/download.html

Ваш вариант https://keepassxc.org/download/ я вижу у авторов оригинального KeePass в перечне неофициальных/пожертвованных. Это не одно и то же.

Насколько я понимаю, при этом создаётся аутентифицированный канал между плагином и KeePassXC, и другие плагины или десктопные приложения через этот канал доступ к данным KeePassXC получить не могут.

Можно об этом где-то поподробнее почитать, чтобы представление получить?
Интуиция говорит мне, что тут либо какое-то недопонимание (возможно, нами обоими), либо какой-то буллщит (со стороны разработчика).

29.08.2022 11:47 UTC
+1

Ну, KeePassXC уже довольно давно весьма популярен (как минимум на линухе он популярнее оригинального, потому что нативный и не тянет за собой Mono/Wine) и использует правильные практики в плане безопасности, так что на мой вкус его вполне уместно считать не менее "официальным" (в плане доверия ему) чем оригинальный.

Если не путаю, то для коммуникации используется native messaging (https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging, https://developer.chrome.com/docs/extensions/mv3/messaging/#native-messaging-host).

29.08.2022 11:52 UTC
+1

Вот краткое описание способа коммуникации https://github.com/keepassxreboot/keepassxc-browser#how-it-works, плюс вот детальное описание протокола с шифрованием https://github.com/keepassxreboot/keepassxc-browser/blob/develop/keepassxc-protocol.md.

28.08.2022 19:15 UTC
0

Так можно ж не через "go-fill-submit", а зайти на страницу, дойти до ваода пароля и заполнить уже появившееся парольное поле. Не знаю, умеет ли такое плагин к keepass, но вроде для мп это штатный функционал (заодно проверит, что не на фишинговом сайте это делаете).

Upd: примеры таких сайтов не назовёте? Хочу на работе проверить, как мы с ними справляемся)

29.08.2022 10:49 UTC
0

Не знаю, что такое go-fill-submit. Обычно речь как раз о том, чтобы зайти на страницу, дойти до формы аутентификации, и вот там как раз плагин справляется не всегда. Насколько я понимаю, сложность обычно возникает тогда, когда одновременно оба поля не показываются, и при этом автоматическое определение поля с паролем по какой-то причине не срабатывает. И получается так, что при попытке вручную подсказать плагину поля логина и пароля можно подсказать только одно из них.

Примеры: https://app.asana.com/-/login и https://www.notion.so/login. Сейчас поиграл с тонкой настройкой - вроде удалось добиться работы плагина на этих сайтах… правда, на ношион срабатывает не каждый раз почему-то (возможно разные бэкенды возвращают немного разные страницы).

@freehabr
28.08.2022 16:24 UTC
+3

Проверил на чтение. На чтение все-таки браузер спрашивает у пользователя.

@ZeroBot-Dot
28.08.2022 16:47 UTC
+4

@Melonomа почему бы код не обернуть в code?

navigator.clipboard.writeText('Hello from the web page.');
let type = 'text/plain';
let blob = new Blob(['Hello from web page'], { type });
let item = new ClipboardItem({ [type]: blob });
navigator.clipboard.write([item]);

@Melonom
28.08.2022 17:06 UTC
+2

Спасибо за совет. Подправил.

29.08.2022 06:57 UTC
+1

Я нашёл 8 отличий между блоком кода из комментария выше и вашим. В комментарии код выглядит нормально.

@aamonster
28.08.2022 16:59 UTC
+50

/me бы вообще работу с Clipboard по умолчанию запретил для всех сайтов. Задалбывают дятлы, норовящие к скопированной строке дописать "взято с нашего очешуительного сайта" (особенно доставляет, когда пытаешься что-то загуглить). Причём этим занимаются, кажется, исключительно сайты с копипастой, без своего контента.

@Retifff
28.08.2022 17:46 UTC
0

А мне наоборот, удобно новости с РБК копипастить на свой форум, сразу пруфлинк есть.

28.08.2022 19:19 UTC
+6

Ну, вам бы пришлось его добавить в исключения)

Несколько кликов для вас один раз против массы неудобств для остальных каждый раз.

@ganzmavag
28.08.2022 19:24 UTC
0

А, кстати, способы отключить это существуют?

28.08.2022 19:59 UTC
0

Емнип для firefox да, для chrome простого метода нет.

29.08.2022 19:09 UTC
0
// ==UserScript==
// @name        Goodbye selection tampering
// @namespace   tag: utils
// @include     ### insert your list here ###
// @version     1
// @grant       none
// ==/UserScript==
(function() {
    var disableSelections = function() {
        document.getSelection = window.getSelection = function() {
            return { isCollapsed: true };
        };
    };
    var script = document.createElement ("script");
    script.appendChild (document.createTextNode ("(" + disableSelections + ")();"));
    (document.body || document.head || document.documentElement).appendChild (script);
})();

Работает как минимум в Vivaldi. Увы, не помню, откуда стащил. Там не было автодобавления «стырено с сайта». :-)
@MegaLite
28.08.2022 19:29 UTC
0

А где это можно запретить? Есть рецепт для Firefox? (Linux; первичный буфер не берётся в расчёт)

28.08.2022 19:59 UTC
+8

Именно для firefox рецепт есть, google firefox disable clipboard access (настройка dom.event.clipboardevents.enabled)

28.08.2022 20:27 UTC
0

А это весь копипаст не грохнет случайно?

28.08.2022 20:40 UTC
+4

Это грохнет возможность сайтам отслеживать, когда вы делаете Copy.

Да просто попробуйте, сбросить настройку обратно недолго.

28.08.2022 21:01 UTC
0

Попробую, спасибо вам!

29.08.2022 05:25 UTC
0

Спасибо!

30.08.2022 08:32 UTC
+1

У меня это грохнуло возможность вставлять текст из буфера на некоторых сайтах ((

30.08.2022 08:50 UTC
+1

Жаль. Надо посмотреть – возможно, расширениями можно сделать это ограничение не глобально, а в зависимости от домена (но, конечно, такое расширение придётся внимательно просматривать и, возможно, собирать самому).

29.08.2022 00:30 UTC
+2

Весь - нет. В основном сломается в кастомных инпутах, основанных на contentEditable, типа всяких ckeditor/tinymce, ну или, там, фейсбуковского редактора постов.

29.08.2022 13:39 UTC
0

Ну, мордокнигу мы не юзаем, а на остальное будем поглядеть, спасибо за наводку на то, где могут возникнуть проблемы

29.08.2022 22:10 UTC
+1
В расширениях может сломаться.

Вообще, в Firefox нет смысла что-то трогать:
Writing to the clipboard is available without permission in secure contexts and browser extensions, but only from user-initiated event callbacks.
30.08.2022 09:01 UTC
0

Вообще-то есть. Когда вы выделяете на сайте текст и жмёте Ctrl-C – это и есть "user-initiated event callback". И сайт может извратить скопированный текст, как ему нравится.

@Ilusha
28.08.2022 22:22 UTC
0

Согласен, давать разрешение, как на геолокацию или камеру.

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

30.08.2022 09:03 UTC
0

Выглядит ужасным костылём, откровенно говоря. Сложным и проблемным. Даже навтыкать между ними невидимые ноды с пробелами – и то лучше.

Но да, вполне могу представить себе ситуацию, когда удобно дать доступ. Например, кнопка "скопировать" – там, где не требуется выделять текст, а он готовится сайтом.

@Boilerplate
29.08.2022 04:47 UTC
+2

Я делал хитрее - вешал событие на копирование и заменял 'а' латинское на 'a' кириллическое. Чтобы скопированные тексты хуже искались.

@s_f1
28.08.2022 17:55 UTC
-15
Буфером обмена пользуются только ламеры.
Программисты используют MOV
@Aleksandr-JS-Developer
29.08.2022 06:27 UTC
+1

А ещё посасывают смузи, разъезжая на электро-самокатах, да

@Perlovich
28.08.2022 18:31 UTC
+2

в Chromium просто разрешили всем сайтам обращаться к буферу обмена (читать и записывать)

Спасибо за новость. Буду отучаться копировать в буфер обмена чувствительную информацию.

Каждая вкладка в браузере может воровать у меня информацию. Удивительно. Надеюсь, откатят.

@Diversantos
28.08.2022 18:41 UTC
+1

Ну и где мой ускоритель инте... тфу, майнинга?

А ты сделай Win-R и Ctrl-V.

@Aigir
28.08.2022 18:46 UTC
0

Таким образом через clipboard наверное можно закинуть на комп пользователя вредоносный код, например какой-нибудь скрипт (и например вставить его из clipboard в офисный документ). Или даже готовый вредоносный файл, который потом просто вставляется из clipboard в нужное место на диске.
Я писал об этом в одном из форумов несколько лет назад применительно к RDP (копирование вредоносных файлов по RDP через clipboard)
И мне на данный момент неизвестны какие-либо антивирусы, которые бы контролировали clipboard.

@CoolCmd
28.08.2022 20:31 UTC
+2
Таким образом через clipboard наверное можно закинуть на комп пользователя вредоносный код, например какой-нибудь скрипт (и например вставить его из clipboard в офисный документ).

напоминает "албанский вирус" :)

29.08.2022 00:50 UTC
0
Чисто теоретически в буфер обмена можно запихать скрытый файл с вредоносном, и при вставке вместо фоточек появится вирус. Правда для этого нужно, чтобы сошлись звезды и между копированием и вставкой фоточек пользователь посетил зловредный сайт (или не посетил, если это можно делать фоне...).
@Alexey2005
28.08.2022 23:11 UTC
+13
Отличная иллюстрация того, почему браузерный стек JS+CSS+HTML — такое костыльное дерьмище. Вот как раз потому, что он именно так и развивается. Никто даже не задумывается о том, чтобы собрать основные юзеркейсы и сценарии использования и закрыть их потом оптимальным способом.
А просто некие безымянные разработчики в недрах нескольких крупных корпораций решают свои мелкие сиюминутные проблемки. Возникла необходимость вывести какой-нибудь дудл — OK, вносим в стандарт очередной кривой костыль, пригодный только для этого.
В итоге через пару десятилетий такого «развития» оказывается, что в стандарте до хренища кофликтующих и дублирующих друг друга фич, которые взаимодействуют крайне неочевидным образом — а в итоге ни одну типичную задачу разрабочика стандартного сайта в лоб не решить, и даже для самых простых вещей нет удобного способа реализации.
@Maksclub
29.08.2022 09:13 UTC
+2

Формально,

А просто некие безымянные разработчики в недрах нескольких крупных корпораций решают свои мелкие сиюминутные проблемки. Возникла необходимость вывести какой-нибудь дудл — OK, вносим в стандарт очередной кривой костыль, пригодный только для этого.

можно отнести не только к JS + HTML, это могут сделать и в Докере например или в Log4j, допустив страшнейшие уязвимости :)

@mallo_c
29.08.2022 06:31 UTC
0

Новый потенциал для pastejacking-атаки

@Sergei_Erjemin
29.08.2022 10:21 UTC
0

А зачем проверять работу заставки Google Doodle в открываемой вкладки, если у меня по умолчанию для новых вкладок стоит пустая страница (или dug-dug-go, или яндекс, или ...)??

@CyberKastaneda
30.08.2022 03:24 UTC
0

Ребята, это баг https://bugs.chromium.org/p/chromium/issues/detail?id=1334203 его починят.