Симо Ахава написал статью про потенциальные опасности, которые могут возникнуть при добавлении выделенного поддомена для рекламных сетей — "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