IASTを使用して、ファーストパーティコード内の脆弱性を実証する方法

最近の記事では、開発者がNew Relicの機能を使用して、スキルセットにセキュリティを追加する方法を紹介しました。また、オープンソースソフトウェアライブラリの隠れたセキュリティリスクを軽減する方法についても詳しく説明しました。これらのブログの両方では、サードパーティのコードと、ソフトウェアアプリケーションのセキュリティに与える影響に重点を置いていました。この記事では、独自のカスタムコード、つまり自分で作成したコードのセキュリティに焦点を当てます。

一般に、ファーストパーティコードのセキュリティを確保する上で使用できる方法は多数あります。一般的なアプローチの1つは、テスト、QA、運用環境などのさまざまな環境で、デプロイメントの前にソースコードをスキャンする静的コード分析ツールの利用です。この方法では、リポジトリやソフトウェアビルドにハードコードされたシークレットが含まれないようにするため、有益であることがわかります。ただし、このような手法では、アプリケーションの静的な側面についての洞察が得られるだけです。

この制限に対処するために、多くの場合、動的アプリケーションセキュリティツールを使用して、外部の観点からアプリケーションを検査することでブラックボックステストを実行しています。このアプローチにより別の視点が得られますが、それでも全体的なセキュリティ状況の一側面しか明らかにされません。問題の核心は、これらのソリューションのどちらも包括的なビューを提供していないことです。

New Relicインタラクティブ・アプリケーション・セキュリティ・テスト（IAST）はこの問題に対処するために正確に設計されています。New Relicのツールはすでにアプリケーションの動的な側面を内部から可視化できるため、IASTを使用するとオブザーバビリティを強化できます。アプリケーションパフォーマンス監視（APM）の本質は、システム上で実行されているコードを監視することです。つまり、パフォーマンスとエラーを表示するだけでなく、サービスの各インスタンスにどのバージョンのコードがデプロイされているか、またアプリケーション自体のリアルタイムアクティビティに基づいてどのメソッドが実際にトリガーされているかも表示します。

サービスの監視では、ファーストパーティとサードパーティの両方のソースから生じるアプリケーションのセキュリティ上の懸念がますます重要になっています。New Relic IASTは、アプリケーションの脆弱性を迅速に検出することで不明瞭さを効果的に排除するため、この状況において重要な役割を果たします。これは、エクスプロイトの決定的な証拠とコード内の正確な位置を提供します。さらに、このツールは実用的かつ反復可能なテスト手順と軽減策を提供し、本番前環境や開発環境でセキュリティ問題が悪用される前に効率的に対処できるようにします。実用的かつ反復可能とはどういうことかを例を挙げてみてみましょう。すべてのセキュリティテストには、関連するcurlコマンド（または他の形式のテストスクリプト）があるため、コードを修正しながら戻って再テストできます。同じテストスクリプトを使用して、テストセット全体を再実行することなく、実際に修正された箇所を確認できます。

New Relic IASTは、証明可能なセキュリティへの最初のステップとして、DevOpsチームとセキュリティチームが連携してCI/CDパイプラインを高速化することで、ソフトウェアセキュリティにおける真の「シフトレフト」を可能にします。これにより、開発ライフサイクルの早い段階でアプリケーションを保護しながら、組織がイノベーションに集中できるようにします。

悪用可能な脆弱性に焦点を当てることのもう1つの重要な点は、従来のアプリケーションセキュリティツールではコンテキストが欠けているため、膨大な数のアラートが発生し、DevOpsチームとセキュリティチームに混乱を招く可能性があります。また、当面のセキュリティリスクの特定や、セキュリティ改善の検証を行うことが困難になります。基本的に、New Relic IASTは、他の多くのソリューションに見られるノイズ（誤検知）を排除し、検証でのエクスプロイトの実証を提供します。

多くのことをお話ししましたが、ここでNew Relic IASTが実際にどのように機能するかを説明します。

