それがまた起こったので、私の欲求不満は常に高くなっています。CVE-2022–29622: (In)vulnerability Analysisというタイトルの私の以前の分析を読んだ場合は、私が何を指しているのか疑問に思うかもしれません。同じ話、別の犠牲者。ただし、この場合は日付が重要です。前回の無敵解析は 2022 年のものでしたが、今日は 2018 年からの別の問題を解析します。

「なぜ 2018 年の何かに対処しなければならないのですか?」と尋ねるかもしれません。素晴らしい質問です！つい最近、Dependency Track を有効にして、Sonatype の OSS インデックスから脆弱性情報を取得したからです。

今日、脆弱なコンポーネントがあるかどうかを確認するためにSCAにざっと目を通していたので、脆弱なコンポーネントがある場合は、修復作業に優先順位を付けました。とても驚くべきことに出会いました。Koa.JSに重大な脆弱性がある!? 私のいつもの「#FFS、私の 1 週間は再編成が必要です」の後、私は次のようになりました。前回のことを思い出して…」

そしてそうしました。まず、タイトルから「問題」が見つかったのは 2018 年であることがわかります。では、なぜ今も維持されているライブラリに脆弱性があり、最新バージョンにアップグレードし続けているのでしょうか? この時点で、私の脳の調査部分が作動しました。

この時点で私たちは何を知っていますか？

1. 伝えられるところでは、2018 年に重大度が割り当てられた Koa に脆弱性があった
2. Sonatype OSS Index and Dependency Track によると、最新バージョンの Koa を実行している間、この問題は 2022 年に私に影響を与えます

• 「脆弱性」の影響を受けた Koa.JS ライブラリのバージョン
• 最新のKoa.JSに「脆弱性」が存在する場合

問題分析

「脆弱性」が何であるか、または何であったかを見てみましょう。関連するイシュー#1​​250 を GitHub から簡単にリンクさせてください。分析できるように、以下の例 (PoC?) をコピーして貼り付けます。

const Koa = require('koa');
const app = new Koa();

app.use(async ctx => {
  ctx.redirect("javascript:alert(1);")
});

app.listen(3000);

「Web アプリケーションまたは Web サービスの開発者として、あなたが私の Web サイトにアクセスした場合、ブラウザを好きな場所にリダイレクトできます。」

それが上記のコードの意味です。上記の PoC では、悪意のあるアクターが何かを悪用するための攻撃ベクトルは示されていません。

この非脆弱性について適切な「PoC」を提供したい場合(そうです、先ほど言いました)、次のようになります。

const Koa = require('koa');
const app = new Koa();
// Try: http://localhost:3000/?vector=javascript:alert(1);
app.use(async ctx => {
  ctx.redirect(ctx.request.query.vector);
});

app.listen(3000);

XSS の脆弱性について言えば、vectorパラメーターの値として入力したものが HTML コンテキストで安全に表示されない場合、実装したアプリケーションはクロス サイト スクリプティングに対して脆弱になります。(これについては後で詳しく説明します)

Sonatype がこれをどのように提示したかを拡大し、もう少し分析します。

「クロスサイト スクリプティングにつながるオープン リダイレクト」? まず、オープンリダイレクトがありませんでした。開いた場合にのみ開いており、2 つの PoC (オリジナルと私のもの) の違いがこれを明確に示しています。最初のものには攻撃ベクトルがなかったため、オープン リダイレクトはありませんでした。私の PoC には攻撃ベクトルがあり、フィルタリングがないため、オープン リダイレクトがありました。しかし、ご覧のとおり、オープン リダイレクトの有無は、Koa.JS ではなく、開発者である私に依存していました。さらに良いことに、リダイレクトがあったかどうかも私次第でした。安全でない方法でユーザーが提供した入力をリダイレクト URL として/中に含めるかどうかも、私次第でした。それでは、Koa.JS のどの脆弱性について話しているのでしょうか? 技術的には、脆弱性はなく、誰かがまだ重大な重大度を割り当てていました。正確にはプロではありません。

とにかく、適切な PoC によって実装された「脆弱性」という言葉を「悪用」しましょう。すでにポート 3000 でリッスンしているものがあるため、サービス ポートを 3000 から 4444 に変更する必要があったことに注意してください。

Location応答ヘッダーに値があることがわかりますjavascript:alert(1)。次に、ブラウザは…にリダイレクトします

