Симо Ахава написал статью про потенциальные опасности, которые могут возникнуть при добавлении выделенного поддомена для рекламных сетей — "What's In A CNAME".

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

Часто рекламодатели начинают просить настроить выделенный поддомен с перенаправлением на их сайт. Проблема заключается в том, что такой поддомен становится first-party и получает доступ ко всем cookies, которые были установлены для доменов верхнего уровня. Так как владельцы сайтов не имеют доступ к этим серверам, они по сути отдают все данные пользователей, которые передаются в cookie, в том числе стейт и авторизационные токены. Вендор рекламы может давать гарантии, что будет использовать только подмножество этих данных, но тем не менее это очень небезопасный подход. Симо призывает очень хорошо подумать перед тем, как настраивать поддомены для сторонних сервисов.

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

#security #dns

https://www.simoahava.com/web-development/whats-in-a-cname/

На сайте Developer Apple была опубликована статья про использование одноразовых SMS-кодов, привязанных к домену, — "Enhance SMS-delivered code security with domain-bound codes".

Современные смартфоны предоставляют средства для автозаполнения поля с SMS-кодом, который отправляется пользователю при включённой двухфакторной аутентификации или подтверждения каких-либо операций. Сейчас автодополнение кодов работает на любых страницах, которые используют поле ввода с атрибутом autocomplete=one-time-code. Проблема в том, что этим могут пользоваться фишинговые сайты.

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

123456 is your Example code.

@example.com #123456

Привязанные к домену коды можно использовать в iOS 14 и macOS Big Sur. На Android эта фича скорее всего появится в одном из следующих релизов.

#security #mobile

https://developer.apple.com/news/?id=z0i801mg
https://github.com/WICG/sms-one-time-codes

В блоге Google Артур Жанк и Лукас Вайксельбаум рассказали про новые фичи безопасности web-платформы, которые были добавлены за последние несколько лет, — "Towards native security defenses for the web ecosystem".

Разработчики браузеров и авторы спецификаций работали над защитой от инъекций и улучшением изоляции между сайтами. Trusted Types и Content Security Policy (CSP) решают проблему XSS. Благодаря Trusted Types потенциально небезопасные API становятся доступны только доверенному коду. CSP предоставляет защиту от server side XSS. Для улучшения изоляции сайтов в платформу были добавлены Fetch Metadata Request Headers и Cross-Origin Opener Policy (COOP). С помощью Fetch Metada к запросам привязывается метаинформация, на основе которой сервер может отклонить запрос. Благодаря COOP добавляется уровень изоляции между сайтами, когда один сайт открывает другой сайт в новой вкладке/окне.

Очень интересная статья. Рекомендую почитать, если интересуетесь безопасностью.

#security

https://security.googleblog.com/2020/07/towards-native-security-defenses-for.html

Еиджи Китамура на web.dev рассказал о том, как упростить процесс обновления данных для аутентификации с помощью менеджеров паролей — "Help users change passwords easily by adding a well-known URL for changing passwords".

Менеджеры паролей в Safari и Chrome (с версии 86) предоставляют элемент управления для быстрого перехода к изменению пароля. Чтобы он правильно работал, на вашем сайте должен быть настроен редирект со страницы /.well-known/change-password на страницу изменения пароля. Для редиректа лучше всего использовать: 302 Found, 303 See Other или 307 Temporary Redirect.

Редирект для /.well-known/change-password уже поддержали Google, Facebook, GitHub и другие сайты. Если на вашем сайте ещё нет редиректа, то его очень рекомендуется добавить.

#web #security

https://web.dev/change-password-url/

Увидел новость, что в Chrome 85 для Android появилась поддержка DNS-over-HTTPS. Прочитал статью "A safer and more private browsing experience with Secure DNS" в блоге Chromium, чтобы разобраться в этой теме подробнее.

DNS-over-HTTPS (DoH) — это протокол для безопасного разрешения ip-адреса по названию сайта. DoH предотвращает перехват данных о посещаемых страницах третьими лицами, которые находятся в той же самой сети, что и легитимный пользователь. Эти данные могут быть использованы для фишинга и фарминга. При использовании DoH появляется дополнительный сервер, к которому подключается браузер по HTTPS для разрешения DNS-запросов. HTTPS гарантирует аутентичность, целостность и конфиденциальность DNS-трафика.

