Это редакционная статья нашего последнего JavaScript-бюллетеня, вы можете подписаться здесь .
Недавно исследователи безопасности проанализировали 133 000 веб-сайтов на предмет устаревших библиотек JavaScript. Их выводы, представленные в официальном документе « Не полагайся на меня: анализ использования устаревших библиотек JavaScript в Интернете» , не приносят радости при чтении. Из проанализированных веб-сайтов 37% загрузили небезопасный JavaScript либо напрямую, либо через сторонние службы, такие как рекламодатели.
Это заставило меня сесть и заметить. Библиотеки, которые проверяли эти исследователи, были 72 из самых популярных проектов с открытым исходным кодом — библиотеки, такие как Angular и jQuery, которые мы все используем каждый день. Я никогда не задумывался над тем, может ли устаревшая версия jQuery представлять серьезную угрозу безопасности. И я (почти) наверняка никогда не вернулся, чтобы обновить старую версию jQuery на веб-сайте, который я сделал. Было ли это то, что я должен был делать?
Моя карьера как L33t H4x0r
Итак, теперь мне стало интересно, и я решил посмотреть, смогу ли я использовать устаревшую версию jQuery для взлома одной из своих страниц. Я начал с поиска «уязвимостей безопасности jQuery» и довольно скоро наткнулся на эту проблему в репозитории jQuery на GitHub . Люди указывали на это как на потенциальную уязвимость межсайтового скриптинга, которая означала, что злоумышленник может выполнить произвольный код в начале запроса. Это звучало многообещающе …
Эту проблему было достаточно легко воспроизвести — проблема была в том, что jQuery выполнял каждый text/javascript ответ, полученный при выполнении $.get() но это было настолько, насколько я был $.get() . Как отметил один из сопровождающих jQuery в потоке, этот «эксплойт» был похож на включение стороннего кода через теги <script> . Это вряд ли поставило бы мой веб-сайт на колени, и вряд ли это было сделано из хакерских фильмов.
Возьмите 2: немного перехвата сессии
Не желая, чтобы меня сдерживали, я представлял, что буду делать, если эксплойт сработает, и я смогу выполнить произвольный код на компьютере пользователя. Мы часто предупреждаем о том, что перехват сеансов, когда вредоносный скрипт может манипулировать файлами cookie пользователя, чтобы получить несанкционированный доступ к информации или услугам, в которые он вошел. Итак, я решил попробовать свои силы в этом.
Я начал с попытки распечатать файлы cookie службы, в которую я вошел (простое приложение Rails, которое использовало гем Devise для аутентификации). Я открыл консоль браузера и вошел в document.cookie ожидая, что вернется мой сеансовый токен, который я мог бы перенести на удаленный сервер для всех видов гнусных целей … Но, к сожалению, эта команда просто возвратила пустую строку. При ближайшем рассмотрении выяснилось, что Devise использует файлы cookie HTTPOnly , которые недоступны через JavaScript для предотвращения именно такого рода атак. Проклятия! Взлом оказался гораздо сложнее, чем я надеялся.
Там джунгли
Хорошо, так получается, что я не лучший хакер в мире, но, шутки в сторону, на самом деле это джунгли! За последние годы безопасность браузера стала стремительно развиваться (например, файлы cookie HTTPOnly), но онлайн-преступники всегда на шаг-два вперед. Список возможных атак кажется бесконечным, и когда вы создаете более сложные приложения, используемые вами библиотеки (невольно) будут вводить уязвимости в вашу кодовую базу. Держать эти библиотеки исправленными в меру своих возможностей или, по крайней мере, знать, что некоторые из них потенциально небезопасны, должно иметь смысл, верно?
Наша оригинальная устаревшая версия jQuery не должна быть слишком сложной для обновления, но что делать, когда приложение начинает расти? К счастью, есть несколько инструментов и услуг, которые могут вам помочь. Например, пакет npm-check делает то, что говорит на жестяной панели, и проверяет устаревшие, неправильные и неиспользуемые зависимости. Он также предоставит ссылку на документацию пакета, чтобы вы могли решить, хотите ли вы обновить. Есть также сервисы, такие как Greenkeeper.io и Snyk, которые автоматизируют процесс, но они начинают уходить на территорию Node.
Посошок
Есть еще один совет, которым я хотел бы поделиться, который помогает уменьшить опасность, создаваемую сторонними скриптами. Это делается для проверки стороннего контента с использованием целостности подресурса (SRI). Возможно, вы столкнулись с этим, если в последнее время пытались включить jQuery из CDN jQuery. Вы увидите что-то вроде:
<script src="https://code.jquery.com/jquery-3.2.1.min.js" integrity="sha256-hwg4gsxgFZhOsEEamdOYGBf13FyQuiTwlAQgxVSNgt4=" crossorigin="anonymous"></script>
Новым здесь является атрибут integrity в <script> который можно использовать для указания криптографического хэша в кодировке base64 ресурса, который вы запрашиваете у браузера. Это эффективно позволяет браузеру гарантировать, что ресурсы, размещенные на сторонних серверах, не были подделаны.
Использование SRI в настоящее время является рекомендуемой передовой практикой. Вы можете использовать SRI Hash Generator для создания собственных хешей.
Вывод
Постоянное обновление зависимостей JavaScript вашего приложения — это всего лишь маленький кусочек гораздо более сложной головоломки безопасности. Для небольших проектов это, вероятно, не представляет больших усилий, но по мере того, как проект начинает расти, то же самое время и усилия затрачиваются на то, чтобы все зависимости проекта были соответствующим образом исправлены. Я думаю, что это важная тема, но та, которая получает слишком мало прессы — мы все склонны стрелять и забывать, когда дело доходит до установки библиотек и модулей JavaScript.
Но что вы думаете? Насколько важно, чтобы вы постоянно обновлялись? Будет ли ваш сайт одним из 37% небезопасных JavaScript-загрузок? Насколько это проблема для нашей отрасли в целом? Позвольте мне знать в комментариях ниже.