Xiva daria https что это

xiva daria https что это

Как мы сделали чтение писем безопаснее: Content Security Policy в Яндекс.Почте

Одним из приоритетов для команды Яндекс.Почты всегда была и есть безопасность данных пользователя. Причем это касается не только хранения писем, но и безопасного доступа к ним. Еще в 2011 году мы стали пропускать все изображения в письмах через наши прокси-сервера, перекрыв один из каналов распространения вредоносного кода, а также кешировать их для экономии трафика и обеспечения большей приватности. В ноябре этого года мы внедрили шифрование при приеме и отправке почты, а также и перевели почту в режим HTTPS-only — теперь веб-интерфейс доступен только по безопасному протоколу.

А с недавних пор мы стали поддерживать новый механизм защиты данных пользователя – стандарт Content Security Policy. С его помощью можно запретить скриптам на странице подгружать какие-либо ресурсы с хостов, не указанных в белом списке.

Это пока довольно редкая штука (ни одна крупная известная нам почта этого ещё не применяет), и в этом посте мы поделимся опытом внедрения стандарта.

Content Security Policy (CSP) — новый стандарт, определяющий HTTP-заголовки Content-Security-Policy и Content-Security-Policy-Report-Only, которые сообщают браузеру белый список хостов, с которых он может загружать различные ресурсы.
Текущий статус стандарта — Candidate Recommendation.

Из чего состоит CSP?

Некоторые браузеры также указывают в отчете ссылку и строку JS, которые привели к нарушению политики безопасности.

Если указан заголовок Content-Security-Policy, то браузер блокирует все ресурсы, которые не соответствуют политике. Заголовок Content-Security-Policy-Report-Only также проверяет все ресурсы, но не блокирует их, а только сообщает о нарушениях. Мы рекомендуем его использовать на первых этапах внедрения CSP.

Как мы внедряли

Мы исследовали эту технологию с весны, когда еще не было ни одной стандартной реализации. Сначала аккуратно внедрили заголовок Content-Security-Policy-Report-Only для нашей внутренней почты. Некоторые время мы изучали отчеты и исправляли нашу политику, и уже в мае включили CSP в блокирующем режиме. Во время внутреннего тестирования исследовалось поведение всех заголовков — и стандартных, и нет.

С публичной почтой было несколько труднее, ведь к нам приходили пользователи с неконтролируемым окружением. Несколько месяцев мы разбирались в отчетах, исправляли политики, и, наконец, осенью выкатили их на 100% в блокирующем режиме.

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

Разберем заголовок на примере мобильной Яндекс.Почты

Что нужно учитывать при внедрении

Xiva daria https что это

> Когда захожу в любой браузер в сетевых активностях появляется следующее:
> browser.exe 1212 is-radar10.common.radar.imgsmail.ru
> browser.exe 3480 bar.love.mail.ru

Почему ты считаешь, что это проблема, или что-то неправильно работает?
Показать полностью.

> сетевая активность просто бешеная

Что это означает? Что в твоём понимании «бешеная активность»? Цифры и доказательства, пожалуйста.

Что такое на картинке и зачем?

> Так же подключаются и эти сайты (смотрите на фото)

Хочешь сказать, что оно само, и ты на эти сайты не заходил?

> это пустой сайт
И ШТО #ЛЯДЬ.

> У тебя трафик в пустой сайт идет
Какие твои доказательства? Если там не отдаётся HTML страница с контентом, это ещё не означает что соединение ненужное (не означает, что оно ничего не делает)

У меня Яндекс Браузер закладки из другого браузера импортнул, хотя я вроде просил «Алису» этого не делать. Естественно, браузер сразу полез туда что-то качать. Фавиконки, например. Должны же быть фавиконки у закладок?

Впрочем, я не проверял, что именно он качает. Впрочем, ТЫ ТОЖЕ НИЧЕГО НЕ ПРОВЕРЯЕШЬ, а просто делаешь предположения и далеко идущие выводы ИЗ ПРЕДПОЛОЖЕНИЙ.
Показать полностью.

Если ты подозреваешь заражение своего компа вирусами, то:
1) Скачай DrWeb CureIt
2) Перезагрузись в безопасный режим Windows
3) Запусти проверку
Вангую, что ничего не найдётся.

Ещё проверь настройки роутера, какой DNS сервер выдаётся по DHCP компьютеру. Естественно, должен выдаваться либо DNS сервер провайдера, либо какой-то широко известный DNS сервер (который ты сам же и настроил, да).

Если ты думаешь, что данные сетевые соединение являются вредоносными, то ТЫ ВООБЩЕ-ТО ЭТОГО НЕ ПРОВЕРЯЛ. Расчехли Fiddler или Charles Proxy и провер. Раз ты такой крутой хаккер с паранойей, то думаю ты разберёшься, как проверить содержимое запросов и ответов.