注：New Relic IASTの使用の開始方法を説明する前に、重要な点を指摘しておきたいと思います。New Relic IASTは、アプリケーション内で一連の実際の攻撃をシミュレートします。ここでは、テストデータを使用して、悪用可能な脆弱性のシミュレーションとテストを行います。そのため、運用前環境でのみ、New Relic IASTを使用してください。

New Relic 言語エージェント

最新のNew Relic APMエージェントには、IAST機能が含まれています。APMエージェントをアプリに追加して、バグやパフォーマンスの問題を特定することがいかに簡単であるかはご存知だと思います。.NET環境でのこの直感的な例をご覧ください。労力を費やすことなく、インジェクション攻撃など、OWASPの悪用可能な脆弱性についてカスタムコードをテストできるようになりました。私の意見では、これはNew Relic IASTの驚くべき利点であり、以下のように、多くの関係者が気に入ると思います。

• IT担当者。さらに別のエージェントを配備する必要がないため
• セキュリティチーム。これにより、開発チームがセキュリティ戦力になる
• 開発者。これはすでに使用しているツールチェーンの一部であるため

この機能は実装が非常に簡単です。この例では、 OWASP Juice Shopアプリケーションをデモ環境として再度使用します。

Juice ShopはNode.jsで構築されているため、最新のNew Relic Node.jsエージェント（IASTはバージョンv10.3.0で追加）をアプリケーションに追加します。

リポジトリ内で次のコマンドを実行するという、よく知られたアプローチに従います。

これにより、New Relicエージェントライブラリがアプリケーションにインストールされます。エージェントを設定する最も簡単な方法は、次の環境変数を定義することです。

Juice Shopの残りの依存関係をnpm installでインストールし、npm startでアプリケーションを実行できるようになりました。しばらくすると、使い慣れたAPMの厳選されたエクスペリエンスで、New Relicアカウントにデータが表示されます。

追加設定をなしに、エージェントはアプリケーション内で使用されるすべてのライブラリを取得し、既知の脆弱性がないかを確認します。このデータは、New Relicサービスの脆弱性管理セクションに公開されます。

New Relic IASTを有効にする

エージェントを起動して実行し、サードパーティのライブラリの脆弱性をすでに報告しているので、IAST機能の有効化を続けましょう。

アプリケーションを停止し、次に2つの環境変数を追加します。

最初の環境変数はセキュリティデータがNew Relicに送信されるかどうかを決定します。これが無効でNEW_RELIC_SECURITY_AGENT_ENABLEDがtrueの場合、セキュリティモジュールは実行されますが、データは送信されません。2つ目の環境変数では、通常すべてのセキュリティ機能を有効または無効にすることができます。

これらを定義したら、他に設定するものは何もありません。アプリケーションが再度実行されると、エージェントは残りの部分を処理します。

実際の攻撃をシミュレーション

（npm startを再度実行することで）アプリケーションが再び実行され、通常の単体テストを実行できるようになります。Juice Shopリポジトリ内では、testフォルダーにすべての単体テストがあります。たとえば、npm run test:apiを実行して、APIテストを実行できます。これらのテストを起動するだけで、エージェントはリクエストのコンテキスト、つまり、パラメーターやペイロードなどのすべての詳細を含む、New Relicコンテキスト内のトランザクションを特定できます。

たとえば、Juice Shopには、アプリケーションのユーザーにログインするためのAPIが含まれています。このエンドポイントでは、ユーザー認証のためのユーザー資格情報を含むペイロードを受信します。

アプリケーションを使用して、既存のユーザーでアプリケーションにログインしてみましょう。

しばらくすると、エージェントがアプリケーションを攻撃していることがわかります。エージェントによって問題が特定された場合、New Relicの脆弱性管理セクションに脆弱性が追加されます。大きな違いは、脆弱性が実際に悪用可能な場合にのみ実行されることです。

例を見てみましょう。

