четверг, 20 февраля 2014 г.

Политика безопасности

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

Поддерживается всеми современными браузерами.

Т.е. если на загруженной странице вдруг затесались ссылки на сайты, работа с которыми не разрешена, то загружаться они не будут. Картинки, скрипты, фреймы – все это будет заблокировано. Это значит что даже если злоумышленник прорвал первый рубеж обороны и как-то внедрил свой злонамеренный код, то до HTTP-заголовков добраться намного сложнее. Более того, браузер немедленно уведомит веб-сервер о нарушении.

И этот же стандарт вполне применим для расширений. Он дополняет механизм permissions, который позволяет явно указывать какими возможностями может пользоваться расширение.

Можно явно указать правила безопасности для расширения, но в большинстве случаев годятся те что прописаны по умолчанию. Чтобы они использовались, в манифесте должна быть указана версия манифеста 2. Вот так они выглядят:

script-src 'self'; object-src 'self'

не слишком понятно? Попробуем разобраться.


Это правило накладывает три ограничения:


1. Запрещено явное и неявное использование функции eval. Нельзя каким-либо образом передать исполняемому скрипту текст чтобы он интерпретировал и выполнил его как скрипт.


Это наиболее часто используемая уязвимость и по умолчанию она закрыта. У этого есть один явный недостаток – программы шифрования исходного JavaScript кода не могут функционировать без этой возможности.


2. Запрещено использование встроенного JavaScript. Мухи отдельно, котлеты отдельно. Вся логика должна быть в js файлах, а в html – только html, никаких скриптов.


3. Расширением загружаются только локальные скрипты и ресурсы.


Хотите использовать jQuery? Пожалуйста. Но включите его в комплект. Никаких CDN и т.п. Таким образом обеспечивается гарантия, что ни вы, ни кто-то другой, не подменит входящий в расширение скрипт другим.



Как это можно было бы сделать? Давайте рассмотрим такую ситуацию: провайдер может перенаправить запросы DNS на свой сервер, который можно настроить таким образом, чтобы для заданных сайтов он возвращал неправильные адреса – перенаправлял вас на фальшивки. Таким образом jQuery или Bootstrap у вас будет загружаться не с гугловского CDN, а с сервера ФСБ. Слегка модифицированный.


Ну ладно, ФСБ этим заниматься не станет – у них есть другие методы получения информации. А вот админ вашего провайдера вполне может такую штуку провернуть, хотя бы и от скуки. А также от желания добыть имена и пароли от вашего банк-клиента и данные кредиток, которыми вы рассчитываетесь на е-бэе.



Не верите что такое возможно? Если у вас стоит Windows




    • найдите файл hosts (с:\windows\system32\drivers\etc\hosts)

    • введите в командной строке ping yandex.ru, запомните IP адрес на который будет ломится ваш пинг

    • откройте hosts и добавьте строчку: IPяндекса www.google.com

    • сохраните и набирайте в браузере www.google.com


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


P.S. Не забудьте вернуть все на место Подмигивающая рожица


Что-то я отвлекся :)


Собственно это практически все. Ограничения можно ужесточить, или наоборот ослабить, но большого смысла в этом нет. Eval, встроенные скрипты и локальные ресурсы – это все что вам нужно помнить о политике безопасности расширений.

Комментариев нет:

Отправить комментарий