Xiva daria https что это

Сообщения: 2842
Благодарности: 468

Скачать и запустить утилиту autoruns, дождаться пока закончится скан, вверху в фильтре написать AP_Mgr.exe, удалить (ну или поснимать галочки) всё что появится в списке. Аналогично с остальными заведомо-вредными процессами.

Сообщения: 2842
Благодарности: 468

При загрузке любого браузера или почтовой программы выскакивает сообщение о подключении с сайтом xiva-daria.mail.yandex.ru.

покажи. А то я не совсем понимаю что за сообщение и где оно «выскакивает».

Xiva daria https что это

Сообщения: 2842
Благодарности: 468

Скачать и запустить утилиту autoruns, дождаться пока закончится скан, вверху в фильтре написать AP_Mgr.exe, удалить (ну или поснимать галочки) всё что появится в списке. Аналогично с остальными заведомо-вредными процессами.

Сообщения: 2842
Благодарности: 468

При загрузке любого браузера или почтовой программы выскакивает сообщение о подключении с сайтом xiva-daria.mail.yandex.ru.

покажи. А то я не совсем понимаю что за сообщение и где оно «выскакивает».

Главный баг открытых проектов Яндекса

Идеология разработки с открытыми исходниками предполагает также и открытый процесс разработки. Следуя этому духу мы сегодня решили открыто исправить серьёзный баг, которому в той или иной степени подвержены почти все open source проекты Яндекса.

ID	1
Summary	Никто не знает про открытые проекты Яндекса
Description	У наших разработчиков уже довольно много опубликованных компонентов, библиотек и готовых решений. Их никто особенно не скрывает, но также про них никто и не рассказывает. Надо рассказать!

» PIRE https://github.com/dprokoptsev/pire

Perl Incompatible Regular Expressions library родилась в недрах разработки поискового робота, где специфика задач позволяет отказаться от поддержки эзотерических возможностей стандартных перловых регулярок, и за счёт этого существенно повысить скорость обработки. В поисковом роботе не бывает, чтобы что-то работало слишком быстро. Вот небольшая выдержка из тестов производительности, которые использовались также в известной статье «Regular Expression Matching in the Wild»:

Файл 500 МБ, регулярка: .*$
pcre	31,67 МБ/сек
re2	242,28 МБ/сек
pire	756,32 МБ/сек
Файл 500 МБ, регулярка: ABCDEFGHIJKLMNOPQRSTUVWXYZ$
pcre	153,67 МБ/сек
re2	653,76 МБ/сек
pire	755,98 МБ/сек
Файл 2 МБ, регулярка: (\d -|\(\d \)\s+)(\d -\d )$
re2	423,76 МБ/сек
pire	775,89 МБ/сек

Особенно ценная черта PIRE — это способность работать также и с очень длинными регулярками, и это очень мало сказывается на производительности.

Xiva — это асинхронный HTTP-сервер для реализации серверной части протокола WebSocket из HTML5. Он не является сервером общего назначения (например, не умеет обрабатывать POST-запросы), за счёт чего получился компактным и быстрым. Он идеально подходит для веб-чатов, live-виджетов и других похожих задач, где надо, чтобы на веб-странице что-то обновлялось по сигналу с сервера. Есть пример реализации серверной части простого веб-чата на Питоне.

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

Об NwSMTP можно думать как о «Nginx для SMTP». Это прокси-сервер, который работает перед основным почтовым сервером и может обеспечивать например поддержку SSL, фильтрацию по RBL, антиспам и антивирусную проверки. Именно он работает сейчас на нашей Почте.

Документация к нему предлагается в духе unix-традиций в виде откомментированного конфиг-файла. Обратите внимание, что проверку на спам через яндексовую Спамооборону доступна «из коробки».

Это, конечно, не все открытые проекты Яндекса. Мы потихоньку будем собирать информацию о них в едином месте. Пока же можно, например, следить на Github за списком проектов пользователя yandex-opensource.

Как мы сделали чтение писем безопаснее: Content Security Policy в Яндекс.Почте

А с недавних пор мы стали поддерживать новый механизм защиты данных пользователя – стандарт Content Security Policy. С его помощью можно запретить скриптам на странице подгружать какие-либо ресурсы с хостов, не указанных в белом списке. В этом посте мы поделимся опытом внедрения стандарта.

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

• валидация пользовательского ввода и Web Application Firewall (WAF);
• экранирование спецсимволов;
• защита кук с помощью HttpOnly, чтобы их нельзя было прочитать из JavaScript;
• различные плагины для браузера, например, noscript.

Теперь появился еще один механизм защиты от такого рода атак — Content Security Policy