Внедрение DoH в Chromium заняло два года, так как DNS уже существует 35 лет и торопливое внедрение могло бы поломать сервисы, использующие старое поведение DNS, например, фильтрацию контента для детей. Более того в некоторых странах (насколько я помню, в Великобритании) отсутствие такой фильтрации могло бы повлечь проблемы с законом для провайдеров интернета.

В Chromium за включение DNS-over-HTTPS отвечает фича "Secure DNS". По умолчанию Chromium пробует использовать сервисы провайдера, чтобы не ломать их механизмы фильтрации, но в настройках браузера (раздел "Security") можно выбрать любого другого провайдера (есть предустановленные сервисы от Google, Quad9, CleanBrowsing, Cloudflare).

#security #chromium

https://blog.chromium.org/2020/05/a-safer-and-more-private-browsing-DoH.html

Збигнев Банах написал статью про HSTS — "Why Websites Need HTTP Strict Transport Security (HSTS)".

Как правило, пользователи при переходе на сайт вводят его имя в адресную строку без протокола. Браузеры по умолчанию переходят на сайт по незащищённому протоколу HTTP. Для того чтобы браузер всегда использовал HTTPS-протокол, сервер на первый запрос должен отправить ответ с редиректом на HTTPS-версию сайта и с помощью заголовка Strict-Transport-Security передать дополнительную информацию о том, что сайт должен работать только HTTPS и закэшировать этот ответ. Время жизни кэша обычно устанавливают на год или два. В следующий раз при посещении сайта пользователь сразу попадёт на HTTPS-версию без редиректа.

Но есть небольшая проблема. Теоретически злоумышленник может перехватить первый запрос и заблокировать работу HSTS. Чтобы этого избежать, браузеры проверяют список сайтов, которые должны работать только по HTTPS (HSTS preload list). В этот список можно добавить свой сайт, но для этого нужно выполнить все условия, например, чтобы все поддомены работали по HTTPS.

Хорошая статья. Рекомендую почитать, если хотите узнать больше про HSTS.

#http #security

https://www.netsparker.com/blog/web-security/http-strict-transport-security-hsts/

В блоге web.dev появилась статья про изменение семантики "same-site", и как это повлияет на передачу кук — "Schemeful Same-Site".

В будущем определение "same-site" будет включать в себя URL схему. То есть сайты https://example.com и http://example.com будут считаться разными, и передача кук между ними будет заблокирована для SameSite=Strict. Подробнее про SameSite можно почитать здесь.

Это изменение делается для улучшения приватности и безопасности. Какое-то время можно будет сохранить передачу кук между безопасным и небезопасным контекстом, но разработчики браузеров настоятельно рекомендуют полностью перевести сайт на HTTPS.

На данный момент отправка кук работает без изменений. Для тестирования поведения сайтов с учётом новой семантики в браузерах были добавлены экспериментальные флаги: schemeful-same-site (Chrome 86) и network.cookie.sameSite.schemeful (Firefox 79). Также в инструментах разработчика будут появляться предупреждения о проблемах с такими куками.

#security

https://web.dev/schemeful-samesite/

В блоге V8 Мартин Бидлингмайер опубликовал статью про новый вспомогательный движок регэкспов, который позволяет избежать катастрофических откатов — "An additional non-backtracking RegExp engine".

V8 по умолчанию использует регэксп-движок Irregexp, который в свою очередь использует алгоритм бэктрекинга для проверки паттернов регэкспов. Этот алгоритм может приводить к катастрофическим откатам (сatastrophic backtracking). Катастрофический откат — это ситуация, когда проверка регулярного выражения не может быть выполнена за разумное время из-за экспоненциального роста количества возможных вариантов, которые должны быть обработаны движком. Катастрофические откаты могут использоваться для совершения DOS-атак, когда web-сервис обрабатывает входные данные пользователей с помощью регулярных выражений.

В V8 версии v8.8 был добавлен новый экспериментальный движок, который не подвержен проблеме экспоненциального взрыва, но гораздо медленнее (на данный момент) Irregexp. Его можно включить с помощью экспериментальных флагов V8.

