Еиджи Китамура на 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/

Утечка исходных кодов из source maps (сорс мапов)

Попалась на глаза статья про потенциальные проблемы сорс мапов — "Source-maps could be revealing your private project files".

Сорс мапы — это служебные файлы, содержащие исходный проекта. Они используются для облегчения отладки транспилированного кода. Если сорс мапы доступны в проде, то любой человек может посмотреть исходный код проекта. Для бизнеса это может быть большой проблемой.

В общем, статья про довольно известные вещи. Я бы не стал про неё писать, если бы не вспомнил про ещё одну статью — "Топ тупых лазеек для исследования конкурентов: source map". В этой статье автор рассказывает про доступ к исходным кодам фронтенда Яндекс.Еды с помощью сорс мапов. Также он настроил переодическую автоматическую выгрузку кода в GitHub, чтобы следить за процессом разработки фронта.

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

#js #security

https://levelup.gitconnected.com/automatically-generated-source-maps-could-be-revealing-your-private-projects-files-17b2d13d7da4
https://teletype.in/@opendevcast/SyYaunCHB

Ускорение установки HTTPS-соединений

Саймон Харн рассказал о том, как HTTPS-сертификаты влияют на производительность сайта — "The Performance Cost of EV Certificates".

Есть три основных типа HTPS-сертификатов: Domain Validation (DV), Organisation Validation (OV), Extended Validation (EV). DV-сертификаты выдаются на основе факта принадлежности домена, как в Let's Encrypt. OV- и EV-сертификаты выдаются организациям за оплату.

EV-сертификат предоставляет большее количество информации для пользователя, но по-большому счёту он не сильно отличается от OV. Вы могли видеть, что сайт использует EV-сертификат, когда в адресной строке рядом с иконкой замка зелёным текстом отображался владелец сертификата. С версии Chrome 77 такие сертификаты отображаются обычным значком замка без зелёного текста.

OV-сертификаты валидируются на стороне веб-сервера отправкой запроса на сервер организации, выдавшей сертификат. EV-сертификаты не могут валидироваться на стороне веб-сервера, поэтому их валидация происходит на клиенте, замедляя установку HTTPS-соединения. Задержка наиболее заметна в странах бывшего СССР, в Восточной Австралии, Канаде и большинстве стран Африки. Некоторые организации сталкивались с минутной задержкой для пользователей в Китае. Эта проблема решается переходом на OV-сертификат.

#http #performance #security

https://simonhearne.com/2020/drop-ev-certs/

Изоляция сайтов в Firefox 94

Анна Гахокидзе из команды разработчиков Firefox рассказала про улучшение безопасности браузера с помощью изоляции сайтов — "Introducing Firefox’s new Site Isolation Security Architecture".

Старая архитектура Firefox для рендеринга контента сайтов использовала непривелигированные процессы. Эти процессы ограничены в выполнении операций, например, им запрещено записывать файлы на диск. Однако несколько сайтов могли быть соседями в рамках одного процесса, и зловредный сайт потенциально мог прочитать память другого сайта.

После обнаружения атак Meltdown и Spectre, которые эксплуатируют CPU для доступа к памяти сайтов-соседей, разработчики Firefox приступили к работе над новой архитектурой (проект Fission). В этой архитектуре все сайты находятся в независимых процессах. Изоляция сайтов позволяет решить проблему утечки данных через разделяемую память на системном уровне. Также изоляция улучшает стабильность браузера — критические ошибки не выходят за рамки выделенного процесса и не затрагивает сайты в соседних вкладках.

Переход на новую архитектуру с полноценной изоляцией сайтов был завершён в Firefox 94.

#firefox #security

https://hacks.mozilla.org/2021/05/introducing-firefox-new-site-isolation-security-architecture/

Как подписать JSON

Раскопал в закладках статью Лауренса Вон Хоутвена про проблему криптографической подписи JSON — "How (not) to sign a JSON object".

Задача заключается в следующем. Есть некий JSON, необходимо гарантировать его подлинность.

Самый надёжный способ — сериализация объекта и получение для него подписи (tag) с помощью симметричного шифра. Затем полученная подпись отправляется на сервер вместе с данными в формате tag,json.

Если нужно добавить подпись внутрь передаваемого JSON, то появляется проблема с UTF. Например в python благодаря UTF можно сконструировать побайтово отличающиеся объекты, но идентичные друг другу при их сравнении с помощью ==. Это потенциальная брешь в безопасности. Для решения проблемы можно отправлять сериализовнную строку вместе с данными, использовать строковую замену или использовать альтернативный формат с автоматической канонизацией UTF. Тем не менее всё это можно легко запороть, что подтверждается неудачными реализациями подписей у AWS и Flickr.

В конце статьи автор предлагает использовать TLS для передачи данных или рассмотреть вариант отказа от подписи в пользу других решений.

#security

https://latacora.micro.blog/2019/07/24/how-not-to.html
https://news.ycombinator.com/item?id=20516489 (обсуждение статьи)