Content Security Policy (CSP) — новый стандарт, определяющий HTTP-заголовки Content-Security-Policy и Content-Security-Policy-Report-Only, которые сообщают браузеру белый список хостов, с которых он может загружать различные ресурсы.
Текущий статус стандарта — Candidate Recommendation.

На сегодняшний день его поддерживают все популярные браузеры:

• Chrome 25+, Firefox 23+, Opera 15+ и Яндекс.Браузер имеют полную поддержку и понимают стандартный заголовок;
• Firefox 4-22, IE 10+ поддерживают нестандартный заголовок X-Content-Security-Policy и имеют частичную поддержку стандартного;
• Chrome 14-24, Safari 5-7 поддерживают нестандартный заголовок X-Webkit-CSP и имеют частичную поддержку стандартного.

Для ознакомления можно почитать на HTML5 Rocks статью Майка Уэста (Mike West) — одного из разработчиков стандарта. Хорошее описание стандарта есть на MDN.

Из чего состоит CSP?

Заголовок CSP состоит из набора разделенных директив — частей политики, контролирующих определенные ресурсы браузера.

• В текущей версии стандарта доступен следующий набор директив:
• default-src указывает список хостов, которые по умолчанию присваиваются неуказанным директивам.
• script-srс, style-src, object-src (для плагинов вроде Flash), img-src, media-src (audio и video), frame-src (iframe), font-src, connect-src (XMLHttpRequest, WebSocket, EventSource) — более узкие директивы, контролирующие соответствующие ресурсы браузера. Для каждой директивы надо указать список хостов (не урлов), с которыми может общаться браузер. Можно использовать *.
• report-uri — указывает URL, на который будут отправляться JSON-отчеты о нарушениях. Вот так он выглядит:

Некоторые браузеры также указывают в отчете ссылку и строку JS, которые привели к нарушению политики безопасности.

Кроме того, в директивах можно использовать не хосты, а ключевые слова (обязательно в кавычках):

• ‘self’ — соответствует текущему хосту, протоколу и порту.
• ‘none’ — все запрещено.
• ‘unsafe-inline’ — используется в script-src и разрешает <script> , javascript: и инлайн-обработчики событий (onclick=""). Для style-src разрешает использование тега <style> и атрибута style="". По возможности старайтесь не указывать это ключевое слово, т.к. это напрямую разрешает исполнять любой инлайн javascript на странице, что может приводить к XSS.
• ‘unsafe-eval’ — используется в script-src и разрешает любую кодогенерацию: eval, new Function, setTimeout(‘ var foo = «bar» ‘, 1).

Хосты можно указывать как просто "yandex.st" , так и с протоколом или портом "https://yandex.st:443" . Помните, что если у хоста не указан протокол или порт, то он берется из текущей страницы, по аналогии с same origin policy. Таким образом, хост "yandex.st" на странице "https://mail.yandex.ru:443/neo2/" автоматически приобретет вид "https://yandex.st:443" .

Если указан заголовок Content-Security-Policy, то браузер блокирует все ресурсы, которые не соответствуют политике. Заголовок Content-Security-Policy-Report-Only также проверяет все ресурсы, но не блокирует их, а только сообщает о нарушениях. Мы рекомендуем его использовать на первых этапах внедрения CSP.

Как мы внедряли

Мы исследовали эту технологию с весны, когда еще не было ни одной стандартной реализации. Сначала аккуратно внедрили заголовок Content-Security-Policy-Report-Only для нашей внутренней почты. Некоторые время мы изучали отчеты и исправляли нашу политику, и уже в мае включили CSP в блокирующем режиме. Во время внутреннего тестирования исследовалось поведение всех заголовков — и стандартных, и нет.

С публичной почтой было несколько труднее, ведь к нам приходили пользователи с неконтролируемым окружением. Несколько месяцев мы разбирались в отчетах, исправляли политики, и, наконец, осенью выкатили их на 100% в блокирующем режиме.

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

Кроме того, в процессе внедрения мы разработали инструменты для работы с CSP:

для браузеров, основанных на Chromium, позволяющее добавлять заголовки на страницу и тестировать политики. для разбора отчетов браузеров, чтобы проще получать список блокируемых ресурсов.

Разберем заголовок на примере мобильной Яндекс.Почты

Примерный план внедрения CSP на сервисе выглядит следующим образом:

1. Оценка списка загружаемых ресурсов.
2. Внедрение заголовка Content-Security-Policy-Report-Only.
3. Анализ логов.
4. Исправление политики.
5. Внедрение заголовка Content-Security-Policy (переход в режим блокировки).
6. Счастье пользователей ��

Что нужно учитывать при внедрении