悪用可能列の感嘆符を使用して、悪用可能な脆弱性を特定できます。これは、問題を発見しただけでなく、そのエクスプロイトの実証も特定しています。脆弱性を分析する際のもう1つの重要な側面は、この脆弱性のリストが重大度に基づいて優先順位付けされていることです。

SQLインジェクションの問題をクリックすると、問題の詳細と、エクスプロイトの実証を提供する、New Relicの独自の機能についての詳細が表示されます。ここでは、脆弱性の詳細な説明と、ファーストパーティコード内でのこの問題の具体的なインスタンスを見つけることができます。

SQLインジェクションインスタンスの1つをクリックすると、ソースコード内の場所とその修正方法に関する詳細情報が表示されます。

悪用可能な脆弱性を修正

New Relic IASTの重要な機能の1つは、New Relicが提供する再現テストです。画面のテストセクションには、エクスプロイトの実証に使用できるテストスクリプトがあります。ここでは、このスクリプトを実行して、SQLインジェクションが実際にJuice Shopにおける悪用可能な問題であることを証明します。

ターミナルを開いて、New Relic UIからコピーした次のコマンドを実行してみましょう。注：スクリプトの最初の行に完全なURLを追加しました。また、data-rawパラメーターも少し調整しました。

このスクリプトを実行すると、Juice Shopの管理者ユーザーの情報を含むJSON データが返されることがわかります。もちろん、これはアプリケーションが提供すべきものではなく、実際に重大な問題とそれに関連するリスクがあることを証明しています。

New Relic IASTによって提供された脆弱性の場所から、SQLインジェクションの問題の1つが「/rest/user/login」にあることがわかります。

アプリケーションのソースコードを調べて、（リポジトリのルートにある）「server.ts」ファイルを開いてみましょう。543行目あたりで、誰かが「/rest/user/login」エンドポイントにアクセスした際に、実際に呼び出されたメソッドがわかります。メソッド「login()」が実行され、これは「/routes/login.ts」にあります。開発者として、ユーザー入力をSQLステートメント（36行目）に直接追加することで、SQLクエリが連結されていることがわかります。

これは明らかにベストプラクティスではないため、開発者はそのようなSQLクエリを作成しないようにする必要があります。

理想的には、パラメーター化されたクエリを使用します。「sequelize」フレームワークでは、これを置換と呼びます。したがって、理想的には、クエリ自体でパラメーターを使用し、置換の概念を使用してそれらをコンテンツに置き換える必要があります。更新されたコードは次のようになります。

先に進み、このコードの問題を修正し、アプリケーションを再デプロイしましょう。アプリの新しいリリースが起動し、データがNew Relicに報告されるようになったので、テストcurlスクリプトを再度実行できます。

この実行が完了すると、以前と同じ結果、つまりJuice Shopの管理者ユーザーの資格情報は得られません。指定したメールまたはパスワードが無効であるというメッセージが表示されます。これは実際に予期していた結果であり、ファーストパーティのソースコード内の修正により実際にバグが修正されたことを証明しています。

ここで、New Relicユーザーインターフェースに戻り、アプリケーションの脆弱性管理セクションを参照すると、依然として2つの悪用可能な脆弱性が特定されていることがわかります。ただし、 SQLインジェクションの問題は約4時間前に検出され、Reflected XSSの問題はデプロイメント後に再報告されたため、この問題はまだ解決していないことがわかります。

結論

この例では、アプリケーションを調べて悪用可能な脆弱性を見つけるテストを実行することにより、対話型のアプリケーションセキュリティスキャンを実行する完全なサイクルを説明しました。

当社は問題を特定しただけでなく、特定の問題が実際に悪用可能であることの実証に再現可能なテストスクリプトを含む、特定のインスタンスも受け取りました。ファーストパーティのコードの問題を修正した後、新しいバージョンのアプリケーションを構築してデプロイしました。今回、New Relic IASTエージェントのテストは、アプリケーション内のこの特定のエリアでは正常に実行できませんでした。同じテストスクリプトを実行して修正が成功したことを証明し、アプリケーションで問題がなくなったことを検証することができました。