Политика безопасности браузера
Образование | Настройки безопасности браузеров
Подпишись
на рассылку
Лучшие публикации Теплицы, доставленные на твой email
Подпишись
на Теплицу(Pro)
Не пропусти лучшие новости для экспертов в области IT, активистов, дизайнеров
Подпишись
в Фейсбуке
Не пропусти лучшие публикации Теплицы, руководства, анонсы мероприятий
Подпишись
ВКонтакте
Не пропусти лучшие публикации Теплицы, руководства, анонсы мероприятий
Подпишись
в Телеграм
Не пропусти лучшие публикации Теплицы, руководства, анонсы мероприятий
Подпишись
на YouTube
Не пропусти видео-уроки, скринкасты, записи вебинаров и мероприятий
Теплица социальных технологий
Всего материалов: 118
Настройки безопасности браузеров
Делаем Google Chrome и Mozilla Firefox безопаснее «штатными средствами». Веб-браузер – едва ли не самый распространенный рабочий инструмент. Люди листают страницы сайтов, отвечают на письма, заходят в онлайновые магазины, скачивают файлы и часто не задумываются: ведь все это время они пользуются одной и той же программой. Достаточно ли она безопасна? Хороши ли настройки по умолчанию? Может, есть смысл что-нибудь изменить?
Статья подготовлена проектом safe.rublacklist.net. На сайте Теплицы размещена по лицензии CC BY 4.0. Проект SAFE – сборник материалов по цифровой безопасности. «Роскомсвобода» рассказывает о практиках и инструментах для защиты данных и коммуникаций.
В этой статье мы поговорим о популярных кросс-платформенных браузерах Google Chrome и Mozilla Firefox.
Будем считать, что вы знакомы с браузером хотя бы в общих чертах, и обратим все внимание на специфические настройки.
Обновления
Устанавливать обновления – общее правило для всех программ, и браузеры не исключение. С помощью обновлений разработчик не только делает программу функциональнее, но и ликвидирует уязвимости и исправляет ошибки. Общая рекомендация: не препятствуйте браузеру в установке обновлений.
Начальная страница
Удобно, когда браузер при запуске показывает часто используемую веб-страницу (например, новостную ленту) или подборку недавно (часто) открытых страниц, но это не лучшая идея с точки зрения обеспечения безопасности. Не давайте браузеру запоминать эти данные, и тогда их не увидит случайный человек.
- Chrome: меню «Настройки» – раздел «При запуске открывать» – убедитесь, что выбрано значение «Новую вкладку».
- Firefox: меню «Настройки» – (слева) меню «Основные» – раздел «При запуске Firefox» – выберите «Показать пустую страницу» или «Показать домашнюю страницу» (в последнем случае убедитесь, что в поле «Домашняя страница» (чуть ниже) указано что-либо не идентифицирующее ваши интересы и дела (например, вариант по умолчанию «Начальная страница Mozilla Firefox»).
Пароли
По умолчанию в обоих браузерах включена функция сохранения паролей. Многие пользователи не обращают на это внимание, и если браузер предлагает сохранить пароль, машинально соглашаются.
Таким образом, браузер становится хранилищем самого ценного, что может быть у активного пользователя сети: паролей к разным аккаунтам. Да, в Firefox есть функция «мастер-пароль», которая позволяет с помощью одного пароля зашифровать все остальные.
Но по умолчанию она выключена, и опыт показывает, что пользуются ею нечасто. Кроме того, сохраненные в браузере пароли не будут автоматически добавлены, например, в другой браузер, которым вы пользуетесь на том же устройстве.
Советуем использовать для хранения паролей надежное зашифрованное хранилище, менеджер паролей (например, KeePassXС).
- Chrome: меню «Настройки» – (в самом низу) ссылка «Дополнительные» – раздел «Пароли и формы» – пункт «Настроить» – передвиньте первый рычажок влево (в положение «Выкл»).
- Firefox: меню «Настройки» – (слева) меню «Приватность и Защита» – раздел «Формы и пароли» – снимите галочку в поле «Запоминать логины и пароли для веб-сайтов».
Не забудьте заглянуть в список уже сохраненных паролей, и если таковые обнаружатся – перенести их в защищенную базу, а из браузеров удалить. Для Google Chrome это можно сделать в том же окне, где рычажок «Выкл» (см. выше), для Mozilla Firefox нужно нажать кнопку «Сохраненные логины».
Отслеживание
Многие веб-сайты собирают данные о вас. Они позволяют третьим сторонам отслеживать, какие сайты вы посещаете. Современные браузеры позволяют включать в запросы уведомление о том, что вы возражаете против такого отслеживания.
У каждого сайта своя политика, и нет гарантий, что ваша просьба будет исполнена «как есть», но включение этой функции может несколько уменьшить активность по сбору данных.
- Chrome: меню «Настройки» – (в самом низу) ссылка «Дополнительные» – раздел «Конфиденциальность и безопасность» – включите рыжачок в поле «Отправлять запрет на отслеживание с исходящим трафиком» и нажмите во всплывающем окне синюю кнопку «Подтвердить».
- Firefox: меню «Настройки» – пункт «Приватность и Защита» – найдите пункт «Передавать сайтам сигнал “Не отслеживать”, означающий, что вы не хотите быть отслеживаемыми» – выберите пункт «Всегда».
В Firefox можно также заблокировать т.н. трекеры, маленькие элементы, используемые веб-сайтами для отслеживания вашего поведения на страницах. Для этого в том же разделе настроек (чуть выше) в позиции «Использовать защиту от отслеживания для блокировки известных трекеров» установите значение «Всегда».
Синхронизация
Эта функция позволяет поддерживать актуальность всех ваших настроек и сохраненных данных, если вы работаете на разных устройствах. Удобно, однако из соображений безопасности мы бы советовали синхронизацию отключить. Убедиться, что синхронизация отключена, можно:
- Chrome: меню «Настройки» – в самом верху;
- Firefox: меню «Настройки» – пункт «Аккаунт Firefox».
Удаление сохраненных данных
История (журнал) посещенных страниц – удобный инструмент, в котором можно, например, найти сайт, посещенный пару дней назад. Но с точки зрения безопасности история – готовый каталог ваших предпочтений, интересов и слабостей. Это детальная коллекция следов, оставленных вами в Интернете. Если устройство попадет в руки злоумышленника, он сможет извлечь из этой коллекции ценный материал.
Помимо истории, есть немало других данных, которые сохраняет браузер.
Некоторые данные, сохраняемые браузером
- История загрузок. Какие файлы вы загружали из Интернета и куда их сохраняли.
- История поиска. Информация о ваших поисковых запросах.
- Данные форм. Информация, которую вы вводите в онлайновые формы (например, имя – при регистрации на каком-либо сайте).
- Куки-файлы (cookies). Маленькие текстовые файлы, которые браузер записывает на ваш компьютер. Могут содержать разнообразную информацию о посещенных вами сайтах.
- Кеш. Сохраненные изображения (и другие данные) с веб-сайтов.
Можно быстро очистить историю вручную, выбрав типы данных для удаления и временной промежуток (например, за час, за день и т.д.).
- Chrome: меню «Дополнительные инструменты» – пункт «Удаление данных о просмотренных страницах». Появится всплывающее окно «Очистить историю».
- Firefox: меню «Библиотека» – «Журнал» – пункт «Удалить историю». Появится всплывающее окно «Удаление недавней истории».
Для браузера Firefox, созданного «с прицелом» на приватность, доступны гибкие настройки «что и как сохранять». Вы можете увидеть их в меню «Настройки» – пункт «Приватность и Защита».
Доступны разные варианты. Если вы настроены решительно и хотите обеспечить наилучшую приватность работы в браузере, попробуйте отключить сохранение данных. Для этого в разделе «История» выберите «Не будет запоминать историю» (понадобится перезапустить браузер).
Впрочем, вы можете выбрать свою комбинацию настроек (вариант «Будет использовать ваши настройки хранения истории»), например, с очисткой истории посещенных страниц и удалением куки-файлов при закрытии браузера.
Удаление сохраненных данных (как для Chrome, так и для Firefox) возможно также с помощью специальных программ-«чистильщиков» вроде CCleaner.
Разрешения
Довольно часто веб-сайты просят разрешение, например, на доступ к данным местоположения (геонавигационные программы, туристические путеводители, интернет-магазины с доставкой товаров на дом и др.), доступ к микрофону и/или камере (чаты, мессенджеры и др.), возможность показывать вам push-уведомления (новостные сайты, развлекательные порталы и др.).
Иногда это способно принести вам пользу, иногда лишь позволяет владельцам сайтов собирать дополнительные данные о вас или надоедать вам всплывающими окошками. Можно настроить ваши предпочтения (и заодно посмотреть, каким сайтам вы уже дали разные разрешения).
- Chrome: «Настройки» – (в самом низу) ссылка «Дополнительные» – раздел «Конфиденциальность и безопасность» – пункт «Настройки контента».
- Firefox: «Настройки» – (слева) «Приватность и Защита» – раздел «Разрешения».
Приватный режим
Во время работы, не изменяя обычные настройки браузера, можно воспользоваться специальным режимом просмотра веб-сайтов, при котором браузер не будет собирать данные (куки-файлы, пароли и т.д.).
В Google Chrome это называется «режим инкогнито», в Mozilla Firefox – «приватное окно». Внешне этот режим мало чем отличается от обычного окна или вкладки.
- Chrome: «Новое окно в режиме инкогнито» (или сочетание клавиш Ctrl+Shift+N).
- Firefox: «Новое приватное окно» (или сочетание клавиш Ctrl+Shift+P).
Не забывайте, что приватный режим не влияет на сохранение загрузок и закладок.
Портативная версия
Большинство из вас наверняка пользуется обычной версией браузера, установленной в системе. Портативная версия имеет преимущества.
- Вы можете носить браузер с собой на флешке, использовать его на работе, дома, в командировке. Все ваши настройки и закладки сохранятся.
- Если вы освоите азы шифрования, то сможете хранить браузер в зашифрованном контейнере или на зашифрованном диске. Это надежно защитит упомянутые выше настройки от чужих глаз. Вы сможете перестать беспокоиться о тех данных, которые не защитить стандартными настройками браузера (например, закладки).
Портативные версии браузеров можно скачать, например, с известного сайта PortableApps:
Многие функции обеспечения безопасности отсутствуют в браузерах по умолчанию, но их можно получить с помощью дополнений/расширений. О том, как это сделать, будет рассказано в отдельной статье.
Обеспечение безопасности современными браузерами
Данная заметка посвящена вопросу работы браузеров и обеспечения ими безопасности при обработке локальных html файлов. Оказывается, сообщения “Использовать этот браузер по умолчанию?”, успевшие всем поднадоесть, являются очень полезными, так как от выбора основного браузера будет зависеть безопасность работы с локальными html страницами. Конечно, это не относится к SEO или маркетингу, тем не менее, возможно, эта информация будет вам интересна.
Основой модели обеспечения безопасности в браузерах является политика безопасности Same-Origin Policy (дословно, политика одного источника), которая защищает web-сайты друг от друга. Например, эта политика безопасности не допустит новостному сайту читать контент из вашей почты на Gmail аккаунте (даже если вы открыли оба сайта в одно и то же время). Однако, что если web-страница запущена локально с вашей файловой системы, а не из сети Интернет? Рассмотрим следующую гипотетическую атаку, если ваш браузер не ограничивает возможности локальных страниц:
- Вы получили email сообщение от злоумышленика, содержащее прикрепленную web-страницу, которую вы скачали.
- Вы можете открыть, теперь уже локально, web-страницу в вашем браузере.
- Локальная страница создает , источник которого https://mail.google.com/mail/.
- Так как вы залогинены в Gmail аккаунт, фрейм загрузит почтовые сообщения.
- Локальная страница прочитает контент фрейма, используя JavaScript код frames[0].document.documentElement.innerHTML. (Если бы вы загружали страницу из сети Интернет, то браузер не выполнил бы этот шаг, так как источником страницы не является Gmail; политика безопасности не допустит чтения).
- Локальная страница может поместить контент в элемент и послать данные с помощью POST запроса на сервер злоумышленика. Теперь у атакующего имеется информация, которая может быть полезна для спама или грабежа.
Gmail ничего не может сделать в данном случае для защиты себя от подобной атаки. Следовательно, браузеры берут на себя обязаность предотвратить такой ход событий с помощью невозможности или большой сложности выполнения описанных выше шагов. Ниже приведена политика безопасности популярных web-браузеров.
Safari 3.2
Локальные страницы Safari 3.2 имеют большие полномочия, так как они могут читать контент любого сайта (шаг №5 будет успешным). Safari защищает своих пользователей с помощью осложнения страницам из Интернет открывать локальные файлы (выполнение шага №2 становится сложным). Например, если вы кликните на гиперссылку, ведующую на локальный файл, Safari не отобразит локальную страницу. Вам надо вручную набрать урл к файлу в адресной строке браузера или же просто открыть файл.
Internet Explorer 7
IE7, также как и Safari 3.2 позволяет локальным страницам читать произвольные сайты и предотвращает клики на локальные файлы. Internet Explorer смягчает атаку путем запрета запуска с локальных страниц JavaScript кода (по умолчанию), предотвращая выполнение шага №5. Однако, он позволяет пользователям убрать это ограничение с помощью появляющегося информационного желтого блока, дающего возможность включить JavaScript или ActiveX объекты.
Opera 9.6
Opera 9.6 ограничивает возможности локальных web-страниц только на локальную файловую систему и не дает им возможности читать страницы из сети Интернет (шаг №5 не выполнится, так как источник iframe не локальный файл). Эта политика уменьшает вероятность наиболее серъезных атак, однако, позволяя локальным страницам читать данные из локальных файлов, появляется опасность при наличии в файловой системе важной информации. Например, если вы готовите налоговую декларацию, используя компьютер, ваша файловая система может содержать налоговые декларации за предыдущие годы. Злоумышленник может использовать описанную выше атаку для получения этих данных.
Firefox 3
Firefox, как и Опера, не дает локальным страницам читать страницы из сети Интернет. Также он ограничивает чтение локальных страниц только в одном каталоге или подкаталоге. Если вы смотрите, к примеру, локальную страницу из каталога “Мои загрузки”, браузер не даст прочитать файл из папки “Мои документы”. Но к сожалению, если запускаемая страница уже находится в “Мои документы”, она сможет прочитать всю информацию оттуда.
Google Chrome
Политика хрома похожа на ту, что использует браузер Опера. Google Chrome не дает пользователям кликать в Интернет-страницах ссылки на локальные файлы, а также блокирует локальные страницы от чтения произвольных сайтов. Однако этот браузер не отключает JavaScript, как Internet Explorer, для того, чтобы web разработчикам было проще работать локально (по статистике многие пользователи влючают JavaScript).
Наряду с политикой доступа также имеются другие вещи, касательно безопасности локальных web-страниц. Большинство пользователей имеют на своем компьютере несколько браузеров. Вы можете скачать страницу в Google Chrome и позже открыть её в Internet Explorer. Для обеспечения безопасности в данном случае используется так называемая web метка, прикрепляемая к скачиваемым страницам. IE обработает эту страницу, как из Интернет, позволяя запустить JavaScript, но не давая доступ на локальные файлы.
Существует множество вариантов развития событий открытия локальных страниц и на данный момент политика безопасности браузеров не может вас защитить на сто процентов от злоумышленников. Разработчики браузеров постоянно улучшают и дорабатывают привелегии, закрывая различные дыры в своих продуктах. Поэтому, работая локально с чужими html страницами, подумайте зараннее о возможных последствиях.
Управляем Internet Explorer с помощью групповой политики
Существует не менее трех независимых и иногда конфликтующих методов настройки IE с использованием групповой политики, поэтому было бы явной ошибкой утверждать, что применять эту технологию просто. Но учитывая, как важно защитить IE во многих компаниях, необходимо принять вызов и постараться найти оптимальное решение задачи. В этой статье собраны советы и оптимальные методы навигации по лабиринту управления IE с помощью групповой политики
Должен признаться, что, приступая к этой статье, я испытал соблазн написать: «Если вы хотите управлять конфигурацией браузера из групповой политики, переходите на Firefox». Как может убежденный сторонник групповой политики, такой как я, сделать подобное заявление? Очевидно, что настройка Internet Explorer (IE) с помощью групповой политики всегда отличалась излишней сложностью. .
Выбираем оружие
Как уже отмечалось, существует три основных метода управления конфигурацией IE через групповую политику.
- Параметры административных шаблонов в разделе Computer Configuration (или User Configuration)Administrative TemplatesWindows ComponentsInternet Explorer. Эти параметры представляют собой типовые блокировки, задаваемые через административные шаблоны. Назначенные таким образом параметры IE не могут быть изменены пользователем.
- User ConfigurationWindows SettingsInternet Explorer Maintenance. Это изначальный механизм для настройки IE через групповую политику. В ранних версиях механизма было много ошибок, а поведение в ходе настройки было непредсказуемым. Версия Windows 7 отличается большей надежностью.
- User ConfigurationPreferencesControl Panel SettingsInternet Settings.Метод настройки IE на основе предпочтений групповой политики ликвидирует пробел двух предшествующих методов, но не распространяется на некоторые важные области.
Поэтому в большинстве случаев решить задачу с использованием лишь одного метода не удается. Как правило, приходится использовать два, а иногда и все три метода, чтобы полностью управлять поведением IE на настольных компьютерах и серверах. В статье будут рассмотрены возможности каждого метода и некоторые особенности, о которых нужно помнить в том или ином случае. Кроме того, иногда знакомые мне специалисты применяли иные приемы в обход трех методов. Например, мне приходилось видеть, как, просто составляя сценарии для реестра, удавалось изменить базовые значения параметров IE (например, настройки прокси), не полагаясь на ненадежную политику настроек IE
Политика административных шаблонов
Параметры административных шаблонов для IE доступны в разделах Computer Configuration и User Configuration объекта групповой политики (GPO). Поэтому можно настроить их для применения ко всем пользователям данной группы компьютеров (Computer Configuration) или к особому кругу целевых пользователей (User Configuration). Назначая политики отдельным компьютерам и отдельным пользователям, избегайте конфликтов для конкретного пользователя, зарегистрированного на определенном компьютере. В случае конфликта обычно преобладают настройки отдельного компьютера, но так происходит не всегда, поэтому, если конфликт неизбежен, обязательно проверьте поведение. Я обычно определяю только параметры административных шаблонов для отдельных пользователей, особенно если предполагается одновременно использовать и две другие области политики. Эти две политики воздействуют только на отдельных пользователей, и в результате удается более аккуратно направлять политики для IE.
При переходе к новой версии IE на обновляемом компьютере обычно устанавливается новый файл шаблона ADM или ADMX. Уверен, что следующая версия IE 9 ничем не будет отличаться в этом отношении. Если установка выполняется на Windows XP или Windows Server 2003, обновленный файл со всеми необходимыми настройками и именем inetres.adm сохраняется в папке C:Windowsinf на компьютере, для которого выполняется обновление IE. Вручную скопируйте файл inetres.adm в доменный объект GPO, если требуется выполнить запуск с новыми параметрами. Известно, что в Windows Vista, Windows 7, Windows Server 2008 и Server 2008 R2 используется новый формат файла шаблона ADMX. Поэтому при установке новой версии IE обновленный файл inetres.admx сохраняется в папке C:Windowspolicydefinitions на обновленном компьютере Windows. Если в домене Active Directory (AD) размещено центральное хранилище ADMX Central Store, необходимо вручную скопировать в него файл inetres.adm, перезаписав существующую версию файла.
Преимущества административных шаблонов. Настройки административных шаблонов IE, как и других административных шаблонов, предназначены в первую очередь для того, чтобы принудительно задать поведение пользователей IE. Как правило, пользователи не могут переопределить настройки, сделанные через административные шаблоны IE (флажок затенен или отсутствует соответствующая вкладка). Например, можно скрыть вкладку Security в диалоговом окне свойств обозревателя данной области политик, и пользователь вообще не увидит этих параметров. Все настройки, с помощью которых можно отключить функции настройки IE, обычно находятся в этой области политики (экран 1).
Как настроить Content Security Policy (CSP)
Три года назад организацией Mozilla Foundation был разработан новый стандарт политики безопасности, который предотвращает XSS-атаки и другие, связанные с ним виды атак запрещая подгружать и выполнять скрипты с запрещённых ресурсов. Называется он Content Security Policy (CSP), что в переводе означает «Политика безопасности контента».
На момент написания статьи стандарт CSP находится в статусе Candidate Recommendation, что означает возможное принятие этого стандарта в будущем W3C консорциумом. На данный момент все популярные браузеры поддерживают этот стандарт.
Как отсутствие CSP может навредить сайту?
Допустим у вас есть сайт, на котором вы показываете рекламу пользователям и честно зарабатываете деньги. И всё идёт хорошо, пока к вам не начнут ходит пользователи с заражёнными браузерами. Заражённый браузер будет подменять рекламу на вашем сайте на свою и показывать её пользователю. Как следствие — пессимизация со стороны поисковиков и падение дохода. Если же вы введёте политику CSP на своём сайте, то чужая реклама уже не покажется конечному пользователю, потому что сервер с которого реклама будет пытаться загрузиться находится не в белом списке, впрочем обо всё по порядку.
Содержание Content Security Policy
По сути Content Security Policy — это заголовок, который сервер отправляет браузеру. Давайте разберём более детально из чего же он состоит.
Сейчас ещё немного теории, и потом сразу перейдём к практики, потерпите
Устанавливаем Content Security Policy на сайт
Как я уже писал выше, CSP — это обычный http заголовок, который можно наблюдать в консоли Google Chrome, наряду с остальными заголовками:
Чтобы лучше понять как работает Content Security Policy, давайте немного поэкспериментируем. Создайте файл index.php и напишите в него следующий код:
Обратите внимание, что в http заголовке я указал Content-Security-Policy-Report-Only он аналогичен Content-Security-Policy, с той лишь разницей, что не блокирует ресурсы, а только оповещает о нарушении. Крайне полезная штука при тестировании системы перед внедрением!
Давайте разберёмся, что же мы понаписали. Первым делом мы указали в http заголовке директиву default-src ‘self’ , что означает что подгружать ресурсы можно только со своего хоста. Любые инлайн скрипты и css запрещены. Ок, идём дальше и видим:
Т.е. попробуем выполнить инлайн скрипт и загрузить картинку со стороннего хоста. И посмотрим как отреагирует наш бравый защитник:
CSP отреагировал адекватно. Т.е. подгрузил картинку и выполнил инлайновый javascript, но при этом сказал нам в консоли «ата-та!», а именно: сообщил о том, что произошло два нарушения.
Теперь давайте изменим заголовок с Content-Security-Policy-Report-Only на Content-Security-Policy и посмотрим что будет:
Пендальф CSP никого не пустил.
Инлайн скрипт не был выполнен, а картинка не загрузилась. Круто, правда?
Теперь можете поэкспериментировать самостоятельно. Вам пригодятся две таблички выше в статье, в которых мы рассмотрели директивы и ключевые слова для указания хостов. Попробуйте заменить ‘self’ на http://zabolotskikh.com/ и посмотрите что произойдет — картинка сможет загрузиться, так как её сервер был указан в белом списке.
Хочу обратить ваше внимание, что хост желательно указывать с протоколом, так как в противном случае протокол будет взят из текущего хоста. Например, если вы укажите хост как zabolotskikh.com , а ваш сервер работает по протоколу https, то в белом списке окажется https://zabolotskikh.com/ .
Обработка отчётов
Вся прелесть этой политики в том, что помимо блокирования, мы также можем собирать отчёты о нарушениях! Помните в примере в http заголовке мы указали url report-uri http://localhost/csp/collector.php для сбрасывания отчётов? Как не сложно догадаться на этот url будут отправляться все отчёты о нарушениях.
Вот так выглядит отчёт о нарушении (в формате JSON):
С этим отчётом вы можете делать всё что угодно, например сохранять в базу, отправлять на почту. Я предлагаю записывать все нарушения в csv файл. Давайте сделаем это!
Создайте файл collector.php и напишите в него следующие строки:
Теперь ещё раз обновите страницу и посмотрите в директорию http://localhost/csp/. У вас должен появиться файл report.csv с двумя строчками кода:
Ура! Мы поймали отчёт о нарушениях и записали его в файл. Можете показать этот файл друзьям А лучше всего начните внедрять CSP на свой сайт, сначала в режиме тестирования, а потом в «боевом» виде. На этапе тестирования отчёт поможет вам анализировать какие директивы реагируют на нарушения и соответствующим образом настраивать их.
Полезные материалы по Content Security Policy
- http://w3c.github.io/webappsec-csp/ — спецификация стандарта.
- https://mathiasbynens.be/notes/csp-reports — интересная статья на английском про CSP.
- https://github.com/immrr/csp-report — скрипт для обработки отчётов о нарушениях и записи их в базу.
- http://www.cspplayground.com/csp_validator — валидатор CSP http заголовка! Очень полезная штуковина, вы можете проверить свой заголовок на корректность, согласно спецификациям стандарта.
Здравствуй дорогой читатель! Я рад приветствовать тебя на страницах моего блога. Уже несколько лет я занимаюсь веб-программированием и рад поделиться с тобой своими знаниями и советами. Если тебе понравились мои статьи, ты можешь подписаться на рассылку блога, из неё ты узнаешь много интересного!
А можно подробней, что куда писать в wordpress?
Годовая
подписка
на
Хакер
Xakep #251. Укрепляем VeraCrypt
Xakep #250. Погружение в AD
Xakep #248. Checkm8
Xakep #247. Мобильная антислежка
Content Security Policy — опасная политика
Обзор нового веб-стандарта и его фундаментальных уязвимостей
Чтобы идти в ногу со временем, браузеры внедряют все новые технологии для обеспечения безопасности пользователей. Одна из них — Content Security Policy, позволяющая разработчикам сайтов четко объяснить браузеру, на какие адреса тот может выполнять межсайтовые запросы. Однако новый веб-стандарт страдает от существенных недостатков, ставящих под сомнение его пригодность как защиты от XSS.
Content Security Policy vs Same Origin Policy
Одним из главных принципов безопасности браузеров и веба в целом является Same Origin Policy — дословно «политика единого источника» (устоявшегося термина до сих пор не существует). Ее суть заключается в проверке трех компонентов, из которых состоит origin: протокол, хост и порт. Если страница http://test1.ru/a.html пытается получить доступ к DOM страницы http://test2.ru/b.html, то у нее ничего не выйдет, так как хосты отличаются. Если бы SOP не существовал, любой сайт мог бы делать запросы на произвольные адреса и получать оттуда данные, что, как подсказывает логика, не есть хорошо. Причем страдали бы все: как пользователи, чьи персональные данные летали бы без принуждения, так и владельцы ресурсов, — в общем, в вебах творился бы полный хаос. Поэтому Same Origin Policy всех спасает и все счастливы. Однако есть одно но: что, если на страницу http://test1.ru/a.html внедрен злой скрипт с сайта http://test2.ru/, который делает плохие штуки в контексте браузера жертвы? В данном случае SOP бесполезен, ибо на
Очевидно, что такой подход не поможет защититься от случаев, когда у атакующего есть возможность внедрить код в скрипт с валидным токеном. Кроме того, есть масса вариантов обхода, о чем пойдет речь ниже.
CRLF Injection
При наличии CRLF-инъекции в заголовках ответа, то есть отсутствии фильтрации символа переноса строки, у атакующего есть возможность банального обхода CSP с помощью внедрения собственных директив. Здесь большую роль играет то, какой заголовок браузер будет использовать при наличии нескольких с одинаковым именем. Как в случае с HTTP Parameter Pollution, где одинаковые имена параметров обрабатываются по-разному на разных платформах, при внедрении еще одного заголовка Content-Security-Policy важно, где он окажется — перед первоначальным или после него, так как один браузер может взять последний заголовок, а другой — первый. Так, если браузер отдает приоритет первому и мы внедряем наш CSP перед настоящим, то обход тривиален:
Если же используется последний встреченный заголовок, то мы можем отправить его в тело страницы, отправив rnrn:
На выходе получим:
Таким образом, первоначальный заголовок попадет в содержание HTTP-ответа и не будет иметь силы.
Scriptless Attacks
Перейдем к более интересным вариантам обхода — на стороне клиента. Основная цель межсайтового скриптинга — получить некую приватную информацию пользователя, которая обычно хранится в cookie. Однако с введением таких мер защиты, как флаг httpOnly, запрещающий JS-скриптам доступ к защищаемым cookie, внедрением в браузеры XSS-фильтров (XSS Auditor в Chrome, XSSFilter в IE), собственно и самого CSP, исследователи безопасности все чаще обращают внимание на другие цели, например личные данные, различного рода токены (CSRF, oAuth, в скором будущем и script-nonce). При этом используются новые способы отправки данных на сторонние сайты, без JavaScript!
CSSAR
Еще в 2008 году Эдуардо Вела (Eduardo Vela), Дэвид Линдсей (David Lindsay) и Гарет Хейс (Gareth Heyes) представили технику чтения атрибутов тегов с помощью CSS-селекторов. На данный момент техника все так же актуальна. Если раньше она позиционировалась как обход NoScript, то сейчас ее можно использовать и для CSP. Суть CSSAR (CSS Attribute Reading) в брутфорсе значений с помощью селекторов атрибутов. Для этого на уязвимую страницу подключается CSS-файл с комбинациями выражений:
Если значение целевого инпута начинается с «a», то будет отправлен запрос на сайт атакующего через подгрузку фонового изображения, относящегося к соответствующей комбинации символов. CSS не имеет возможности указать позицию символа, поэтому для получения следующего знака необходимо сгенерировать массу вариантов вида
Поэтому конечный PoC может иметь объем в несколько сотен килобайтов.
CSSAR в действии
Вариант обхода № 4. Postcards from post-XSS world
Интересные идеи предложил Михал Залевски (Michal Zalewski). Например, имея внедрение кода перед формой, защищенной CSRF-токеном, можно вставить незакрытый тег img:
Все содержание страницы до следующей закрывающей кавычки, включая и целевой токен, после незакрытого атрибута src будет отправлено на сайт атакующего.
Другой вектор — использование тега , который работает как CDATA в XML. Внутри textarea допускаются любые символы, однако в отличие от предыдущего способа отправить полное содержание страницы можно только при участии пользователя, который должен самостоятельно отправить форму.
Еще один способ использует тот факт, что формы не могут быть вложенными, поэтому внедрение незакрытого тега
Аналогичного результата можно достичь при помощи вектора с использованием тега , который определяет URL для всех относительных путей на странице. Согласно стандарту, тег должен быть включен внутри , однако большинство браузеров допускают использование тега в любом месте:
Вариант обхода № 5. SVG-кейлоггер
Не менее интересные способы отправки личных данных на сторонние сайты в обход CSP можно встретить в исследованиях Марио Хайдериха (Mario Heiderich). Один из них играет роль настоящего кейлоггера при помощи тегов и . Официальная и документированная W3C-фича accessKey внутри позволяет привязать нажатия клавиш к инициированию HTTP-запросов — идеально для реализации кейлоггера, причем без использования JS! Внедрив следующий код на страницу с формой авторизации, можно перехватить нажатия клавиш пользователя и, соответственно, его логин и пароль:
Кейлоггер без строчки JS
Вариант обхода № 6. Чтение атрибутов с помощью… скроллбаров
Пожалуй, самая интересная scriptless-атака в обход CSP — чтение атрибутов с помощью CSS, SVG и скроллбаров в WebKit от того же Марио Хайдериха. Один из принципов атаки аналогичен CSSAR — с помощью CSS-селекторов содержание атрибута можно выразить через DOM, но уже селектором :after c CSS-выражением вида content: attr(href) (для ссылок). Дальше интересней — для каждого такого элемента с содержанием атрибута можно присвоить SVG-шрифт. В шрифте имеется лишь один символ, таким образом, остальные символы в целевом атрибуте не будут иметь физического размера на странице. Если «сжать» значение, то с помощью скроллбаров можно выяснить, какой символ содержится в значении, используя специальный селектор для указания фонового изображения при появлении скроллбара:
Техника позволяет извлекать CSRF-токены за меньшее количество запросов и с помощью меньшего по размеру эксплойта, нежели CSSAR. Демо смотри здесь.
Content Security Policy — большой шаг в сторону более безопасного веба. В перспективе веб-стандарт может серьезно повлиять на клиент-сайд атаки как класс. Если сейчас на большинстве уязвимых к XSS сайтам угнать куки можно обычными JS-векторами, то в будущем с распространением CSP в массы все будет не так просто. А это подтолкнет исследователей безопасности к еще более изощренным техникам, нацеленным на уязвимости в особенностях реализации CSP в конкретных браузерах.