#библиотека дня

#security #tracking #fingerprinting

Методы однозначной идентификации пользователя и/или его браузера называют fingerprinting. Буквально – снятие отпечатков пальцев. Малоприятная процедура, согласитесь :)

Существует известная библиотека — даже со своим сервисом — FingerprintJS. Она (и подобные ей) определяют пользователя по совокупности множества параметров: user agent, списки шрифтов, подключённые плагины браузера, ОС, разрешение экрана – всё идёт в ход.

Я, например, использовал её чтобы предотвратить читерство в онлайн-кликере где было важно, чтобы пользователь оставался в одном браузере.

И вот недавно появился ещё один параметр. Нас подвела старая добрая фавиконка, так родилась библиотека Supercookie.

Новость на русском с подробным объяснением принципа работы: https://www.opennet.ru/opennews/art.shtml?num=54553

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

#фишка дня

Посмотрите на этот код; ничего странного не замечаете?

А здесь происходит ого-го какая драма!

Итак, этот, казалось бы, невинный кусок кода очень даже содержит в себе бэкдор. Посмотрите внимательно на GitHub Gists: https://gist.github.com/bekharsky/fa4c071ce657e37f6d0f3e7f4a91799b

Да, это на скриншоте сложно заметить, но в деструктурировании req.query вторым параметром лежит невидимый символ \u3164. Заполнитель, буквально.

То есть:

const { timeout,\u3164} = req.query;

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

Доклад по методу: https://certitude.consulting/blog/en/invisible-backdoor/

Вообще, таких символов очень много (очень рекомендую почитать статью). Не копируйте все подряд из сети себе.

#node #js #security #unicode

#статья дня

Помните библиотеку FingerprintJS? Вот, напомню: https://yangx.top/htmlshit/509

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

Вот, попробуйте: https://csstracking.dev/

И что ещё забавнее, т. н. CSS4 может всё сделать ещё хуже с точки зрения приватности.

#css #fingerprint #privacy

#тред дня

Задержался с постом, релизил обновление продукта. Ух у юзеров будет бомбить, изменение уровня ribbon в MS Office.

Да, почти никакого автопостинга, с пылу с жару, цените, мои дорогие 😙

Итак, тут Андрей Ситник в очередной раз поднял тему безопасности npm-пакетов. Думаю, нелишним будет и тут сохранить. Далее слово автору с незначительной редактурой:

Угон пакета и вставка вредоносного кода — риски большинства пакетных менеджеров.

В npm при деплое можно снизить риски и ускорить деплой:

npm install --production --ignore-scripts

--production не будет ставить devDependencies, --ignore-scripts выключит postinstall-скрипты.

Использование --production при деплое, значит что вам более системно надо разделять dependencies (только что нужно для сборки) и devDependencies (всё остальное).

Но так даже лучше — при обновлении зависимостей сразу понятны риски (обновления devDependencies менее опасно).

TS и файлы типов не нужны для компиляции .ts в .js — swc и babel умеют отрезать типы.

Поэтому и для фронтенд-проекта и для nodejs-сервиса tsc и типы должны быть в devDependencies.

Проверка типов должна идти как тесты в отдельном задании.

Для nodejs-сервиса в dependencies записываются только те зависимости, что нужны для запуска сервера (а не его компиляции).

Отдельным заданием ставятся все зависимости и собирается JS-файлы. А внутри docker-образа сервиса установка только с --production.

#npm #yarn #pnpm #node #security

#статья дня

Думаете, SVG это только формат описания векторной графики?

Нет, всё чуть-чуть сложнее. SVG это формат, не менее интересный чем весь стек HTML, а то и более. Внутри SVG может содержаться настоящее приложение, способное включать в себя и HTML (вспоминаем мой опыт с foreignObject).

Но раз весь стек HTML, то и скрипты? И сетевые запросы? Да. К сожалению. Или к счастью.

Сначала давайте посмотрим на эту статью: https://habr.com/ru/company/pvs-studio/blog/652255/

Она для общего развития, про десктопные приложения. Но суть остаётся той же: если ваш SVG-парсер неправильно настроен, вы рискуете многим.

Ну а если занимаетесь настройкой серверов и разработкой полномасштабных проектов, то не забывайте о том, что, загрузив SVG, можно и XSS-атаку провести: https://blog.yeswehack.com/yeswerhackers/file-upload-attacks-part-2/

Вот ещё из 2011 презентация, многое неактуально из-за развития CSP в браузерах, но опять же — помните про правильную настройку: https://owasp.org/www-pdf-archive/Mario_Heiderich_OWASP_Sweden_The_image_that_called_me.pdf

Фильтруйте ваши изображения, в общем.

#svg #security #css

#заметка дня