Довольно хардкорная статья. Рекомендую почитать всем, кто интересуется темой разработки браузеров и безопасностью.

#v8 #security #internals

https://v8.dev/blog/non-backtracking-regexp

Алекс Бирсан — исследователь в области информационной безопасности — опубликовал статью о том, как ему удалось получить доступ к внутренним сетям 35 организаций — "Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies".

Из публичных источников (GitHub, ресурсы сайтов и т.п.) были собраны имена приватных пакетов, которые доступны только из внутренних сетей организаций. Для этих пакетов в публичных репозиториях (npm, PyPi, RubyGems) были опубликованы одноимённые пакеты. Из-за ошибки в конфигурации некоторые билд-системы начали скачивать и устанавливать пакеты из публичного репозитория. Таким образом Алекс получил доступ к внутренним сетям Apple, Microsoft, PayPal, Uber, Yelp.

После публикации статьи Microsoft выпустила документ с рекомендациями для предотвращения подобных ошибок в npm, yarn, NuGet Gallery, Pip, Gradle и Maven Central.

Советы для npm: используйте scoped packages, настройте npm так, чтобы в приоритете был приватный реестр, не удаляйте package-lock.json и используйте npm ci для установки зависимостей.

#security #npm

https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
https://azure.microsoft.com/en-us/resources/3-ways-to-mitigate-risk-using-private-package-feeds/

Майк Уэст в блоге Chromium написал статью про средства предотвращения неявных утечек данных между сайтами в пределах одного процесса браузера — "Mitigating Side-Channel Attacks".

Браузеры полагаются на концепцию origin для предотвращения явной утечки данных между сайтами. Но существуют атаки по сторонним каналам, которые могут обойти ограничения браузера и прочитать любые пользовательские данные любых сайтов. Например, с помощью атаки Spectre можно было читать данные сайтов-соседей, которые попадали в один браузерный процесс. Для этого небезопасный сайт example.com мог добавить на страницу ресурс другого сайта ( <img src="https://email.com/user_emails.json" /> ) и получить доступ к его содержимому через единое адресное пространство памяти процесса. Чтобы предотвратить Spectre, браузеры по умолчанию отключили небезопасные API и включают их лишь только для тех сайтов, которые можно изолировать между разными процессами (Site Isolation).

Для предотвращения атак подобного типа можно использовать другие методы, даже если браузер не поддерживает Site Isolation:

— Ограничение ответов со стороны сервера на основе анализа HTTP-заголовков Sec-Fetch-*,
— Ограничение возможности загружать ресурс как подресурс (то есть как в примере с img выше) с помощью cross-origin-resource-policy (CORP),
— Предотвращение загрузки документа в iframe'ах с помощью X-Frame-Options: SAMEORIGIN и CSP-политик,
— Ограничение доступа к window opener'а с помощью Cross-Origin-Opener-Policy (COOP),
— Предотвращение атак MIME-type confusion с помощью X-Content-Type-Options: nosniff и установки корректных заголовков Content-Type.

#security

https://blog.chromium.org/2021/03/mitigating-side-channel-attacks.html

Chrome 92 будет предотвращать небезопасный доступ к сервисам локальной сети. Обо всех подробностях рассказали Эиджи Китамура и Титуан Ригоди в статье "Private Network Access (CORS-RFC1918) updates".

Сейчас сайты могут без проблем обращаться к ресурсам из локальной сети. Например, внешний сайт компании может отправлять какую-нибудь статистику в интранет-сеть для тех пользователей, у которых есть к ней доступ. Такая политика небезопасна, так как любой внешний сайт может отправить любой запрос не только к внутреннем сайтам, но и к роутеру или принтеру пользователя. Подобным образом в 2014 году были взломаны более 300 тысяч роутеров по всему миру.

Начиная с Chrome 90 браузер будет предупреждать о небезопасных запросах при обращении к ресурсам локальной сети. В Chrome 92 такие запросы перестанут работать по умолчанию. Чтобы они продолжали работать, сайт-инициатор запроса и целевой сайт должны работать по HTTPS. Также в будущем будут проверяться CORS-заголовки, разрешающие доступ к ресурсу (пока эта часть спецификации находится на стадии обсуждения).

