Политика безопасности контента (CSP):
CSP играет очень важную роль в защите отображаемого контента. Он просто решает, откуда должен извлекаться контент в нашем приложении. Он добавляет дополнительный уровень защиты, который помогает в выявлении и смягчении уязвимости внедрения контента.
Если неавторизованный человек хочет внедрить свой контент, чтобы воспользоваться преимуществами приложения, например, может использовать приложение с XSS, которое отправляет файл cookie в другой домен или уязвимость, связанная с кликджекингом, то оно покажет ошибку и не позволит приложению сделать ошибку. запрос к тому произвольному домену.
CSP по умолчанию блокирует функцию оценки строки, такую как eval (). Поэтому, если разработчик хочет использовать функцию eval (), он должен изменить ее, как Json.parse ().
Когда мы используем CSP:
я. Если браузер поддерживает, CSP устанавливает некоторые ограничения и сообщает браузеру, как вести себя по отношению к приложению и оставлять нежелательный контент в соответствии с реализованным CSP.
II. Если браузер не поддерживает CSP, браузер игнорирует его и работает нормально, ничего не блокируя. Иногда дает предупреждения.
Синтаксис:
Content-Security-Policy: ‹directive› ‹value›; ‹Directive› ‹value›
я. Директива: правила для различных ресурсов, которые определены в ней.
II. Значение: здесь можно добавить / внести в белый список один или несколько доменов.
Это означает, что заголовок пользовательского агента может загружать, какие ресурсы и какие действия мы хотим выполнить с этими ресурсами.
Примечание.
я. Если он не установлен плотно, то его можно использовать не по назначению.
II. Все браузеры не поддерживают CSP, особенно IE и более старые версии других браузеров. В этом случае мы должны запретить использование браузера со старой версией.
iii. Убедитесь, что браузер поддерживает версию CSP, которую вы собираетесь внедрить.
Что нужно?
В настоящее время приложение предоставляет множество функций, например, приложение извлекает некоторые изображения или сценарии с другого конца, поэтому это содержимое необходимо защитить с помощью CSP.
Как получить CSP?
Я создал небольшой репозиторий на GITHUB, т.е.
https://github.com/guptabless/csp-scanner/blob/master/csp.py
Команда : python csp.py –u ‹URL-адрес приложения›
я. Если в приложении реализован CSP, он получит все веб-сайты, указанные в CSP:
Как реализовать CSP:
CSP не зависит от языковой структуры. Мы можем настроить его на сервере Apache или Nginx.
После реализации CSP на сервере мы можем увидеть результат выше в заголовке ответа.
я. Default-src: это обязательно, потому что, если приложение не может найти свой конкретный ресурс, оно будет использовать сценарий по умолчанию.
II. Script-src: запрещает выполнение встроенного скрипта.
iii. Style-src: запретить применение встроенного стиля.
iv. Report-to: это не остановит работу веб-сайта, если будет загружено какое-либо содержимое, не упомянутое в CSP, но будет создавать журналы возникших проблем.
Если вы хотите удалить эту директиву, вы можете реализовать политику CSP в принудительном режиме. В принудительном режиме вы все равно можете включить директиву report-to, но организация решает, хотят ли они ее включать или нет, потому что все нарушения CSP по-прежнему регистрируются.
v. Предки фреймов: мы можем ограничить отображение страницы во фреймах другими страницами.
Если мы установим для этой директивы значение «none», то это будет то же самое, что и «X-Frame-Options: deny».
Если мы установим для этой директивы значение «self», это означает, что только с того же веб-сайта (того же происхождения) и аналогично использованию X-frame-Options: SameOrigin.
vi. Изображение: чтобы ограничить источник изображения.
Значения внутри этих директив мы можем включать URL-адреса и некоторые указанные ключевые слова, такие как «none», «self», «unsafe-inline» и unsafe-eval. Это означает, что встроенный javascript разрешен по умолчанию. Эти ключевые слова всегда вводятся в одинарных кавычках, и каждая директива должна быть указана только один раз в одном заголовке.
Примечание. Внедрение CSP - не сложная задача, но поддерживать CSP - задача, но каждый раз, когда мы вносим изменения в приложение, мы должны убедиться, что политика CSP была изменена в соответствии с ними.
Основные шаги при внедрении CSP:
Вот несколько шагов, как безопасно реализовать CSP.
я. Перечислите все ресурсы, которые использует ваше приложение:
Проверьте всю функциональность приложения и внесите в белый список все ресурсы, которые приложение использует. Однако вопрос в том, как узнать ресурс?
а. Изучив исходный код приложения
б. Используя сканер отрыжки и проверьте URL-адрес и ресурсы.
c. Прокрутите все конечные точки приложения, чтобы ничего не осталось.
Примечание. Мы можем использовать несколько инструментов для проверки ресурсов, так как всегда лучше получить больше.
II. Создание политики по основному ресурсу:
На основе ресурсов найдите уникальные домены, чтобы мы могли легко реализовать эти домены в директивах в соответствии с их категорией, например, ресурс, связанный с изображением, чтобы он попадал в тег «image».
iii. Ознакомьтесь с политикой производства
После этого организации необходимо внедрить CSP в режиме «только отчеты». Таким образом, если есть ошибка в реализации CSP и есть какое-либо нарушение, то отчет отправляется на «report-uri». В организации «report-uri» уже указан URL, по которому будет отправлен отчет о нарушении. Чтобы они могли исправить ошибку в CSP
iv. Улучшите свою политику CSP и повторите процесс еще раз с iii по iv
После изменения политики CSP снова попробуйте реализовать обновленную политику CSP и повторите два вышеуказанных шага. Чтобы убедиться, что при запуске приложения в приложении не будет ошибок из-за реализации CSP.
v. Регулярный мониторинг
Продолжайте регулярно отслеживать политику CSP, чтобы мы узнали о лазейках и, если есть какие-либо обновления в приложении или включение любых новых ресурсов, обновите политику CSP соответственно.
Следуя шести шагам, мы обрабатываем белые списки доменов и внедряем CSP, но если мы хотим установить ограничение на основе страниц. Этого можно добиться с помощью директивы песочницы. Здесь мы рассматриваем страницу так, как если бы она была из изолированного фрейма.
Использование CSP:
Мы не можем использовать это никакими способами. Давайте обсудим здесь:
я. Script-src: ‘unsafe-inline’
Он находится под слабой безопасностью CSP. Этот параметр удаляет песочницу XSS. Это позволяет вставлять JavaScript в HTML-страницу, чтобы злоумышленник мог фактически выполнить XSS, используя вредоносные теги JS.
II. Если пользователь пытается загрузить изображение:
Приложение имеет функцию загрузки файлов, и злоумышленник загружает изображения этого типа.
‹img src =» https://test.com onerror = ‹script› alert (1) ‹/script› »/›
iii. Если у нас есть белый список img-src и frame-src с unsafe-inline и unsafe-eval, тогда это может вызвать проблему, поскольку встроенный javascript может быть выполнен, даже если мы можем использовать img-src для запуска XSS.
iv. Мы добавили некоторые домены в белый список, но если в этих доменах есть что-то вредоносное, например JSONP, это также делает наше приложение уязвимым.
‹скрипт src = https://test.com / jsonp? callback = alert (1) /›
Исправление
· Конфигурация в CSP должна быть ограничительной.
· Правильный белый список домена в значении директивы.
· Отключите встроенный JavaScript и CSS, чтобы защитить приложение от XSS или кроссфреймовых сценариев.
· Любой надстройкой пользователь может завершить CSP, поэтому постарайтесь обучить пользователей этому.
· Установка небезопасной встроенной директивы означает, что весь этот белый список, который вы сделали для скриптов, бессмыслен. Так что не используйте небезопасную встроенную директиву.
