Андрей Печкуров — участвует в разработке 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 (обсуждение статьи)