#security #chrome

https://developer.chrome.com/blog/private-network-access-update/

Андрей Печкуров — участвует в разработке Node.js — написал статью про внутреннее устройство Math.random в V8 — "[V8 Deep Dives] Random Thoughts on Math.random()".

V8 использует генератор псевдослучайных чисел (PRNG), поставляемый окружением (Node.js, Chromium) или откатывается на системный источник случайности (например, /dev/urandom в Linux), если он не был задан в окружении. После того как генератор был проинициализирован seed-значением, все последующие случайные числа генерируются детерминировано с помощью алгоритма xorshift128+ и сохраняются в пуле из 64 значений, который заполняется по мере необходимости. Использование пула заранее сгенерированных случайных чисел очень распространённый подход, который используется при реализации PRNG.

Math.random не рекомендуется использовать для задач, связанных с безопасностью, потому что под капотом он не использует криптографически безопасный генератор псевдослучайных чисел (CSPRNG). Для таких задач вместо Math.random рекомендуется использовать генератор из Web Crypto API или модуля crypto в Node.js.

#js #v8 #internals #security

https://apechkurov.medium.com/v8-deep-dives-random-thoughts-on-math-random-fb155075e9e5

Никита Ступин из Huawei написал статью про атаку "Prototype pollution" — "JavaScript prototype pollution: практика поиска и эксплуатации".

Prototype pollution — это атака, с помощью которой изменяют прототип базовых объектов ( Object.prototype, Function.prototype, Array.prototype ) для модификации хода выполнения программы. Например, если код обращается к свойству window.foo и выполняет его содержимое с помощью eval, то в некоторых ситуациях можно добиться выполнения произвольного кода, переписав в прототипе объекта свойство foo ( Object.prototype.foo = 'alert(1)' ). Чаще всего на клиенте prototype pollution используется для реализации XSS с помощью изменения GET-параметров.

В статье очень детально разбирается механизм работы этой атаки на клиенте и сервере. Есть пример поиска и эксплуатации prototype pollution на практике и советы по защите.

Большая и интересная статья. Рекомендую почитать.

#js #security

https://habr.com/ru/company/huawei/blog/547178/

Полифил для предзагрузки JavaScript-модулей с проверкой целостности

Гай Бедфорд — автор jspm и SystemJS — рассказал о своих опытах реализации кроссбраузерной предзагрузки JavaScript-модулей с проверкой целостности — "ES Module Preloading & Integrity".

В нативной модульной системе модули загружаются после загрузки их родителей. Чтобы ускорить загрузку нижележащих модулей, можно использовать предзагрузку с помощью <link rel="modulepreload">. Ещё можно включить проверку целостности с помощью атрибута integrity. Проблема в том, что modulepreload и integrity поддерживаются только в Chrome.

Гай в своей статье предлагает использовать полифил для поддержки modulepreload и integrity во всех браузерах и рассуждает о том, как ещё может быть реализована проверка целостности JavaScript-модулей.

#esm #performance #security

https://guybedford.com/es-module-preloading-integrity

Удалённое выполнение кода в популярном npm-пакете

Тим Перри нашёл серьёзную уязвимость в npm-пакете pac-resolver (3 миллиона еженедельных загрузок) — "Proxies are complicated: RCE vulnerability in a 3 million downloads/week NPM package".

Администраторы предприятий часто используют PAC-файл для автоматической настройки HTTP-прокси в браузерах и других сетевых программах. Путь до этого файла добавляется вручную или автоматически с помощью протокола WPAD. Пакет pac-resolver упрощает работу с такими файлами в Node.js и является зависимостью proxy-agent. Proxy-agent в свою очередь используют Firebase CLI, AWS CDK и другие утилиты.

PAC — очень старый механизм, который был впервые добавлен в Netscape Navigator 2.0 в 1996-году и стал неофициальным стандартом. Содержимое PAC-файла — обычный JavaScript, который должен запускаться в изолированном контексте. Проблема в том, что pac-resolver запускал этот код с помощью модуля vm, механизм изоляции которого легко обходится, тем самым открывая вектор для удалённого выполнения кода.

