Как обезопасить себя, устанавливая obsidian плагины

Плагины в Obsidian - это если не главная, то одна из главных его киллер фич, которая делает инструмент поистине универсальным. Такой возможности настолько гибко кастомизировать приложение, в частности - мобильное, нет наверное ни у одного приложения для ведения заметок. И лично я глубоко благодарен разработчикам Obsidian, что они не стали ограничивать API и дают такие же возможности community плагинам, как и себе, то есть буквально создают честную конкуренцию между своими коммерческими решениями (Sync, Publish) и частными.

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

Модель угрозы

Для начала надо понять, что именно может сделать злоумышленник через скомпрометированный плагин. API плагинов на данный момент позволяет запускать любой код, без ограничений контекста исполнения. Это значит, что плагины могут:

• делать сетевые запросы на любые сайты
• скачивать и выгружать файлы
• работать с файловой системой (не только с vault, а всей файловой системой)
• запускать другие процессы Таким образом, плагины могут содержать, например, такие зловреды, как криптомайнеры и ransomware, и не только.

Также важно понимать как именно плагины попадают к нам. Сторонний разработчик выгружает исходный код плагина на GitHub, после чего запрашивает review у разработчиков Obsidian. Они проверяют исходный код и если всё ок публикуют его в общем списке плагинов. В дальнейшем разработчик может обновлять плагин, выгружая новые версии, но на сколько я знаю, они уже не проходят проверку командой Obsidian (поправьте меня, если ошибаюсь). Вот здесь описан этот процесс.

Когда мы нажимаем кнопку установить плагин, то скачивается не исходный код, а собранная программа, обычно в виде трёх файлов: main.js, styles.css и manifest.json. Сборка обычно осуществляется с помощью GitHub Actions, что автоматизирует выгрузку новых обновлений. Но разработчик также может загрузить итоговые файлы вручную, так что они не обязательно будут соответствовать исходному коду, который вы видите в репозитории.

Таким образом я бы выделил несколько основных способов, как зловредный код может попасть к вам на компьютер вместе с каким-либо плагином:

1. Недобросовестный разработчик хочет выпустить зловредный плагин. Он публикует какой-нибудь полезный плагин, который сперва проходит review. Затем в одном из последующих обновлений он публикует собранный плагин с вредоносным кодом (скорее всего не обновляя исходный код плагина) и вы получаете его вместе с новым обновлением.
2. Аккаунт (GitHub или npm) добросовестного разработчика плагина, которым вы пользуетесь, взламывается и от его имени публикуется обновление с вредоносным кодом. Такие взломы, к сожалению, происходят достаточно часто.
3. Аккаунт разработчика одного из npm пакетов, который используется в одном из ваших плагинов, взламывается, а автоматическое обновление или невнимательный разработчик ставят его и выгружают плагин, использующий скомпрометированный код. Как раз об этом риске и как команда разработки obsidian его обходит недавно писал u/lishid. Но такой же риск присутствует и для obsidian плагинов тоже, не только для самого приложения. Безусловно есть и другие возможные риски, но касательно именно плагинов, это самые вероятные.

Как защититься

Теперь, когда мы понимаем, какие вообще у нас риски, можно поговорить о том, как себя обезопасить.

Самое очевидное решение: не ставить плагины. Так мы избегаем всех рисков, но как я писал в самом начале, было бы крайне жаль отказываться от всех тех возможностей, которые нам дают плагины.

Второй вариант: использовать только самые популярные, проверенные временем плагины. Так мы получаем самый важный функционал и нивелируем первый сценарий из описанных выше рисков. Кроме того, можно снизить вероятность возникновения 2 и 3 сценариев реже ставя обновления, но это тоже компромисс, так как в обновлениях могут быть важные исправления, а старые версии могут быть также скомпрометированы и установлены, например, при синхронизации вами нового устройства.

Вы можете сами собрать код плагина из исходного кода. Сделать это чаще всего совсем не сложно и довольно быстро. Так вы сможете быть уверены, что то, что опубликовал на GitHub разработчик, то вы и ставите себе в Obsidian, а не какую-то скомпрометированную сборку. Опишу в двух словах как это сделать для пользователей Mac. Для пользователей Windows почти всё то же самое с поправкой на то, что команды надо запускать в WSL и я не могу описать их точно, так как нет компьютера с Windows под рукой. А пользователи Linux и так всё это знают.