Если у вас было хоть что-то важное на Heroku, сайд-проект или не дай бог рабочие материалы — срочно или съезжайте оттуда, или меняйте все явки-пароли.

В Heroku уже две недели творится неладное. Сначала утекли OAuth-токены (включая интеграцию с GitHub), теперь оказалось, что ещё и хешированные, конечно, но все же доступы к БД.

Не завидую я ни им, ни их клиентам, в общем: https://status.heroku.com/incidents/2413?updated

Мимо меня вся эта истерия сервисов деплоя как-то мимо прошла, мне проще было сервер развернуть в своё время. Есть в этом и плюсы, и минусы, конечно.

В общем, берегите себя и свои данные :).

#heroku #security

#новость дня

Я почти никогда не выкладываю новости, но эта насколько смешна, настолько же и ужасающа.

Данные миллиарда жителей Китая утекли в сеть: https://www.wsj.com/articles/vast-cache-of-chinese-police-files-offered-for-sale-in-alleged-hack-11656940488

Причем, не абы каких, а полицейских отчётов в том числе. И точность данных подтверждена.

Как так вышло?

Блогер на госслужбе выкатил технический пост на CSDN и в исходный код попали коды доступа (пароли и секреты) от базы данных. Потрясающе: https://twitter.com/cz_binance/status/1543700689611792386

Что это значит? Ну не знаю, как для вас, а для меня — быть крайне осторожным, выкладывая посты, связанные с моей деятельностью :)

#security #stupidity

#фишка дня

Посмотрите на этот код; ничего странного не замечаете?

А здесь происходит ого-го какая драма!

Итак, этот, казалось бы, невинный кусок кода очень даже содержит в себе бэкдор. Посмотрите внимательно на GitHub Gists: https://gist.github.com/bekharsky/fa4c071ce657e37f6d0f3e7f4a91799b

Да, это на скриншоте сложно заметить, но в деструктурировании req.query вторым параметром лежит невидимый символ \u3164. Заполнитель, буквально.

То есть:

const { timeout,\u3164} = req.query;

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

Доклад по методу: https://certitude.consulting/blog/en/invisible-backdoor/

Вообще, таких символов очень много (очень рекомендую почитать статью). Не копируйте все подряд из сети себе.

#node #js #security #unicode

#новость дня

Народ, отложили волчистость, убрали руки от клавиатуры на минутку и срочно смотрим сюда: https://blog.reversinglabs.com/blog/iconburst-npm-software-supply-chain-attack-grabs-data-from-apps-websites

С декабря 2021 года около двух десятков пакетов NPM воровали данные из форм, встроенных в мобильные приложения и сайты.

Как происходило внедрение? По опечаткам :) Регистрировались похожие на уже существующие пакеты имена. А дальше человеческая невнимательность делала своё чёрное дело.

Пройдите проверьте, нет ли у вас по-глупости чего-либо подобного. Сверьте названия, версии и хеши.

Будьте внимательны, котаны!

#js #npm #security

#статья дня

Те из вас, кто использует Instagram, TikTok, Facebook + Messenger, Snapchat, наверняка замечали, что они открывают все ссылки насильно внутри приложения. Telegram, кстати, тоже (но есть настройка). Наверное же, не просто так?

Конечно не просто так :)

Приложения на голубом глазу встраивают свой код прямо в страницу, которую открывают. И могут трекать всё, что угодно. Особенно этим отличился TikTok. Он логирует вообще всё, вплоть до нажатий клавиш: https://krausefx.com/blog/announcing-inappbrowsercom-see-what-javascript-commands-get-executed-in-an-in-app-browser

Ну а Facebook естественно божится, что они встраивают код, чтобы повысить вашу безопасность :)

Рекомендую внимательно изучить эту статью и инструмент за ней. Заставляет задуматься.

#security #privacy

#видео дня

И продолжая тему трекинга (который на самом-то деле не всегда зловредный и хочет вам навредить) вот прекрасное видео нашёл.

Утилита заставляет ваш компьютер издавать звук каждый раз, когда Chrome посылает данные в Google. Льёт в уши, так сказать. Гляньте, удивитесь.

Ну и ссылка на саму утилиту, для Linux: https://github.com/berthubert/googerteller

#security #privacy

#заметка дня

Безопасный фронтенд в 2022 году выглядит так (в оригинальном твите есть совсем спорные моменты, здесь я их стараюсь убрать или уточнить):

1. HTTPS

2. Токен (авторизационный, или рефреш — зависит от вашей спецификации) должен храниться в secure, samesite, httponly куке. Т. е. не быть доступным из JS (в случае XSS, cross-site scripting, внедрения кода, токен нельзя будет вытащить с помощью этого самого внедрённого кода).

Если не используете SSR для хотя бы для логина, fetch-запрос (ajax) вполне себе может выставить вам куку с httponly. Главное соблюсти все остальные условия и правильно выставить атрибут Path=/.

