Security for all - #18 - 2 августа 2018

Content Security Policy - CSP

Сегодня

Новая уязвимость в протоколе Bluetooth; Исправлены уязвимости в Apache Tomcat; Google запускает U2F ключи собственного производства; Борьба с криптомайнерами в Google Play Store.

Основная тема - Content Security Policy или по-русски Правило ограничения домена.

Работа над ошибками

Сегодня мне придется отступить немного от традиций и начать с работы над ошибками :) В прошлом выпуске, рассказывая про опцию “не отслеживать”, я сказал, что при включении данной опции браузер будет посылать куку DNT. На самом деле DNT будет посылаться как заголовок.

Вспомогательные темы

CMS - Content Management System - система управления содержимым или контентом. Как понятно из названия, используется для совместного редактирования. В контексте интернета используется для удобного редактирования сайтов.

Origin или источник. Под этим термином в контексте веб приложений понимается тройка значений источника данных:

Хеш функция - функция преобразующая входные данные произвольной длинны к значению фиксированного размера. Криптографически стойкая функция должна быть необратимой и стойкой к коллизиям.

Bluetooth Special Interest Group (SIG) - организация, которая заведует разработкой стандартов Bluetooth и лицензированием устройств на соответствие этим стандартам.

AOSP или Android Open Source Project - открытая часть операционной системы Android от Google. Большинство производителей дорабатывают ее под свое железо. Также в открытой части отсутствуют многие закрытые драйверы для различных устройств. Поэтому большинство Android устройств, включая устройства самой Google, используют комбинацию ПО с открытым и закрытым исходным кодом.

CWE - Common Weaknes Enumeration - система категорирования недостатков и уязвимостей в программном обеспечении. В отличие от CVE (Common Vulnerabilities and Exposures), который описывает конкретные уязвимости в конкретных продуктах, каталог CWE содержит обобщенное описание возможных проблем, которые могут встретиться в любом программном обеспечении.

Новости

Новая уязвимость в протоколе Bluetooth

Лиор Неуманн (Lior Neumann) и Илай Бахам (Eli Biham) из Израильского технологического института Технион (Techion Israel Institute of Technology) обнаружили уязвимость в некоторых реализациях прошивок Bluetooth устройств и драйверов операционных систем. Если коротко, то в некоторых реализация недостаточно или вовсе не проверяются параметры, с использованием которых генерируется сессионный ключ для шифрования передаваемых по беспроводному каналу данных. Это может привести к тому, что злоумышленник будет иметь возможность послать в эфир такой поддельный ключ, который позволит ему в дальнейшем расшифровывать передаваемый трафик. Это может стать серьезной проблемой, например, для беспроводных Bluetooth клавиатур.

Для исправления ситуации Bluetooth Special Interest Group (SIG) обновила стандарт Bluetooth и сделала проверку ключей на стадии спаривания устройств обязательной. В программу сертификации также были добавлены тесты на наличие этой проблемы.

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

Продукты Microsoft уязвимости не подвержены, про Linux пока деталей не известно.

https://thehackernews.com/2018/07/bluetooth-hack-vulnerability.html

Исправлены уязвимости в Apache Tomcat

Apache Software Foundation (ASF) выпустила исправления для сервера Tomcat. Одна из уязвимостей может быть использована для раскрытия конфиденциальной информации. Tomcat - это веб сервер с открытым исходным кодом, предназначенный для обслуживания веб приложений написанных на языке Java.

Первая уязвимость (CVE-2018-8037) раскрытия информации связана с неправильной обработкой завершения соединений, из-за чего сессия может быть переиспользована в новом соединении. О проблеме сообщил Дмитрий Трескунов 16 июня, а 22 июля информация уже стала публичной.

Вторая уязвимость (CVE-2018-1336) связана с UTF-8 декодером и может привести к бесконечному циклу в обработке и как следствие к отказу в обслуживании.

Уязвимости подвержены 7, 8 и 9 версии Tomcat’а. Администраторам рекомендуется обновить ПО.

https://thehackernews.com/2018/07/apache-tomcat-server.html

Google запускает U2F ключи собственного производства

На 18-й конференции Google Cloud Next компания представила USB токены с названием Titan Security Key. Они будут поддерживать стандарт FIDO U2F. Ранее Google заявляла, что 85000 ее сотрудников уже используют аппаратные устройства для двухфакторной аутентификации в течение нескольких месяцев и за это время они не стали жертвами фишинга.

