30.08.2022 00:36
freehabr 7 3600 Источник

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

Сначала на багтрекере проблеме выставили нулевой (самый важный) приоритет решения и я думал, что ее в ближайшее время исправят.

Но буквально вчера автор бага написал, что ничего страшного в этом нет, можно не торопиться. И поставил проблеме приоритет номер 3.

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

По счастью, комментарии на багтрекере может оставлять любой желающий. Я крайне рекомендую вам оставить там сообщение, что это опасная уязвимость, и ее надо срочно исправить.

Комментарии (7)


  1. dartraiden
    30.08.2022 00:56
    #24675604
    +6

    Он там вполне ясно объяснил, почему приоритет снижен — потому что это технически не является регрессией (это не означает, что это не нужно исправлять, но это и не регрессия).

    The change is only applicable to async clipboard APIs, and not the DataTransfer APIs or execCommands. User gesture was never a requirement for read/write, readText/writeText methods, so this isn't technically a regression. In my change, I added transient user activation to read/write because we allow custom clipboard formats to be read/written via these APIs(https://chromestatus.com/feature/5649558757441536). I didn't add it for readText/writeText because some sites (like the doodle share) rely on this behavior. We need to send a breaking change first to the blink-dev before we add this restriction to these methods. Reducing the priority of this bug since its technically not a regression. This behavior has been there since we shipped async clipboard APIs (version 66) chromestatus.com/feature/5861289330999296


    1. DrinkFromTheCup
      30.08.2022 11:11
      #24676468
      +2

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

      Правда, лично с моей колокольни за фразу "это не регресс потому, что уже было в версии ххх" надо заставлять мыть рот с мылом.
      Потому, что по такой логике в широком смысле ничто не регресс. Ведь дефективный код/логика же ВСЕГДА был в какой-то закоммиченной версии.

      Вообще, автор бага - странный кекс. Нашкодить и слинять циклов у него хватило - а откатить либо переписать набело не хватило...


    1. freehabr Автор
      30.08.2022 11:21
      #24676502
      +1

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


  1. Aleksandr-JS-Developer
    30.08.2022 09:23
    #24676122
    +1

    Уже приоритет 1


  1. MRD000
    30.08.2022 11:27
    #24676526

    Интересно, что кто-то выложил пример как это работает, но в Chrome оно не заменяет в буфере обмена ничего почему-то. Или у меня установки по-умолчанию другие?


    1. MRD000
      30.08.2022 11:34
      #24676562

      А... Нашел, "Uncaught (in promise) DOMException: Document is not focused.". Но если перезагрузить страницу, то работает.


  1. verstoff
    30.08.2022 12:40
    #24676872
    +1

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

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