Node.jsアプリケーションの脅威モデリング

この記事は、Gergely Nemeth氏（RisingStackのCEO）によるゲスト投稿です。同氏は、Node.jsアプリケーションやマイクロサービスの監視とデバッグを行うTrace by RisingStackを開発しています。

アプリケーションをどのような脅威から守るべきでしょうか。クロスサイトスクリプティング攻撃に対処すべきでしょうか。SQLインジェクションはどうでしょうか。クロスサイトリクエストフォージェリから身を守るべきでしょうか。端的に言えば、答えははいです。ただし、いつものことながら、そう単純ではありません。攻撃者となり得る人物や、攻撃者がアクセスできるもの（そして、それにどれほどの価値があるか）によって、アプリケーションをさまざまな方法で守る必要があります。「誰から守るのか？」「どれくらいの期間、安全を保つのか？」に答えられなければ、セキュリティについて語る意味はありません。

だからこそ、ソフトウェアに対するセキュリティ上の脅威をモデル化する必要があります。有効な手法の一つが、攻撃ツリーです。

攻撃ツリーとは？

攻撃ツリーは、さまざまな攻撃を踏まえて、システムのセキュリティを形式的かつ体系的に記述する方法です。基本的には、システムへの攻撃をツリー構造で表します。目標をルートノードとし、その目標を達成するさまざまな方法をリーフノードとして表します。- Bruce Schneier

攻撃ツリーの例

以下は、物理的な金庫を対象にした簡易的な攻撃ツリーです。攻撃者の明白な目標は、金庫を開けることです。この例では、そのための主な方法が2つあります。金庫の鍵をピッキングするか、暗証番号を入手するかです。暗証番号を入手するには、誰かに賄賂を渡すか、会話を盗み聞きする必要があります。盗み聞きに成功するには、会話に耳を傾け、標的に暗証番号を口にさせなければなりません。

目標同士のつながりを把握したら、それぞれに値を割り当てられます。この例では、値は可能（P）と不可能（I）です。これはあくまで攻撃者の視点で可能か不可能かを判断することを忘れないでください。たとえば、攻撃者に潤沢な資金があれば、賄賂を渡すことは可能です。一方、大学生の視点では、おそらく不可能でしょう。

値を割り当てると、どの経路への対策が必要かがはっきりわかります。

もちろん、リーフに割り当てる値は、攻撃コストなど、ほかのものでもかまいません。

Node.jsアプリケーションの攻撃ツリーを作成する

攻撃ツリーの基本がわかったところで、Node.jsアプリケーションに適用してみましょう。

まず、攻撃目標となり得るものを特定します。目標ごとに、個別の攻撃ツリーを作成します。それぞれの目標について、考えられる攻撃をできるだけ多く洗い出し、ツリー全体ができあがるまでこの作業を繰り返してください。異なるツリーに同じサブツリーが含まれていても、まったく問題ありません。

攻撃ツリーが十分にできあがったら、それをセキュリティ上の判断に活用できます。クロスサイトスクリプティングやクロスサイトリクエストフォージェリなど、特定の種類の攻撃に対してシステムが脆弱かどうかを判断できるようになります。

きっと驚くはずです。多くの人は、対策すべきではない攻撃ベクトルへの防御に力を注ぐ一方で、大きなセキュリティ上の穴を放置しています。

Node.jsアプリケーションの攻撃ツリーの例

Node.jsアプリケーションの攻撃ツリーを見てみましょう。RisingStackではNode.jsの監視ソリューションを開発しているため、Traceの世界を例に攻撃ツリーを紹介します。

ここで作成する攻撃ツリーの目標はシンプルです。物理的な金庫の例と同じように、認証を回避することです。

上の例は、Traceアカウントの認証を回避する方法を示しています。最初のサブツリーは、Cookieが盗まれた場合を示しています。この例では、安全でない依存関係が原因でCookieが盗まれる可能性があります。

• Cookieの安全性を高めるには、Secureモードを有効にできます。この属性を設定すると、リクエストがHTTPSで送信される場合にのみ、ブラウザーからCookieが送信されます。

• Cookieの有効期間を短くすることもできます。盗まれたとしても、使用できる時間を限られたものにできます。

2つ目のサブツリーは、正しいユーザー名とパスワードを使ってアカウントにアクセスするケースを示しています。この場合、攻撃者はユーザーから認証情報を入手する必要がありますが、これは私たちには制御できません。

• 二要素認証を追加すれば、攻撃者の手間を増やせます。

3つ目のサブツリーは、Trace by RisingStackのデータベース内の認証情報が実際に変更されるケースを示しています。そのためには、攻撃者がデータベースにアクセスする必要があります。

• 攻撃者にデータへアクセスされたとしても、最後の防御策が残っています。データセットを暗号化しましょう。

これらの例は完全なものではなく、簡単にさらに複雑になりますが、システムのセキュリティを脅威モデリングする際に、どのように始めればよいかイメージしていただけたと思います。