最近、セキュリティ研究者の調査によって、13万3000のWebサイトが最新でないJavaScriptライブラリーを使用していること分かりました。調査結果は『Thou Shalt Not Depend on Me: Analysing the Use of Outdated JavaScript Libraries on the Web（Webサイトにおける最新でないJavaScriptの使用率に関する分析）』として、報告書にまとめられPDFで公開されています。決して楽しい読み物ではありません。対象のWebサイトのうちの37％が、直接的もしくは広告主のようなサードパーティサービスを通じて、安全ではないJavaScriptを読み込んでいました。
これを知って、私は目が覚めました。研究者が対象にしていたライブラリーは、もっとも人気のある72のオープンソースプロジェクトでした。日常的に使っているAngularやjQueryのようなライブラリーです。jQueryの古いバージョンが、深刻なセキュリティの脅威を含む可能性があるなんて、考えたこともありませんでした。また、昔作ったWebサイトの古いjQueryを更新したこともほとんどありません。もっとちゃんとしておくべきでした。
自分でハッキングしてみる
調査結果に興味がわいたので、古いページのjQueryを使って自分のページをハックできないか実験してみることにしました。「jQueryのセキュリティ上の脆弱性」と検索して、すぐにjQueryのGitHubリポジトリに書かれているイシューを見つけました。イシューには、潜在的なクロスサイトスクリプティングの脆弱性があると指摘していました。攻撃者がリクエスト元で任意のコードを実行できる、ということです。このときは、良さそうなものを見つけたと思っていたのですが…。
イシューに書かれていること（jQueryが$.get()リクエストを実行したときに、受け取ったすべてのtext/javascriptを実行してしまう）を再現するのは簡単でした。しかし、興奮したのはそこまででした。イシューのスレッド内でjQueryの開発者が指摘していたように、この「悪用」は<script>タグを介してサードパーティのコードを組み込むことと良く似ていました。つまり、Webサイトを乗っ取る、ハッキング映画に出てくるものとはほど遠いものだったのです。
テイク2：セッションハイジャックしてみる
それでもまだ興味があり、うまくやればユーザーのコンピュータで任意のコードを実行できるのではないかと考えました。 セッションハイジャックを使って悪意のあるスクリプトでユーザーのCookieを操作して、サービスへの不正アクセスやなりすましのログインをされる危険性は、よく警告されています。自分の手でセッションハイジャックをしてみようと思いました。
ログインしていたサービス（認証にDevise gemを使った単純なRailsアプリ）のCookieを表示しようと試みました。ブラウザーのコンソールを開いて、自分のセッショントークンが返ってくるのを期待してdocument.cookieと入力しました。このトークンを使えば、あらゆる悪意のあるアクションをリモートサーバーにAjaxできます。残念ながら、このコマンドは空の文字列を返すだけでした。よく調べてみると、DeviseがHTTPOnly cookiesを使用していて、この種の攻撃を防ぐためにJavaScript経由ではアクセスできないようになっていました。なんということでしょう！ ハッキングは思っていたよりもはるかに難しいことが分かりました。
セキュリティを保つためにすべきこと
ここまでで、私が世界最高のハッカーじゃないことが分かりました。冗談はさておき、ハッキングされる危険はすぐそこにあります。ブラウザーのセキュリティは過去数年間で飛躍的に高まっています（HTTPOnly Cookieも良い例）。しかし、オンライン上の犯罪者は常に1歩、2歩先を行っています。攻撃される可能性のあるリストは無限であり、さらにより複雑なアプリケーションを構築する際に使用するライブラリーは、無意識のうちにコードの脆弱性を高めます。ライブラリーにできるだけパッチを当て続けたり、潜在的に安全ではないものが含まれる可能性があることを意識するだけでも意味があるとは思いませんか。
昔使っていた古いjQueryを更新するのは難しいにせよ、アプリケーションが複雑化してきたときはどうでしょうか。幸いなことに、役に立つツールやサービスがあります。たとえば、npm-checkパッケージは、まさに望み通りの働きをします。最新ではないものや、間違っているもの、未使用の依存関係がないかをチェックします。また、パッケージのドキュメントへのリンクも提供して、それを元に更新するかどうかを決められます。さらにプロセスを自動化するGreenkeeper.ioやSnykなどのサービスもありますが、利用するにはNodeの深い部分に踏み込む必要があります。
もう1つの方法
もう1つ紹介したいテクニックは、サードパーティのスクリプトによって引き起こされる危険を緩和するものです。具体的には、Subresource Integrity（SRI）を使用してサードパーティのコンテンツを検証します。最近、jQuery CDNからjQueryを組み込もうとした人は、この検証が入っていることに気付いたかもしません。次のようなコードです。
<script
src="https://code.jquery.com/jquery-3.2.1.min.js"
integrity="sha256-hwg4gsxgFZhOsEEamdOYGBf13FyQuiTwlAQgxVSNgt4="
crossorigin="anonymous"></script>
新しいのは<script>タグのintegrity属性で、ブラウザーにフェッチしているリソースに対するbase64でエンコード化されたハッシュ値を指定できることです。これにより、ブラウザーはサードパーティサーバーでホストされているリソースが改ざんされていないことを確認できます。
現在、SRIを使用することがベストプラクティスとして推奨されています。SRI Hash Generatorを使って独自のハッシュを作成できます。
まとめ
アプリケーションのJavaScriptの依存関係を最新の状態に保つことは、大きなセキュリティパズルの中の小さな部分に過ぎません。小規模なプロジェクトの場合、それほど大変ではないはずです。しかし、プロジェクトが大規模化すると、プロジェクトのすべての依存関係に適切なパッチが適用されているかを確認するのは、かなりの時間と労力が費やされます。これは大切なことですが、あまり表に出ることはありません。JavaScriptライブラリーやモジュールをインストールするとき、こういった対策は忘れられる傾向にあるのです。
※この記事は、最新のJavaScriptニュースレターを編集したものです。
（原文：How Do You Keep Your JavaScript Dependencies Up-to-date?）
［翻訳：萩原伸悟／編集：Livit］
