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