По сравнению с SMS, аутентификация с помощью токенов гораздо более надежная, а в некоторых случаях и гораздо более удобная. Точные цены токенов не названы, но предположительно цена будет в районе $20-$30.

https://thehackernews.com/2018/07/google-titan-security-key-fido.html

Борьба с криптомайнерами в Google Play Store

Вслед за Apple компания Google решила изменить условия работы своего магазина приложений Play Store с целью блокировки приложений, которые используются для добычи криптовалют. Ранее Google уже забанила майнинговые расширения для браузера Chrome. Помимо приложений обе компании ведут борьбу и с рекламой криптовалют.

На практике уже встречались инфицированные приложения для Android, которые незаметно для пользователя использовали ресурсы центрального процессора. Также в добыче криптовалют участвуют посетители некоторых сайтов. Некоторые сайты поступают корректно и предупреждают об этом пользователя, а некоторые делают втихую.

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

https://thehackernews.com/2018/07/android-cryptocurrency-mining.html

CSP

В одном из прошлых выпусков мы рассматривали уязвимости вида XSS - Cross Site Scripting. Суть уязвимости заключается в том, что веб приложение некорректно обрабатывает часть входных данных и интерпретирует их как код. При эксплуатации код либо целиком берется из входных данных, либо добавляется команда на загрузку кода со стороннего ресурса.

Для защиты есть несколько механизмов. Один из них - CSP или Content Security Policy (политика безопасности содержимого).

Возможности CSP

XSS атака эксплуатирует доверие браузера к полученным с сервера данным. Вредоносный скрипт выполняется в браузере жертвы, потому что браузер доверяет данным с сервера.

С помощью csp можно сократить возможности атаки, указав, каким источникам можно доверять. В дополнение можно указать, какие протоколы могут использоваться. Например, можно задать, что весь контент будет получаться с использованием протокола HTTPS.

Для включения защиты нужно в ответ сервера добавлять специальный заголовок, который так и называется - Content-Security-Policy (с дефисом между словами).

Приложение и веб сервер

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

Политики CSP

Давайте вернемся к написанию правил, которые именуются в рассматриваемом нами контексте политиками. В политиках нужно описать ограничения, накладываемые на разные типы ресурсов.

Есть отдельные политики для скриптов (script-src), стилей (style-src), изображений (img-src), фреймов (frame-src) и других компонентов. Также есть специальная директива, которая задает политику по-умолчанию (default-src). В каждой директиве можно указать один или несколько источников. Значение ‘self’ ограничивает источник ориджином приложения. ‘none’ - запрещает загрузку. Можно указать также url с использованием маски или отдельно схему (http:, https:, file:, …).

Если указать политику по умолчанию или политику для скриптов, то браузер автоматически запретит выполнение встроенных скриптов - тех скриптов, которые прописаны в теле страницы. При внедрении кода в результате XSS добавляются обычно встроенные скрипты. Поэтому такое поведение браузера очень даже оправдано.

По своему опыту могу сказать, что от встроенных скриптов не всегда легко избавиться. Особенно если вы используете сторонний продукт, например, CMS. Поэтому для разрешения встроенных скриптов есть несколько возможностей. Первая добавление в политику значения ‘unsafe-inline’. Это не самый хороший путь, потому что так разрешаются все встроенные скрипты, даже те, которые добавятся в результате атаки. Чуть более сложный, но также и более надежный путь - использовать либо случайное число (‘nonce-’), которое будет разным для каждого запроса, и которое будет указано в каждом скрипте, или значения криптографической хеш функции для каждого встроенного скрипта (‘-’). При таком подходе атакующему будет непросто угадать случайное число или создать скрипт, значение хеша для которого будет одним из разрешенных.

Обнаружение проблем

Перед тем, как что-то внедрять на постоянной основе, обычно проводится тестирование, выявляются проблемы. Для CSP можно также организовать тестирование - в этом режиме браузер будет не блокировать запросы, которые не подходят под политики, а будет отправлять о них информацию по указанному в настройках адресу. Чтобы использовать тестовый режим, а не боевой, достаточно поменять название HTTP заголовка с Content-Security-Policy на Content-Security-Policy-Report-Only. Полученные несоответствия нужно будет проанализировать и либо исправить приложение, чтобы оно удовлетворяло политикам, либо исправить политики.

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

На этом на сегодня все. Изучайте и внедряйте. До следующей недели.