3. Объявляйте CSP (Content security policy), чтобы снизить вероятность проведения XSS.

4. Генерируйте куки заново при каждом входе пользователя. Это нужно для предотвращения session fixation, «застывшей» сессии.

5. Задавайте короткое время жизни кук (опять же, застывшие сессии).

По 2 пункту: я вижу столько кандидатов, сдающих тестовые задания с токеном в local storage… Это ладно. Но невозможность ответить на вопрос, почему это плохо — 🚩

#security #cookie #js

#фишка дня

Менеджер паролей в Google Chrome умеет определять, утекли ли ваши пароли вместе с остальными в результате взлома (или кривой конфигурации) очередного сервиса. Это не является секретом.

А вот что интересно — он предлагает сменить этот самый пароль. Но у разных сервисов же разные ссылки на страницы запроса паролей. Google и это знает?

Нет! Ему и не надо. Ведь есть соглашения.

Одним из таких соглашений является концепция Well-Known URI (известные ресурсы).

Давайте покажу: Chrome вас бросит на ссылку вроде такой: http://www.loc/.well-known/change-password

И .well-known/change-password редиректит на смену пароля. Актуальность за вами.

Если вы хоть раз добавляли на сайт Apple Pay, концепция должна быть знакомой.

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

#security #rfc #wellknown

#фишка дня

Как заставить пользователя сгенерировать надёжный пароль?

Ну, вообще — никак. Только организационно. Пришлые посетители — они и психануть могут.

Но вот в экосистеме Apple такая попытка имеется. И называется — атрибут passwordrules.

Поддерживается он не только встроенными менеджерами паролей на яблочных ОС и, соответственно, браузером Safari, но и популярным менеджером паролей 1Password.

Самое забавное, что у Apple даже специальный инструмент для проверки правил имеется: https://developer.apple.com/password-rules/

Будет ли это стандартом в скором времени? Скорее всего, нет: пользователи не очень любят ограничения, пока не прилетит в лицо. Так что надеемся на методы входа, исключающие ввод паролей в принципе.

Впрочем, пропозал есть: https://github.com/whatwg/html/issues/3518

Но если вы в могучем тырпрайзе и в вашем тырпрайзе или яблоки, или 1Password — тема рабочая.

#password #security #1password #apple

#инструмент дня

Важной частью процесса разработки является сканирование уязвимостей в коде и зависимостях. А ещё более важной — слежение за ними.

И этот процесс было бы неплохо автоматизировать.

Да, в какой-то мере справляется dependabot, но не во всех компаний используется GitHub и хотелось бы получать сводки в любой момент. Ну а npm audit такая себе игрушка.

И тут у нас имеются прекрасные инструменты. Для начала, конечно же, база уязвимостей для Open Source библиотек: https://ossindex.sonatype.org/

Обратите внимание, речь не только про JS aka npm, в каталоге присутствуют практически все мыслимые среды и пакетные менеджеры.

Второй момент это тулинг. И тут от тех же Sonatype имеется пакет AuditJS: https://github.com/sonatype-nexus-community/auditjs

И расширение для VS Code: https://marketplace.visualstudio.com/items?itemName=SonatypeCommunity.vscode-iq-plugin

Всем безопасной разработки, котаны!

#security #vulnerability #scan #audit

#инструмент дня

Важной частью процесса разработки является сканирование уязвимостей в коде и зависимостях. А ещё более важной — слежение за ними.

И этот процесс было бы неплохо автоматизировать.

Да, в какой-то мере справляется dependabot, но не во всех компаний используется GitHub и хотелось бы получать сводки в любой момент. Ну а npm audit такая себе игрушка.

И тут у нас имеются прекрасные инструменты. Для начала, конечно же, база уязвимостей для Open Source библиотек: https://ossindex.sonatype.org/

Обратите внимание, речь не только про JS aka npm, в каталоге присутствуют практически все мыслимые среды и пакетные менеджеры.

Второй момент это тулинг. И тут от тех же Sonatype имеется пакет AuditJS: https://github.com/sonatype-nexus-community/auditjs

И расширение для VS Code: https://marketplace.visualstudio.com/items?itemName=SonatypeCommunity.vscode-iq-plugin

Всем безопасной разработки, котаны!

#security #vulnerability #scan #audit #бородач

#фишка дня

Если ваш конфиг ESLint до сих пор заставляет писать rel="noopener noreferrer" в каждой targer="_blank" ссылке, вы живёте в прошлом.

Потому что писать noopener не надо.

Этот атрибут запрещает установку свойства window.opener на открытое окно, таким образом, запрещая доступ открытого окна к открывающему.

Это уже 4 года как дефолтное поведение всех (нормальных) браузеров.