Проблема была исправлена два месяца назад в pac-resolver v5.0.0. В новой версии используется пакет vm2, который был сделан специально для запуска потенциально опасного кода.

#security #nodejs

https://httptoolkit.tech/blog/npm-pac-proxy-agent-vulnerability/

Потенциальные проблемы с сертификатами Let's Encrypt

Вчера Скот Хелм написал статью о том, что 30 сентября истёк срок действия корневого сертификата IdentTrust DST Root CA X3, который используется Let's Encrypt. Из-за этого на старых устройствах перестали открываться некоторые сайты, так как сертификат Let's Encrypt используют миллионы HTTPS-сайтов. Эта ситуация возникла из-за прекращения обновления прошивок старых устройств.

IdentTrust и Let's Encrypt придумали решение, чтобы корневой сертификат оставался валидным до 2024 года для Android-устройств с версиями ОС выше 2.3.6. Пользователи Android с более старыми версиями столкнутся с проблемами.

Сертификат IdenTrust DST Root CA X3 невалиден для:
— Windows < XP SP3
— macOS < 10.12,
— iOS < 10
— Android < 7.1.1 (версии >= 2.3.6 будут работать с ISRG Root X1 cross-sign)
— OpenSSL <= 1.0.2
— Ubuntu < 16.04
— Debian < 8
— Mozilla Firefox < 50
— Java 8 < 8u141
— Java 7 < 7u151,
— NSS < 3.26
— Amazon FireOS (Silk Browser)

Если у вас или у ваших знакомых внезапно перестал открываться любимый сайт, то скорее всего причина в этом.

#announcement #security

https://scotthelme.co.uk/lets-encrypt-old-root-expiration/

Sanitizer API — безопасная работа с DOM

В блоге web.dev была опубликована статья, посвящённая Sanitizer API — "Safe DOM manipulation with the Sanitizer API".

Sanitizer API — это реализация полноценного санитайзера данных на уровне веб-платформы. Он предназначен для удаления из пользовательского ввода нежелательных HTML-тегов и аттрибутов, которые эксплуатируются в XSS. Можно сказать, что это аналог библиотеки DOMPurify, но без накладных расходов на лишний парсинг.

В Sanitizer API используется контекст парсинга. Благодаря этому структура кода всегда остаётся валидной. Например, Sanitizer API не позволит вставить внутрь <div></div> результат парсинга строки <td>lorem</td>, так как получилась бы невалидная HTML-разметка.

Поддержка Sanitizer API на данный момент есть только в Chrome и Firefox в экспериментальном режиме.

#api #security

https://web.dev/sanitizer/

CORS — история появления и нюансы использования

Джейк Арчибальд написал статью про CORS с интерактивными примерами — "How to win at CORS".

Впервые управление кроссдоменными-запросами появилось в Flash с помощью файла /crossdomain.xml, в котором описывались права доступа сторонних сайтов. В 2005 году рабочая группа W3C Voice Browser Working Group предложила альтернативное решение для XML-ресурсов. Так как XML не получил широкого распространения для представления HTML-документов, предложение рабочей группы трансформировалось в CORS (Cross-Origin Resource Sharing), который управляется с помощью HTTP-заголовка: Access-Control-Allow-Origin.

Кроме истории появления CORS в статье также рассказывается о нюансах его использования. В общем, хорошая статья. Рекомендую почитать.

#web #security #history

https://jakearchibald.com/2021/cors/

Компроментация npm-пакетов coa и rc

В четверг были скомпрометированы npm-пакеты coa и rc. На первый пакет приходится 7 миллионов загрузок в неделю, на последний — 14 миллионов.

Во взломанных пакетах был размещён Windows-троян, который воровал сохранённые пароли, данные кредитных карт и т.п.

На данный момент вредоносные версии пакетов уже удалены, но специалисты по безопасности рекомендуют на всякий случай проверить в системе наличие вредоносных файлов: compile.js, compile.bat, sdd.dll. Для предотвращения подобных инцидентов npm советует включить двухфакторную аутентификацию.

#npm #security

https://www.bleepingcomputer.com/news/security/popular-coa-npm-library-hijacked-to-steal-user-passwords/