Алоха, разработчики, это джайниш, SDE-1 @ Innovaccer Analytics. Вкратце, я являюсь разработчиком JavaScript, работающим над созданием устойчивых многократно используемых компонентов в React.js. Я и моя команда работаем над созданием платформы для размещения, создания и управления информационными панелями для наших партнеров по здравоохранению в США. Мы создали множество функций, таких как создание панели мониторинга на основе кликов, модуль разрешений для ACL, простое создание предупреждений и многие другие.
На прошлой неделе я был на собрании по планированию спринта, где обсуждал создание службы управления публикациями для поддержания контролируемого потока информационных панелей на нашей платформе. В рамках этой функции пользователи смогут легко загружать созданные панели мониторинга на базе PowerBi (файл .pbix) на нашу платформу и им не нужно беспокоиться о настройке базовых разрешений и конфигураций.
Мы придумали сквозной рабочий процесс, в котором сначала файл будет загружен в корзину AWS S3, после завершения загрузки мы вызываем REST-API со всеми метаданными, чтобы попросить серверную часть запустить задание, которое позаботится обо всем. конфигурации. Звучит легко, правда ??
У нас было 2 плана: либо интегрировать ASW-SDK в node.js, который в нашем случае используется в качестве сервера перехода, либо использовать удивительную концепцию Pre-Signed URL, предоставляемую AWS. Мы решили использовать последнее. Процесс прост
- Предоставьте метаданные о структуре каталогов и файле и сгенерируйте предварительно подписанный URL-адрес.
- Используйте этот предварительно подписанный URL-адрес и базовую HTTP-клиентскую библиотеку Promise, такую как Axios / Fetch API, для загрузки этого файла в S3.
Все части работали нормально, но на последнем этапе загрузки возникла ошибка: Отказано в подключении к '$ {pre-signed URL}', потому что это нарушает следующую директиву политики безопасности контента: «Connect-src». На тот момент я понятия не имел, что такое CSP. Я прочитал несколько блогов и нашел решение. По моему опыту, это то, что мы должны знать о том, как работает современный браузер.
Что ж, многие из вас слышали о XSS в классе веб-безопасности. Давайте немного подведем итоги.
«Атаки с использованием межсайтовых сценариев (XSS) - это тип инъекции, при которой вредоносные сценарии внедряются на безопасные и надежные веб-сайты. XSS-атаки происходят, когда злоумышленник использует веб-приложение для отправки вредоносного кода, обычно в форме сценария на стороне браузера, другому конечному пользователю. Недостатки, которые позволяют добиться успеха этим атакам, довольно широко распространены и возникают везде, где веб-приложение использует ввод от пользователя в выводе, которое оно генерирует без проверки или кодирования ».
Заявление стоит само за себя, но чтобы дать вам немного больше информации, давайте поговорим о том, как работает Web Security.
В основе модели веб-безопасности лежит «политика одного и того же происхождения», то есть код из одного источника «https://goodOrigin.com» должен иметь доступ только к своим данным и к некоторым другим источникам, например «https: //badorigin.com »нельзя допускать. Это обеспечивает хорошую изоляцию от остальной сети, и это звучит замечательно. Но на практике злоумышленники нашли способ обойти это.
Браузер по умолчанию принимает весь код, который появляется на странице от goodOrigin, считая его истинным, поскольку нет нарушения политики одного и того же происхождения. Вот как это должно работать, но подождите, пока это не станет сложным, что, если злоумышленники введут какой-то вредоносный код, который поставляется вместе с предполагаемым кодом. В некотором смысле злоумышленник обошел «политику одного и того же происхождения». Поскольку браузеры сочтут это законным, они запустят эти скрипты, и мы ОБРЕЧЕНЫ !!!!! . Судебные разбирательства на миллионы долларов в зависимости от типа данных, с которыми вы имеете дело.
Для предотвращения этого нам нужно, чтобы браузеры были умными, но как браузеры узнают, что законно, а что нет? Вы угадали, CSP.
Вместо того, чтобы доверять всему, что получено от сервера, CSP создает HTTP-заголовок Content-Security-Policy. Здесь вы определяете список всех разрешенных источников, откуда скрипты могут быть загружены и выполнены. Даже если злоумышленнику удастся внедрить скрипт, он не сможет изменить заголовок http, и браузер проверит, что он нарушает CSP, и выдаст ошибку вместо ее выполнения.
Есть список директив, который вы можете найти здесь. например Допустим, вы хотите выполнить какой-нибудь скрипт с apis.google.com. Вы можете добавить ascript-src directive, который управляет набором связанных со скриптом привилегий для конкретной страницы. Поскольку мы хотим, чтобы запускались скрипты от goodOrigin и apis.google.com. Мы укажем Content-Security-Policy: script-src :'self',https://apis.google.com в заголовках наших ответов r. Браузер послушно загружает и выполняет JavaScript из apis.google.com по HTTPS, а также из источника текущей страницы.
Но моя проблема все еще не решена, я хочу подключиться к своей корзине S3, я не загружаю скрипт, так почему он должен терпеть неудачу !!. Оказывается, CSP - это больше, чем просто скрипты. Он также применяет шрифты, изображения, скрипты стилей, URL-адрес, по которому вы можете подключиться через XHR / WebSockets и т. Д. В моем случае я пытался сделать запрос XHR, поэтому мне пришлось использовать connect-src , в которой я определил базовый URL-адрес корзины S3 «https: // {BucketName} .s3.amazonaws.com» и Вуаля, все готово.
Примечание: если CSP не определен, браузер будет доверять всему, что получает. Так что, если бы я изначально не определил CSP, я бы никогда не столкнулся с этой проблемой. Однако рекомендуется внедрять CSP, если вы имеете дело с конфиденциальными данными. Кроме того, это не просто единственный способ его реализовать. Мы можем указать CSP в разделе ‹head› HTML-кода, но самый безопасный способ - это HTTP-заголовок, так как он не может быть изменен. CSP просто снижает риск XSS и не является полным решением, поскольку у нас есть умные люди, которые знают, как обойтись.
Надеюсь, вам эта статья показалась интересной и вы, вероятно, кое-что узнали. Кроме того, это первая статья, которую я написал, и я знаю, что в ней есть ряд ошибок. Конструктивная критика всегда приветствуется.
Вы можете связаться со мной по электронной почте: «[email protected]» для дальнейшего общения.
Ссылка:
