セキュリティをテストするときに、Webアプリケーションのすべての入力パラメーターをテストする必要がありますか？

Question

検証の欠如に対する入力パラメーターのテストはブラックボックスWeb脆弱性評価の一部であることはわかっていますが、すべての入力パラメーター（パラメーター、Cookie、HTTPヘッダー、URL ...）をテストする必要がありますか？ =テストしない場合、そのパラメーターがSQLインジェクションまたはXSSに対して脆弱である可能性があります。

優先順位付けは一般的な答えの1つですが、完全に重要ではない機能でのSQLインジェクションがデータベースへのアクセスを開いて攻撃者に完全な制御を与える場合に優先順位を付ける方法

入力要素のサンプルを選択する必要がある場合、そのサンプルの選択方法

テストする入力パラメーターを選択するときに、ペンテスターは経験または本能でその決定を行うべきですか？

注：すべてのパラメーターをテストするのが正しいことですが、時間の制限により、これは現実的ではない場合があります。

Lucas Kauffman · Answer

はい、良いテストを実行したい場合は、すべてのパラメーターをテストする必要があります。入力変数の重要度と、アプリケーション内のどこにあるかに応じて、自動テストと手動テストのどちらを使用するかを選択できます。特定の入力変数は重要ではないように見えるかもしれませんが、アプリケーションのより重要な機能（ストアされたXSSを考える）に到達するためのベクトルを攻撃者に残す可能性があることに注意してください
可能性とビジネスへの影響に基づいて優先順位を付けます。その脆弱性により、コマンドの実行や、機密情報を含むデータベースのすべてのコンテンツのダンプが可能になる場合は、できるだけ早くパッチを適用する必要があります。公開情報へのアクセスのみを許可している場合（アプリケーション内でより多くの特権を取得したり、基盤となるOSにアクセスしたりするために悪用できない場合）、優先度を低くすることができます（他に優先している問題に応じて）オン）
「入力要素」が何であるかはわかりませんが、パラメータを意味する場合は、すべてを選択する必要があります。一部の分野では、他の分野よりも注意を払うことができます（予算/時間によって異なります）。
場合によっては、クライアントが要求することを実行する必要があります。明らかに、特定の変数が他の変数より影響を受けやすいことがわかった場合は、もう少し注意を払う必要があります。ただし、クライアントの要件を考慮する必要があると思います。

機能が重要であると見なされていない場合でも、アプリケーションとアプリケーション内に格納されている情報に対するエクスプロイトの影響を常に評価する必要があります。逆も当てはまります。エクスプロイトを使用した重要な機能はあるが、実際にそこから貴重な情報を得ることができない場合は、修正するために優先度を低くする必要があります。したがって、脆弱性を悪用することによる影響は重要であり、重要度ではないは、悪用している関数の重要性です。 影響に基づいて優先順位付けを行う必要があります。

u2702 · Answer

答えは間違いなく「はい」、「いいえ」、「それは依存する」です。この質問をするためのより良い方法は、「リソースが限られていることを知っているので、自分のWebアプリケーションのレビューをどのように優先するべきですか？ "です。

セキュリティにおいて、成功は100％安全であるとは定義されていません。成功とは、リスクを許容可能なレベルまで下げることと定義する必要があります。「許容可能なリスクのレベル」は、アプリケーションの機能、アプリケーションが保護する機能、何か悪いことが起こった場合の影響を基にする必要があります。ペースメーカーを実行するコードについては、Androidゲームを1ドルで購入するゲームよりも詳しく確認してください。

99％の組織にとって、リソースは限られています。 Webアプリケーションのあらゆる側面を徹底的にテストするためのリソースがあるとは考えられません。どのリソースを確認できるかを理解し、優先順位を付ける必要があります。

アプリケーションはそれぞれ異なるため、独自の判断を行う必要がありますが、ここで私が優先するいくつかの事項を示します。

SQLクエリの一部として使用される入力（SQLインジェクション）

実行されたコマンドの一部として使用される入力（コマンドインジェクション）

LDAPクエリの一部として使用される入力（LDAPインジェクション）

他のユーザーにエコーバックされる1人のユーザーからの入力（永続的なXSS）

そのユーザーにエコーバックされる1人のユーザーからの入力（XSSを反映）

ユーザーのアカウントを変更するアクションの一部として使用される入力

複雑な処理の一部として使用される入力（リソース枯渇DOS）

昇格された特権で実行されるすべてのプロセスに渡される入力

さらに、Webアプリのすべての側面を徹底的に確認することはできないため、追加の緩和策を追加して"cheat"を行います。

昇格された特権なしでWebサーバーを実行する

DBアクセスのアカウントには最小限の権限が必要です

異なるタイプのDBアクセス用に個別のアカウントを持っています。 DB呼び出しの95％が読み取り専用である場合は、それらの書き込み権限を持つアカウントを使用しないでください。

k1DBLITZ · Answer

他の人が指摘したように、短い答えは[〜＃〜] yes [〜＃〜]です。すべての入力パラメーターをテストする必要があるのは、つまり、アプリケーションのコーディングがどれほど適切であるか、または不十分であるかはわかりません。

しかし、すでに述べたように、ビジネスラインからの非現実的な締め切りがある場合、必ずしもうまくいくとは限りません。

OWASPは、どのキャラクターに優先順位を付けるべきかを判断できる場合があります。例： http://owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet （OWASP Webサイト）

ただし、そうは言っても、今ではより大きなワークロードが作成されています。可能性のある各脆弱性を調べ、どの文字がその脆弱性に固有であるかを判別する必要があります。

そのタスクだけでは、すべてのキャラクターをテストするよりも（少なくとも最初は）時間がかかる可能性があり、完全ではありません。（言うまでもなく）