• Safari 5 и AndroidBrowser с заголовком X-Webkit-CSP имеют очень плохую реализацию стандарта. И мы советуем вам вообще не использовать CSP для этих браузеров. Например, они плохо понимают правила unsafe-eval и unsafe-inline.
• Firefox в X-Content-Security-Policy реализует немного нестандартные директивы. Вместо connect-src нужно писать xhr-src (или можно добавить правила в default-src). Кроме того, он не понимает unsafe-inline, unsafe-eval, вместо них надо дописывать директиву «options inline-script eval-script». Подробнее про собственную реализацию заголовка можно почитать на вики Mozilla.
• У Firefox и X-Content-Security-Policy есть проблемы с report-ui.
• Safari в iOS6 шлет очень неинформативные отчеты.

Мы не рекомендуем использовать нестандартные заголовки. Последние версии современных браузеров (за исключением IE) поддерживают стандартный заголовок, поэтому, используя только его, вы покрываете подавляющую часть аудитории.

Особенности CSP, о которых нужно всегда помнить:

• Если вы используете inline-картинки, то в img-src нужно разрешить протокол «data:».
• Используя Blob, указывайте ‘self’ (для Chrome) и blob: (для Firefox и X-WebKit-CSP)
• CSP верхнего документа не распространяется на дочерние iframe за исключением about:blank.
• Если вы не хотите блокировать расширения хрома, которые, кстати, с последних версий тоже живут по CSP, то надо разрешить протокол «chrome-extension:»
• default-src распространяется на все неуказанные директивы, но если вы захотите что-то добавить или удалить, то придется указывать все домены заново.
• Можно одновременно указывать Content-Security-Policy и Content-Security-Policy-Report-Only. Оба заголовка будут работать независимо. Такой подход будет полезен для тестирования новых политик.
• Если вы используете фреймворки с feature detection (например, jQuery < 1.8 или Modernizr), то для style-src надо указать ‘unsafe-inline’.

Естественно, это не всегда возможно, но старайтесь не использовать *, а указывайте точный список доменов. Также указывайте все директивы, иначе все ошибки будут сыпаться как нарушение в default-src. Конечно, размер заголовка увеличиться, зато найти проблемы будет намного проще.

К сожалению, нам пока не удалось отказаться от unsafe-inline. Инлайн-скрипты в почте используются для двух вещей: выдача настроек и проверка загрузки критичных JS (jQuery и загрузчика). И если настройки мы могли переделать на JSON, то отказаться от важных отчетов незазгрузки JS мы не смогли, и пришлось оставить ‘unsafe-inline’. Также проблем добавило активное использование инлайн-атрибутов в WYSWYG-редакторе TinyMCE.

Хоть такое правило и позволяет исполнять любой инлайн javascript на странице, мы можем обезопасить себя тем, что разрешаем соединение только с проверенными ресурсами.

Обновленный стандарт CSP 1.1

Новая версия стандарта на текущий момент находится в стадии черновика, но Chrome и Firefox уже начинают внедрять новые возможности из него.

Например, новая директива nonce может стать решением неудобства с полным запретом unsafe-inline. Схема работы пока находится в стадии разработки, но мы прикладываем усилия, чтобы он работал следующим образом:

1. nonce — случайная последовательность символов передаваемых в заголовке;
2. если есть unsafe-inline и nonce, то nonce выключает unsafe-inline;
3. выполняются только те инлайн-скрипты, которые подписаны атрибутом nonce с той же последовательностью символов.

Также CSP 1.1 добавляет новые возможности:

• указание политики через метатег;
• JavaScript-API для получения и проверки политик;
• DOM-событие о нарушении политики;
• новые директивы form-action, plugin-types.

В заключение

CSP оказался не только защитой от атак и блокированием непонятных запросов. В тестировании нас приятно удивили две вещи:

1. По сути CSP дает возможность сделать из компьютеров пользователей распределенную систему тестирования безопасности. И если резко увеличивается количество отчетов о нарушениях, это повод пойти искать проблему.
2. Так как все пользователи почты работают по HTTPS, CSP дал возможность отследить и исправить те укромные места, в которых запросы все еще шли по HTTP.

Пробуйте CSP, внедряйте, защищайте личные данные пользователей и просто делайте мир лучше.

Xiva daria https что это

Авторизуясь в LiveJournal с помощью стороннего сервиса вы принимаете условия Пользовательского соглашения LiveJournal

От меня чего-то хочет антивирус:

«Приложение, установленное на локальной компьютере, пытается установить связь с удаленным компьютером. Разрешить?»
Приложение: Plugin Container for Firefox
Источник Mozilla Corporation
Удаленный компьюте (тут каждый раз разные адреса) чаще всего какая-то xiva-daria.mail.yandex.net
Удаленный порт:

Внизу два окошка для постановки галочек:
Запомнить действие (создать правило)
Временно запомнить действие для процесса

В самом низу две кнопки: Разрешить и Запретить
Нажимаю на запретить – табличка продолжает вылетать.