Итак, вам понадобятся два инструмента: git (обычно устанавливается вместе с Xcode из App Store или через brew, вот тут подробнее) и Docker. И стандартный терминал. Далее:

1. Скачиваете себе исходный код плагина (для примера возьму замечательный dataview плагин):

git clone https://github.com/blacksmithgu/obsidian-dataview.git

2. Команда выше скачает исходный код в папку ./obsidian-dataview (папка всегда называется как плагин). Перейдите в неё командой:

cd obsidian-dataview

3. Далее нам надо установить зависимости и собрать проект. Для этого проще (и безопаснее всего) использовать docker образ, в котором предустановлено всё, что нам нужно (если вы не знакомы с docker, то воспринимайте его как некую виртуальную машину, которая запускается у вас в терминале и в которой мы дальше будем выполнять все команды):

docker run -it --rm -v ./:/app -w /app node:22 bash

4. Выполнив команду выше, вы попадёте "внутрь виртуальной машины". Теперь установим зависимости плагина - это другие программы, которые нужны для его работы. Для этого выполним команду:

npm ci

5. Теперь мы можем собрать плагин, выполнив команду (почти всегда, но бывают исключения):

npm run build

6. Если в консоли вы не увидели сообщений об ошибках, то поздравляю, вы вероятно собрали свою первую программу. Далее выходим из docker командой exit.
7. В только что созданной папке вы должны увидеть новый файл: main.js. Это собранный код плагина. Часто он лежит не в корне проекта, а в папке build или release или реже в другой аналогичной. Рядом с ним или в корне проекта так же может быть styles.css. А также в корне проекта всегда лежит manifest.json. Последний - это описание плагина. Среди прочего в нём есть его id.

8. Последнее, что нам осталось сделать, это скопировать файлы main.js, styles.css и manifest.json в папку в вашем vault: ./vault/.obsidian/plugins/obsidian-dataview (папку надо прежде создать самостоятельно). Если вы не видите папки .obsidian, то включите отображение dot-files комбинацией клавиш cmd + shift + . в Finder. Теперь перезагрузите плагины в Obsidian и вы должны увидеть ваш новый плагин.

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

• Сетевые запросы. Почти любой зловредный код так или иначе должен как-то связываться с сетью. Либо для того, чтобы выгрузить полученную информацию с компьютера жертвы, либо наоборот, чтобы загрузить другой код, который уже будет нести в себе основной payload. Посмотрите, куда ходит плагин. Можно как самое простое и беглое решение пройтись поиском по http. Обычно там будет множество url из комментариев, файла package-lock.json и различных url, которые показываются вам в интерфейсе (например, funding и помощь). Но вас должно насторожить, если плагин что-то загружает и затем исполняет полученный код. Для этого поищите, например, команду eval.
• Чаще всего зловредный код так или иначе маскируется. Пройдитесь по нему и посмотрите, нет ли в коде непонятных длинных последовательностей символов, вроде такого: _0x9e38=['\x28\x2E\x2B\x3F.... Также посмотрите, нет ли среди файлов скомпилированных бинарников (не читаются как текст). Иногда плагины используют wasm, так что это не всегда плохо, но надо хотя бы понимать, зачем он им понадобился.
• Поищите запуск системных процессов. Для этого обычно используются пакеты типа child_process, execa, cross-spawn, но не обязательно только эти.
• Посмотрите package.json. Конечно, не js разработчику там будет мало что интересного, но в идеале стоит посмотреть какие зависимости использует плагин. Пакеты можно проверить на сайте npmjs.com, где написано какой функционал они предоставляют. Стоит обратить внимание на пакеты с малым количеством скачиваний или функционал, который непонятно зачем нужен данному плагину. Есть автоматизированные инструменты проверки, но о них как-нибудь в другой раз, и так этот лонгрид мало кто читать будет.
• Также в package.json могут быть скрипты, которые бывает тоже выполняют те или иные зловредные действия, но по ним я вряд ли могу дать общих рекомендаций, так как надо уже смотреть, что именно они делают.

В заключение

Если что, этим постом я не хотел никого отговаривать использовать плагины. Наоборот, лично я считаю их лучшей фичей Obsidian и пользуюсь множеством крутейших плагинов, за которые также очень благодарен их разработчикам. Но надеюсь, что этот текст даст многим лучшее понимание что именно может пойти не так и развеет иллюзии безопасности или наоборот особой опасности плагинов. Так что пользуйтесь плагинами и пусть они помогут вам в решении ваших задач. Всем добра!

Читайте также