Fortify 360-シンクとソース-脆弱性の数
アプリケーションセキュリティ環境では、私はFortify SoftwareのFortify360を日常的に使用しています。
私の最大のハードルの1つは、数値の説明です（ソースとシンク）
Fortifyは、未検証のデータがユーザーに表示されるソースコードの各場所に、クロスサイトスクリプティングの脆弱性としてフラグを立てます。
未検証のデータがユーザーに表示される場所（シンク）が300あるとします。これらの300のシンクのうち、1つの関数を使用してデータベースからデータがすべて取得されます。 （ソース）
Fortifyはその後、クロスサイトスクリプティングの脆弱性が300件あると報告します。それがあなたに明確に伝えていないことは、そのうちの300が同じ場所から修正される可能性があるということです。
アプリケーションセキュリティエンジニアの観点から、あなたへの私の質問は、300のクロスサイトスクリプティングの脆弱性、または1つのクロスサイトスクリプティングの脆弱性があることをクライアントに報告しますか？これらのステートメントのいずれかは正確ですか？
ソースまたはシンクを報告しますか？
私が現在行っていることは、300個の潜在的なクロスサイトスクリプティングの脆弱性があり、1つの関数/メソッド内ですべて修正される可能性があることを報告しています。
300の場所で公開されている1つのクロスサイトスクリプティングの脆弱性があると言った方が正確ですか？
これの一部は主観的であることに気づきますが、自分の方法にいくつかの光を当てることができるフィールドの他の人からのインプットを探しています。
私はほとんど常にこれを300か所に現れる1つの脆弱性と表現します-特にこれが50、100、またはそれ以上の脆弱性がある可能性があるより広いレポートの一部であった場合、そうでなければ、本のように分厚いレポートで終わります-人は行動を起こすことができます。
聴衆側から考えてください。彼らは、リスクへの露出と、それに対して何ができるかを知りたいと思うでしょう。彼らの行動は修正を行うために個人またはチームを割り当てることであるため、修正する必要のある1つの問題があると言われたほうがよいでしょう-出現する300のインスタンスは、脆弱性よりも優先度が高くなる可能性があります1つの表示インスタンスですが、修復は同じです。
AviDの返信を繰り返します。クロスサイトスクリプティングは、入力検証の問題よりも、状況依存の出力エンコーディングの問題として一般的に解決されます。入力検証の問題としてそれを解決しようとしている場合、多くの場合、ブラックリスト入力検証アプローチを奨励することになります。または、ホワイトリストアプローチを使用している場合、これらを次のように取得できない可能性があります。必要に応じてしっかりと締め付けます。
また、出力エンコーディングコンテキスト（HTML、属性、CSS、JavaScript）ごとに何を処理する必要があるかは異なります。そのため、MicrosoftのWPL（Web保護ライブラリ）、OWASP ESAPI、OWASP Reform for other languages。
私の個人的な好み（私はベンダーであるIBMで働いていますが、私自身の意見です）は、修正のための最適なレポート方法はソースとシンクを提供することです。
これは特に、.NETフレームワークの場合に当てはまります。異なる出力コントロール（シンク）は、それらに渡されるデータを異なる方法でエンコードし、異なる入力コントロール（ソース）は、常にURLエンコードされた形式からデータのエンコードを解除するとは限りません。
Javaを使用すると、通常、それほど大きな変動は見られませんが、最適な修正を決定する前に、ソースとシンクの両方を考慮する必要があります。
私の意見では、XSSがどこにあり、どのように利用できるかは重要であり、重要ではありません。
XSSはある程度危険であるため、問題ではありません。
無害に見えるURIとparam構造のXSSは、より多くのフィッシングにつながるため、問題になります。多くの点で（攻撃者の観点から）、アプリケーションまたはインフラストラクチャの認証済みおよび非認証の訪問者/ユーザーの両方が利用できるページでXSSを利用できるようにすることをお勧めします。
これをXSSではなくSQLiと言い換えると、状況はより適切になり、理解しやすくなります。 SQLiの各インスタンスを悪用可能性の行使に変えることができます。多くの場合、ブラインドSQLiは悪用するのがより困難ですが、重要ではありません。実際のキーは、SQLiの各欠陥によって公開されたデータまたは不正アクセスです。 CVSSとDREADが頭に浮かびますが、実際にはCWSSやSTRIDEのようにさらに最適化する必要があります。
だから-あなたの質問に答えるために-決定はappsecリスク管理の練習であるべきです。おそらく、脆弱性カテゴリごとに1つ以上、おそらく300未満の個別の調査結果があります。私はそれらをソフトウェアの弱点として話すことを好みますが、これは対象読者によって異なる場合があります。特にレポート作成の取り組みにおいて、情報を提示する場合は、対象読者へのカスタマイズが常に重要です。
この場合も、ソースまたはシンク（あるいはその両方）をリストするかどうかは、ターゲットユーザーによって異なります。レポートを受け取っていれば、両方を確認したいと思いますが、それは私がアプリケーションの専門的な技術評価者だからです。シンクはほとんどの開発者にとって最も有用であり、根本原因の問題（つまり、エンコーディング（XSSおよびSQLiの場合））に集中できる場合がありますが、他の修正と多層防御がある場合があります。開発者だけでなく、DBA、システム管理者、マネージャ、およびアプリケーションとシステムのライフサイクルに関与している人のために提案する戦略。
だから私の答えは、この答えはおそらく数千または数百万の他の要因に大きく依存しているということです。
答えは次のとおりです。
1つの設計規則は、データベース内のすべてのデータを信頼できないサニタイズと見なすことです。そのため、HTMLを出力するコードは、HTML出力に含める前に適切にエンコードまたはエスケープする必要があります。それがあなたのプロジェクトが取ったアプローチであれば、これは300のバグです。これは、Webアプリケーションを構築するためのかなり一般的な方法です。
別の設計分野は、データベースに格納する前にすべてのデータをサニタイズすることです。これにより、データベースに格納されたデータは、すべての妥当なHTMLコンテキスト（HTML、属性、CSS、JavaScript）で安全に出力できることがわかります。これがプログラマーがフォローしている分野である場合、最初に適切にエンコード/エスケープ/サニタイズせずにデータベースにデータを格納するコード内の場所があるかどうかを知りたいです。この場合、1つのバグがあるか、多数のバグがある可能性があります。
より一般的な設計規則は、データベース内のフィールドごとに異なる不変式を使用することです。それらの一部は、データベースに格納する前に事前にサニタイズされています（そして、おそらく異なるコンテキストの場合：たとえば、1つのフィールドは、エスケープ済みまたは信頼できるHTMLを保持する場合があります） 、JavaScriptに含めるのに適したエスケープ済みの文字列を保持している場合もあります）。一部は、出力側でエスケープ/サニタイズされていないため、サニタイズする必要があります。この場合、発見したXSS脆弱性に関連付けられているデータベースの特定のフィールドについて、プログラムがどの不変条件を維持しているかを調べる必要があります。
4番目のアプローチ、そしておそらく最も一般的なアプローチは、規律をまったく持たないことです。これはセキュリティにとって悪いニュースです。
したがって、私は、ソフトウェアの開発者がXSSを防御するための体系的な戦略を採用しているかどうかを理解することから始めると思います。それらが体系的な戦略を採用していない場合、根本的な問題があります（いくつかのバグを報告できますが、それらはより根本的で深刻な問題の症状です：XSSに対する規律のある防御の欠如）。彼らが体系的な戦略を採用している場合、その戦略が何であり、意図された不変条件が何であるかを理解すると、有用なバグレポートを書くことができるようになります。