Pull to refresh

Comments 64

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

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

UFO just landed and posted this here

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

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

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

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

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

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

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

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

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


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

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

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

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

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

Typical.

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

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

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

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

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

Впрочем, если у пользователя неопределенное время болтаются пароли в буфере обмена, то возможность их кражи его явно не сильно беспокоит.

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

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

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

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

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

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

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

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

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

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

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

Ну, 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).

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

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

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

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

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

@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]);

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

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

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

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

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

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

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

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

// ==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. Увы, не помню, откуда стащил. Там не было автодобавления «стырено с сайта». :-)

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

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

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

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

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

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

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

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

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

В расширениях может сломаться.

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

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

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

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

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

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

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

Буфером обмена пользуются только ламеры.
Программисты используют MOV

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

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

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

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

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

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

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

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

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

Чисто теоретически в буфер обмена можно запихать скрытый файл с вредоносном, и при вставке вместо фоточек появится вирус. Правда для этого нужно, чтобы сошлись звезды и между копированием и вставкой фоточек пользователь посетил зловредный сайт (или не посетил, если это можно делать фоне...).
Отличная иллюстрация того, почему браузерный стек JS+CSS+HTML — такое костыльное дерьмище. Вот как раз потому, что он именно так и развивается. Никто даже не задумывается о том, чтобы собрать основные юзеркейсы и сценарии использования и закрыть их потом оптимальным способом.
А просто некие безымянные разработчики в недрах нескольких крупных корпораций решают свои мелкие сиюминутные проблемки. Возникла необходимость вывести какой-нибудь дудл — OK, вносим в стандарт очередной кривой костыль, пригодный только для этого.
В итоге через пару десятилетий такого «развития» оказывается, что в стандарте до хренища кофликтующих и дублирующих друг друга фич, которые взаимодействуют крайне неочевидным образом — а в итоге ни одну типичную задачу разрабочика стандартного сайта в лоб не решить, и даже для самых простых вещей нет удобного способа реализации.

Формально,

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

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

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

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

Sign up to leave a comment.

Other news