バックドアのコードを確認するにはどうすればよいですか？
バックドアを評価するためにコードレビューが必要なコードベースがあります。
コードは大きすぎてすべてを確認できません。問題への取り組みをどのようにすすめますか。
これは、Java Oracleデータベースを備えたWebアプリケーションであり、非常に大きな製品からコードがカスタマイズされています。
カスタマイズはほとんどすべてのコードベースをカバーしますが、カスタマイズされたコードを自動的に識別できます。
私は構造の概要から始めます-設計の観点から、コードの個別の部分は明確に定義されていますか？たとえば、コードベース全体でそれらの目的に使用される検証コード、入出力関数などがありますか、それともすべての関数が個別のものですか？機能的に安全なコードはありますか（多くの場合、特定のスタイル構造はデータフローのセキュリティに影響を与えません）
すべての関数に対して認証を実行するセキュリティラッパーがある場合、それらの関数のレビューを簡単に確認して、たとえばラッパー関数の使用を確認することができます。
それが非常に大きなコードベースである場合、Fortifyなどのツール（または@AviDが名前を付けることができる他のツール）を実行して、問題の最初のパスを作成する必要がありますが、すべてのツールが不足しています。コンテキストインテリジェンス。彼らは典型的なシグネチャに基づいて識別するので、偽のポジティブ（そしておそらく偽のネガティブ）を取得します-これは、適切な概要を持つことがツールが見つけられないリスクを特定するのに役立つ理由です）
ツールは比較的リスクが低いため、ツールは考えられるリスク領域を絞り込み、大多数の問題を識別し、人間がツールの出力を検証して追加し、アプリケーション環境のコンテキストに配置するという考え方です。
過度に商業的であると思われるリスクがあるので、コードレビューツールを熟知しているだけでなく、Java + Oracleに精通しているだけでなく、ビジネスの経験がある人でもある経験豊富なセキュリティコンサルタントのサービスを使用することをお勧めします。およびセキュリティリスクベースのアーキテクチャ。
一番下の行：あなたはねじ込まれています。開発者の1人が意図的にそのコードベースにバックドアを隠したと懸念している場合、バックドアが存在するかどうかを伝える現実的な希望はありません。人生は最低だ。
コメント：ここの一部の人々は、コードを確認するか、静的分析ツールなどを使用して、バックドアをチェックできると提案しています。信じてはいけません。これが意図的に隠されたバックドアを検出する可能性が高いと考えている場合、彼らは自分をだましています。私の意見では、これらの回答は過度に楽観的であり、誤った安心感を与える可能性があります。 （私はこれを言って他のコメンテーターを否定することで自分を不人気にするつもりですが、私はあなたに私の正直で率直なアドバイスを与える責任を感じます。）
アドバイスと緩和策：何をすべきかについては、そのソフトウェアの機能と、それがどのように関連しているかについて、もっと教えていただく必要があると思いますあなたのビジネス、そしてそれがバックドアを持っている場合の結果は何ですか？状況に応じて、考慮すべき一般的な軽減策の一部を以下に示します。
リスク転送サプライヤーに、コードにバックドアがないことの保証を提供するように要求します。 （バックドアが存在する場合、バックドアが発見される可能性は非常に低いため、発見された場合のペナルティは、それを検出する確率の逆数に比例して増加する必要があります。）
分離。バックドアの影響を分離して、このソフトウェアの機能にのみ影響し、攻撃する機会を制限することができます。あなたの他のシステム。仮想マシンで実行したり、ネットワークからファイアウォールで遮断したりできます。また、ネットワークからファイアウォールで遮断して、悪意のある人物がバックドアをアクティブ化するのを困難にすることもできます。
監視。場合によっては、外部監視を実行して不正なアクティビティを検出できる可能性があります。たとえば、スロットマシンジョイントでは、取り込んだ金額、支払った金額を監視できます。統計的には、これら2つは強い関係にあるはずです。予想額を5標準偏差以上超えるペイアウトが見られる場合、それは心配する良い理由かもしれません。別の例として、銀行では、複式簿記を使用して、消費者の苦情の割合や消費者が異議を唱える頻度などのいくつかの集計メトリックを追跡できる場合があります。これらの種類の監視手法は特定のビジネスに非常に固有ですが、潜在的に悪意のあるものを検出するのに効果的です。
これらはいずれも、意図的なバックドアに対して本当に優れた防御を提供する可能性は低く、特定の状況に適用できる場合とそうでない場合がありますが、運が良ければ、何もしないよりはましです。
@Roryはかなりカバーされていますどのようにレビューを始めるか...
単に「バックドア」だけでなく（@ VP01が彼のコメントで述べたのと同じように）、あなたが探しているものを知っているべきだと付け加えます。
例えば。あなたはそうするバックドアを探していますか？
- 認証バイパス（特別なIDまたはスーパーパスワードを使用）;
- 魔法のパラメータ（ala "？admin = 1"）;
- ペニー盗み（スーパーマン3のように）;
- 情報を盗む（例：バックエンドでクレジットカード番号をメールで送信する）;
- ...何か他のもの。
探しているバックドアのタイプがわかっている場合は、何百万行ものコードのそれぞれに等しく集中する必要はなく、優先順位を付けることができます。
また、人間の知能に基づいて定義したバックドアの特定のタイプの検索をサポートするなど、非常に豊富にスクリプト化できる自動化ツールがいくつかあることも付け加えておきます。コンテキストは、何百万ものLOC全体に適用されます...
追伸あなたはこれらの関連する質問のいくつかに興味があるかもしれません：
Roryの答えはカーネルに影響を与えると思いますが、ここではタイミングが非常に重要です。その後コードレビューを行うには、コードはすでに巨大で、文書化が不十分で、テストが不十分で、本番環境で（ここでそうであるかどうかはわかりません）は、すでに「遅すぎる」ため、正しく実行できません。最高のツールとJava/Oracleを使用しても、外部アナリストはビジネスロジックの欠陥を理解するのが難しくなります（故意にそこに植え付けられました）。私の意見では、最初からのコード分析は進むべき道です。
使用される言語に関係なく、すべてのアプリケーションレビューに共通するいくつかの方法があります。ここにいくつかのヒントがあります：
- 大きなコードの変更を監視するには、差分ツールを使用できます（私がここで述べたように Code Review Strategies ）;
- 疑わしいネットワーク要求をログに記録して確認できるように環境をセットアップします。
- 非常に簡単な方法は、「grep」のようなツールを使用することです-いくつかの基本的で明白な悪意のあるコードに役立ちます。