ふーん、安心！警告ボックスがポップアップすることはありませんでした。はい、クエリ パラメータhttps://google.comの値として入力して Google にリダイレクトされる可能性があります。そのため、アプリケーション (PoC)はオープン リダイレクトに対して脆弱ですが、Koa が原因ではなく、フィルタリングされていないユーザー データを に渡したことが原因です。それは私が心配していることではありません。vectorctx.redirect

GitHub の問題のコメントから注目すべき重要なことは、次のとおりです。

この問題は、Koa がリダイレクト応答の本文に HTML ハイパーリンクを出力し、クロスサイト スクリプティング攻撃を引き起こす可能性があるという事実に起因しています。

ああ、それはもう少し理にかなっています! まだそうなのか見てみましょう。

いいえ、もうそうではありません。応答本文はありません。この「脆弱性」は私には影響しないと結論付けることができると思います。依存関係トラックで誤検知としてマークするだけです。

コンテキスト分析

すべてのセキュリティ専門家が採用し、「問題」を報告する前に実行する「コンテキスト分析」を提案します。これを別の例にして、それがどのように行われたかを示します。(コンテキストの重要性をよりよく説明しているため、CVE-2022–29622: (In)vulnerability Analysisを読むことをお勧めします。)

1. すぐに使用できる Koa.JS は、どこにもリダイレクトしません。そのため、Sonatype OSS Index で述べられている「オープン リダイレクト」は存在し、存在しませんでした。
2. GitHub で提供された「PoC」に基づいて、開発者が XSS につながる可能性のあるばかげたことを行う機会がありました。ただし、上記の #1 を参照してください。Koa.JS は、独自にリダイレクトを行いませんでした。以下の #2 を参照してください。
3. 報告された「脆弱性」が存在するためには、開発者は自分のアプリケーションを安全でない方法で実装したに違いありません。これは、Koa.JS が改善されたとしても、脆弱性があるとは言えないことを意味します。文脈的に不適切です。問題の脆弱性は、安全に実装されていない Web アプリケーションにのみ存在する可能性があります。

このような状況に対処する最善の方法の例を挙げましょう。私が Swagger Parserに提出したこの問題と、それがどのように伝えられたかを見てください。問題レポートを分析してみましょう。

1. タイトルには「安全でないリゾルバーの動作」と書かれています。タイトルの LFI (Local File Inclusion) について話しているのではありません。これは、私が混乱した場合にローカル ファイルが含まれる可能性がある一方で、自分が何をどのように操作しているかを知るのは、開発者としての私次第だからです。デフォルトの動作は (おそらく今も) 安全ではありません。しかし、ライブラリ自体は、私が関与しなければ何もしません。
2. 次に、どのバージョンのライブラリについて話しているかを明確に述べます。ライブラリの安全でない既定の動作がアプリケーションに影響を与える条件をリストすることで、コンテキストをさらに明確にします。これにより、ライブラリ自体に脆弱性がないことは明らかですが、開発者を支援するために改善できる安全でない動作があります。
3. コンテキストが設定されたので、動作する PoC、脆弱なコード スニペット (PoC として作成したもので、Swagger パーサーの一部ではありません!)、および脆弱なアプリ/サービスを悪用した実際の結果を提供します。ライブラリは安全ではありません。
4. いくつかの調査を行ったところ、開発者として、問題を軽減する方法でライブラリを実際に構成できることがわかりました。（ある程度）私はこれを開発者と共有しました。少なくとも、ドキュメントを更新して認知度を高めることができます。
5. 追加のコンテキスト、分析、および改善方法の例を提供しました。

結論

まず第一に、Sonatype は OSS インデックスをうまく活用し、データベース内の各脆弱性についてバージョン情報を利用できるようにする必要があります。それが最低限のことです。(データベースからこの特定のエントリを完全に削除するためのボーナス ポイント。)

Dependency Track は FOMO に悩まされていると思われます。そのため、バージョン番号が利用できない場合は、コンポーネント名の一致のみに基づいて問題を報告します。重大な脆弱性を見逃すリスクがないことはある程度理解しています。この動作の問題 (誤検知) は、ソフトウェア構成分析の採用を促進しないことです。静的コード分析の誤検知のように、開発者を怖がらせます。逆効果。

コンテクスト！流血の文脈、人々！私が提案する：

1. すべてのセキュリティ専門家が採用し、「問題」を報告する前に実行する「コンテキスト分析」
2. 「安全でない行動」と「脆弱性」を区別する
3. ソフトウェア ライブラリとアプリケーション/サービスの違いを理解する