Ну а ставить ли noreferrer — чтобы узнать URL, откуда пришёл пользователь — дело ваше.

#eslint #security #anchor

#такое дня

Есть у меня некое предубеждение к продуктам, которые распространяются через инфлюенсеров. Как, например, браузер Arc.

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

Например, у вас не возникало ощущения, что обязательное требование облачного аккаунта для использования такого продукта, как браузер, это как-то ненормально?

Или что концепция бустов, Boosts — это когда кто-то может сделать свой набор скриптов и правил для изменения поведения любого сайта — звучит как встроенный MITM?

Man in the middle, если что. Это вот: https://en.wikipedia.org/wiki/Man-in-the-middle_attack

И ведь так и оказалось! Автор xyzeva (я только знаю, что зовут её Ева) опубликовала результаты исследования безопасности Boosts и смогла воспроизвести атаку с подменой авторства буста на любое нужное ей.

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

Вот, почитайте: https://kibty.town/blog/arc/

TL;DR: они использовали Firebase максимально наивно.

Даже если не интересуетесь инфобезом, там прекрасная кошечка бегает за курсором.

Arc признали существование уязвимости, выкатили об этом пост и выплатили автору вознаграждение: https://arc.net/blog/CVE-2024-45489-incident-response

По счастью, предположительно никто не пострадал.

В общем, внимательно рассматривайте продукты, которые предлагают всё и сразу, just call my toll free number.

#security #browser

С начала 2000-х браузеры предоставляли пользователям удобную возможность видеть, какие ссылки они уже посещали, используя CSS-псевдокласс :visited.

Однако это удобство обернулось уязвимостью.

С помощью анализа стилей отрисованных ссылок можно было выяснить, какие страницы были посещены, что открывало путь для скрытых атак. Эта техника называется Visited Link Sniffing.

Как браузеры защищали от этого?

Для борьбы с такой угрозой браузеры внедряли различные меры:

✅ Ограничение доступа к вычисляемым стилям для :visited
✅ Игнорирование некоторых стилей вообще

Но эти подходы оставались полумерами, так как информация о посещённых ссылках оставалась глобальной, и её всё ещё можно было использовать для скрытого отслеживания. Например, буквально считая миллисекунды парсинга стилей: https://codepen.io/alinaki/pen/ogNrVoj

Примечание: это будет работать только на Firefox и Safari и только на достаточно старых машинах.

Что теперь предлагает Google?

В Chrome 123 появился новый подход — Partitioned Visited Links History. Теперь ссылки считаются посещёнными только в пределах определённого контекста. Например, для одного сайта или даже внутри конкретного iframe.

Это значит:

✅ Один сайт не будет знать, какие страницы вы посетили на другом.
✅ История посещений разделена на изолированные части (partition'ы).

Псевдокласс :visited больше не работает глобально — он зависит от контекста.

Собственно, смотрим на иллюстрацию: пока вы не посетили ссылку на каком-то сайте, она подсвечиваться не будет. А вот в каком-нибудь поисковике или соцсети, куда вы заходите постоянно — будет. Что буквально нивелирует суть атаки.

Это не только предотвращает старые методы слежки, но и делает браузеры более приватными по умолчанию. Защита теперь встроена в механизм работы с веб-страницами.

👉 Подробности:
https://github.com/explainers-by-googlers/Partitioning-visited-links-history

#history #security #safety

#новость дня

Никогда такого не было, и вот опять!

Уязвимость на базе localhost? Дайте две!

Итак, по порядку. Не так давно мы с вами обсуждали уязвимость под названием 0.0.0.0 Day. Суть её заключалась в том, что браузеры разрешали рандомным сервисам стучаться на разные порты по адресу 0.0.0.0, тем самым, позволяя этим самым сервисам определять, что же у вас на компьютере такого установлено. Это могли быть как средства для разработчиков, так и различные локальные сервисы поиска, защиты или просто мониторинга.

Так вот, на этих ваших прекрасных Android-смартфонах практически каждое приложение Facebook и Яндекса поднимают свой сервер, прослушивающий определённый диапазон портов. А скрипты аналитики и метрик передают куки этим самым серверам, связывая посещение некоего рандомного сайта с вашим аккаунтом в перечисленных компаниях.

А, каково? На iOS так сделать нельзя, потому что долгоживущие фоновые процессы ещё надо обосновать самому Apple.

А вы потом удивляетесь, откуда столько релевантной и не очень рекламы, ведь никому не говорили, никуда не входили. Только говорили.

Статья: https://localmess.github.io/
Перевод: https://habr.com/ru/articles/915732/

Совершенная красота, конечно. Facebook, кстати, перестали это использовать. Яндекс вроде ещё использует.

Почитайте статью или перевод. Очень крутая.

#cvs #security #privacy #vulnerability