Как вы обновляете свои зависимости JavaScript?

1. Моя карьера как L33t H4x0r
2. Возьмите 2: немного перехвата сессии
3. Там джунгли
4. Посошок
5. Заключение

Это редакционная статья нашего последнего JavaScript-бюллетеня, вы можете подпишитесь здесь ,

Недавно исследователи безопасности проанализировали 133 000 веб-сайтов на предмет устаревших библиотек JavaScript. Их выводы, представленные в официальном документе, Ты не должен зависеть от меня: анализ использования устаревших библиотек JavaScript в Интернете Не делайте для счастливого чтения. Из проанализированных веб-сайтов 37% загрузили небезопасный JavaScript либо напрямую, либо через сторонние службы, такие как рекламодатели.

Это заставило меня сесть и заметить. Библиотеки, которые проверяли эти исследователи, были 72 из самых популярных проектов с открытым исходным кодом - библиотеки, такие как Angular и jQuery, которые мы все используем каждый день. Я никогда не задумывался над тем, может ли устаревшая версия jQuery представлять серьезную угрозу безопасности. И я (почти) наверняка никогда не вернулся, чтобы обновить старую версию jQuery на веб-сайте, который я сделал. Было ли это то, что я должен был делать?

Моя карьера как L33t H4x0r

Итак, теперь мне стало любопытно и я решил посмотреть, смогу ли я использовать устаревшую версию jQuery для взлома одной из своих страниц. Я начал с поиска «уязвимостей безопасности jQuery» и довольно скоро наткнулся эта проблема на репозитории JQuery's GitHub , Люди указывали на это как на потенциал уязвимость межсайтового скриптинга Это означает, что злоумышленник может выполнить произвольный код в источнике запроса. Это звучало многообещающе ...

Эту проблему было достаточно просто воспроизвести - проблема была в том, что jQuery выполнял каждый текстовый / javascript-ответ, полученный при выполнении запроса $ .get (), но это было настолько, насколько я был рад. Как отметил один из сопровождающих jQuery в потоке, этот «эксплойт» был похож на включение стороннего кода через теги <script>. Это вряд ли поставило бы мой веб-сайт на колени, и вряд ли это было сделано из хакерских фильмов.

Возьмите 2: немного перехвата сессии

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

Я начал с попытки распечатать файлы cookie службы, в которую я вошел (простое приложение Rails, которое использовало Придумать драгоценный камень для аутентификации). Я открыл консоль браузера и вошел в document.cookie, ожидая, что вернется мой сеансовый токен, который я мог бы перенести на удаленный сервер для всех видов гнусных целей… Но, к сожалению, эта команда просто возвратила пустую строку. При ближайшем рассмотрении выяснилось, что Devise использует HTTPOnly куки , которые недоступны через JavaScript, чтобы предотвратить именно этот вид атаки. Проклятия! Взлом оказался гораздо сложнее, чем я надеялся.

Там джунгли

Хорошо, так получается, что я не лучший хакер в мире, но шутки в сторону, на самом деле это джунгли! За последние годы безопасность браузера стала стремительно развиваться (куки-файлы HTTPOnly - тому пример), но онлайн-преступники всегда на шаг-два вперед. список возможных атак кажется бесконечным, и когда вы создаете более сложные приложения, используемые вами библиотеки (невольно) будут вводить уязвимости в вашу базу кода. Держать эти библиотеки исправленными в меру своих возможностей или, по крайней мере, знать, что некоторые из них потенциально небезопасны, должно иметь смысл, верно?

Наша оригинальная устаревшая версия jQuery не должна быть слишком сложной для обновления, но что делать, когда приложение начинает расти? К счастью, есть несколько инструментов и услуг, которые могут вам помочь. Например, пакет проверки npm делает то, что говорит на жестяной панели, и проверяет устаревшие, неправильные и неиспользуемые зависимости. Он также предоставит ссылку на документацию пакета, чтобы вы могли решить, хотите ли вы обновить. Есть также такие услуги, как Greenkeeper.io а также Snyk которые автоматизируют процесс, но они начинают уходить на территорию узла.

Посошок

Есть еще один совет, которым я хотел бы поделиться, который помогает уменьшить опасность, создаваемую сторонними скриптами. Это делается для проверки стороннего контента с использованием целостности подресурса (SRI). Возможно, вы столкнулись с этим, если в последнее время вы пытались включить jQuery из CDN jQuery. Вы увидите что-то вроде:

<script src = "https://code.jquery.com/jquery-3.2.1.min.js" целостность = "sha256-hwg4gsxgFZhOsEEamdOYGBf13FyQuiTwlAQgxVSNgt4 =" crossorigin = "anonymous"> </ script>

Новым здесь является атрибут целостности в теге <script>, который можно использовать для указания криптографического хэша в кодировке base64 ресурса, который вы запрашиваете у браузера. Это эффективно позволяет браузеру гарантировать, что ресурсы, размещенные на сторонних серверах, не были подделаны.

Использование SRI в настоящее время является рекомендуемой передовой практикой. Вы можете использовать SRI Hash Generator создавать собственные хеши.

Заключение

Постоянное обновление зависимостей JavaScript вашего приложения - это всего лишь маленький кусочек гораздо более сложной головоломки безопасности. Для небольших проектов это, вероятно, не представляет больших усилий, но по мере того, как проект начинает расти, то же самое время и усилия затрачиваются на то, чтобы все зависимости проекта были корректно исправлены. Я думаю, что это важная тема, но та, которая получает слишком мало прессы - мы все склонны стрелять и забывать, когда дело доходит до установки библиотек и модулей JavaScript.

Но что вы думаете? Насколько важно, чтобы вы постоянно обновлялись? Будет ли ваш сайт одним из 37% небезопасных JavaScript-загрузок? Насколько это проблема для нашей отрасли в целом? Позвольте мне знать в комментариях ниже.