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

Получаем примерно такие сообщения об ошибках, development mode. На продакшне это не очень используется, потому что хотелось бы собирать статистику. Content-Security-Policy тоже позволяет собирать репорты. Специальный атрибут report-uri позволяет указать нам эндпоинт, куда мы будем слать наши отчеты. Если вы сразу боитесь внедрять Content-Security-Policy, то это разумно, потому что вы можете заблокировать какие-то важные скрипты, в продакшне это страшно. Вы можете подключить их в режиме Report-Only, правила будут отрабатывать точно так же, но отчеты будут отправляться примерно в таком виде: что было заблокировано, почему было заблокировано, каким правилом.

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

То есть, вы не должны хранить cookie, чтобы они не были доступны из документа, передаваться только в реквестах. Для поддержки различных защит в старых браузерах, почитаете потом, помните о них обязательно. Это мы пытаемся обезопасить себя со стороны девелопмента, но что делать в продакшне? Нам нужны какие-то тулы, которые автоматизируют эту защиту.

Есть такой сайт и организация OWASP (Open Web Application Security Project). Если начнете что-то гуглить, вы обязательно туда попадете, именно там собрана вся актуальная информация, статистика обо всех уязвимостях. И казалось бы, где, как не там, искать советы по использованию тулов. И вот, если мы зайдем на этот сайт, мы увидим ссылку на загрузку 2013 года, релиз был 4 года назад. Использую я это? Наверно, нет. Вот еще совет 2006 года. Это, наверно, когда Сэми Камкар взламывал, тогда появился этот тул. То есть там ничего толкового нет. Большинство тулов даже только под виндой работает. Но самое интересное, что просто так тулы нам тоже не нужны. Мы хотим их встроить в CI. Один из самых популярных CI для энтерпрайза — это Jenkins, я буду приводить пример именно к нему. Как бы парадоксально ни звучало, один из действительно стоящих продуктов — это продукт от самой OWASP, они его поддерживают, хотя почему-то не так сильно пиарят, как другие. ZAP Application Proxy работает следующим образом. Мы в своем Jenkins должны сослаться на этот Application Proxy, через который будет работать наше приложение. В режиме теста, этот Proxy может протестировать наше приложение. Как он это сделает? Он просто берет наше приложение и начинает насиловать во все инпуты, вставляет всё подряд, потом собирает отчеты о том, что вставилось, что перезагрузилось, как произошло, и отправляет нам отчеты в разных форматах. Дополнительно нам понадобятся ZAP Plugin и какой-то плагин для создания отчётов, для того, чтобы собирать аналитику в долгосрочном периоде. Строить какие-то тренды и т.д. Из минусов, мы можем понимать, что просто так, особенно фронтенд-разработчику, поставить proxy server в Jenkins CI довольно сложно, и тем более, чтобы через него работало приложение. По перформансу может ударить, решение не самое простое. Но ради интереса вы можете установить его локально и протестировать ваш сайт. Я вот поигрался с holyjs-moscow.ru, сайт, на котором, в принципе, нет ни одного инпута, там нечему ломаться. Но вот есть несколько рекомендаций, что пропущены некоторые хедеры для старых браузеров. То есть если я как-то встроюсь между доменом и этим сайтом, я могу этим воспользоваться для майнинга, почему бы нет.

Следующий тул — Arachni, работает он по схожему принципу. Из Jenkins мы должны сослаться и отдать URL нашей задеплоенной тестовой среды этому Arachni. У Arachni отличный CLI, и он занимается тем же самым, начинает играться с нашим приложением и формирует нам отчеты. Использовать удобнее, весит меньше и внедрять довольно просто. Дополнительно нам понадобятся: Text Finder Plugin для того, чтобы проанализировать результат отчета, пометить build как failed или success, и еще один плагин для анализа в долгосрочном периоде.

Но это всё динамическая проверка. Мы написали код, задеплоили, там проверили, но нам надо как-то понимать, что мы пишем уже что-то не то, то есть мы должны включить какой-то тул для статического анализа. Если мы начнем гуглить, в первых рядах появятся Checkmarx, Veracode, SonarQube в каком-то режиме — дорогие тулы, для энтерпрайза даже дорого, по-моему. Мы живем уже почти в 2018 году, на JavaScript уже мало кто пишет, мы пишем на ECMAScript, мы пишем на TypeScript, мы пишем на JSX, кто-то еще на чем-то пишет. Умеют ли это всё анализировать эти анализаторы? Нет. Стоят дорого, не умеют ничего. А есть ESLint – бесплатное решение для вашего кода. Подключаем Security плагин, добавляем ваш код, работаем. Он нисколько не стоит и в CI встраивается элементарно.

Хорошо, что еще можно проверить? Мы проверили динамически наши приложения, мы проверили статически наш код во время написания, а что с node-модулями? Один из популярных тулов — это Node Security Platform, устанавливается из npm очень просто (npm install nsp) с помощью команды npm check – запускается. Есть там уязвимости нет, пробегает по зависимостям, формирует вам отчёт. Работает классно, нисколько не стоит. Как вы понимаете, в CI это встроить очень просто. Работает он интересным образом — анализирует пакеты, которые есть в package.json, и проверяет по базе данных, есть ли уязвимость в этой версии и так далее, ведет зависимости, формирует вам отчет. Работает классно, опенсорс проект, тоже нисколько не стоит, но я бы вам еще посоветовал посмотреть на Snyk, работает абсолютно по такому же принципу. Устанавливаете с npm, запускаете, он пробегает по package.json, ищет уязвимости и на удивление находит их больше. Не знаю, может быть у них разные базы данных. Snyk появился позже, но маркетологи работают намного лучше. Сейчас он тестируется в Lighthouse, вы можете зайти в Canary, он там уже встроен. Вы можете посмотреть, какие уязвимости есть в ваших приложениях, прямо в dev tool, но мы используем очень часто код, который обфусцирован, разобраться, какие там есть зависимости, практически невозможно, только в старых приложениях, поэтому стоит относиться с долей иронии к этой ставке. В Snyk уже встроен GitHub, прямо сейчас вы можете зайти в Dependency graph любого приложения и увидеть зависимости, уязвимости и посмотреть, стоит ли вообще это использовать. Это работает уже прямо сейчас на всех репозиториях.

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

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

Смотрите за своими node_modules, вы сами приглашаете их в свое приложение, поэтому будьте разборчивы в этих гостях. Обязательно используйте Content-Security-Policy, а также тулы для динамического и статического анализа (ESLint).

Минутка рекламы. Как вы, наверное, знаете, мы делаем конференции. Ближайшая конференция про JavaScript — HolyJS 2018 Piter, которая пройдет 17-18 мая 2018 года. Можно туда прийти, послушать доклады (какие доклады там бывают — вы уже увидели в этой статье), вживую пообщаться с практикующими экспертами-джаваскриптерами, практиками и изобретателями разных моднейших технологий. Короче, заходите, мы вас ждём. Билеты можно достать на официальном сайте.