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

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, встроенные скрипты и локальные ресурсы – это все что вам нужно помнить о политике безопасности расширений.