#статья дня

Думаете, 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

#новость дня

Как вам такое: взломать npm, получить доступ к пулу пакетов, которые скачивают по два миллиарда раз в неделю и всё ради чего? Ради призрачного шанса попасть в UI какой-нибудь крипто или NFT-биржи и украсть эфирчик-другой.

Звучит как плохая серия сериала Скорпион? А нет, это вот буквально вчера случилось. Да-да, я опоздал с новостью.

Итак, некто с помощью фишингового письма с требованием обновить 2FA-токены умудрился обмануть ментейнера нескольких пакетов для работы с командной строкой (chalk, например, чтобы эту самую строку красить. Очень полезно.) Джоша Джунона.

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

В выпущенные атакующими обновления пакетов был подставлен вредоносный код, выполняемый на системах пользователей, работающих с сайтами или приложениями, использующими скомпрометированные версии пакетов. Вредоносная вставка для браузеров осуществляла перехват трафика и активности Web API, прикрепляя свои обработчики к функциям fetch и XMLHttpRequest, а также вмешивалась в работу типовых интерфейсов криптокошельков для скрытой подмены реквизитов получателя при переводе. Подмена осуществлялась на уровне модификации значений в запросах и ответах, незаметно для пользователя (в интерфейсе пользователя показывались корректные реквизиты). Поддерживались форматы транзакций Ethereum, Bitcoin, Solana, Tron, Litecoin и Bitcoin Cash.

В общем, технические подробности и список пакетов есть тут: https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised

Очень рекомендую проверить установленные версии даже если вы не держите у себя на сайтах кошельки и биржи. А если держите — тем более.

И вообще, котаны, проверяйте, откуда письма и их смысл. Вы прочитайте письмо с иллюстрации — ну курам на смех.

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

#npm #security

#молния дня

По данным Aikido, в экосистеме npm снова обнаружена очередная атака на цепочку поставок.

Речь идёт о новом черве, который действует автоматически и был создан той же группой, что стояла за инцидентом в августе. Кажется, они прочитали комментарии к предыдущему посту: https://xn--r1a.website/htmlshit/3761

Схема атаки выглядела так: в репозиторий загружались вредоносные версии пакетов. При установке они собирали информацию из окружения и CI — переменные process.env, ключи облачных сервисов и другие секреты.

Эти данные выгружались в GitHub в репозитории с названием «Shai-Hulud». Параллельно добавлялись workflow в GitHub Actions, которые отправляли содержимое на внешний сервер (через webhook) и дублировали его в логи.

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

Проверьте свои машины на наличие червя:

find . -type f -name "*.js" -exec sha256sum {} \; | grep "46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09"

Кстати, на сей раз снова началось с утилитки про цвета, @ctrl/tinycolor.

Чтобы снизить риски, рекомендуется фиксировать версии зависимостей, не обновляться сразу на latest, использовать lock-файлы (все же знают, что для CI запуск установки надо проводить с ключом фриза?) и инструменты проверки.

Отдельно стоит отметить, что pnpm уже предпринял шаги для сокращения таких рисков: некоторое время назад был удалён механизм postinstall-скриптов, который часто использовался злоумышленниками. А недавно появилась опция minimumReleaseAge, позволяющая задерживать публикацию новых версий на сутки или дольше. Это даёт время на анализ и позволяет заметить подмену до того, как пакет попадёт в продакшен.

Но любим мы pnpm не только за это.

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

#npm #security #attack

#ссылка дня

Сupercookie — https://github.com/jonasstrehle/supercookie
— показывает почти абсурдный рабочий (но в 2025 году лишь частично) способ отслеживать людей через обычную фавиконку.

Браузер хранит эти маленькие иконки так упорно, что по одному только факту: «запросил он её повторно или нет», можно собрать устойчивый идентификатор.

Кстати, поскольку тема не новая, я решил проверить.

Итак:
1. В Chrome стабильно устойчиво, даже после перезапуска браузера
2. В Chrome Incognito устойчиво в пределах сессии, новая сессия — новый айди.
3. В Firefox устойчиво в пределах сессии. Перезапуск бораузера — новая сессия, новый айди.
4. В Firefox Private Window аналогично инкогнито в Chrome: новое окно — новый айди.
5. В Safari вообще определить не смогло — постоянный редирект :)

Фавиконка уже давно время от времени выстреливает в самых неожиданных местах. Когда-то находили утечки приватного режима в Firefox — браузер сохранял фавиконки даже там, где вообще не должен был ничего помнить. Были случаи, когда соединение, открытое ради favicon, не закрывалось даже после того, как вкладку закрыли.

То есть сама механика суперкуки не падает с неба. И теперь это оформлено в аккуратный POC: заходишь на демо в репозитории, а оно спокойно узнаёт тебя, потому что favicon-кэш живёт своей отдельной жизнью.

И самое ироничное во всём этом: автор сидит и пишет диссертацию, как превратить такую пустяковую деталь интерфейса в стабильный механизм идентификации.

А какова была тема вашей диссертации, котаны? Я вот Шазам копировал.

Если что, есть перевод: https://habr.com/ru/companies/itsumma/articles/542734/

#favicon #security

#статья дня

SourceCraft обновил ИИ-агента — Code Assistant теперь помогает с безопасностью кода и командной работой.

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

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

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

Хороший пример того, как ИИ перестаёт быть «магией» и становится инструментом ежедневной разработки.

#ai #code #security