.
数年前、私が愛用していたオンライン ゲームのサーバーが数日間ダウンし、ゲーム内のキャラクターがすべての成果とともに失われて死んでしまうのではないかとすでに恐れていました。 幸いなことに、彼らは問題を解決し、数日後にはすべてが再びオンラインになりました。 私はこの種の次の事件に備えたかったので、Web サイトにログインし、キャラクターのすべてのプロパティのスクリーンショットを作成しました。
一瞬、嬉しかったです。 次回は、たとえすべてのデータが失われたとしても、自分が勝ったことを証明でき、すべてのものを取り戻すことができます。 次に、スクリーンショットを見て、同様に簡単にスクリーンショットを変更して、さらに優れたゲーム内アイテムを入手できることに気付きました。 したがって、基本的には無価値でした。 自分でデジタル署名しても改善されません。
このシナリオはオンライン ゲームに限定されません。 命令が出されたこと、違反が行われたこと、または何らかの任務が遂行されたことを証明できることは、一般的な検討を行う価値があると思われます。
明らかに、そのようなスクリーンショットを自分で作成して署名することはできません。 信頼できる第三者の助けが必要ですが、多くの場合、問題はあまりにも些細すぎて、「現実世界」の弁護士に関与したり、弁護士にお金を払ったりすることさえできません。 最初に考えられるのは、archive.org などの Web アーカイブ サイトにそのページのコピーが偶然存在するかどうかを確認することかもしれません。 多くの場合、そうではありません。 たとえそうだったとしても、ログインによって保護されている部分にアクセスすることはできません。
ログインプロセスのステップを習得できる自動ツールは存在せず、Web サイト所有者がキャプチャの使用を検討したとしても、プログラムがキャプチャをバイパスできる可能性はほとんどありません。 これは手動で、または Web ブラウザを使用して行う必要があります。 そのため、プラグインを使用して、サーバーから送信されたすべてのデータを保存し、デジタル署名しようとする人もいます。
繰り返しますが、これは解決策ではありません。 マシン上の DNS やルーティングを操作して、別のコンピュータや仮想マシンに「サーバー」の役割を持たせることは比較的簡単です。 ブラウザは SSL と証明書を使用してこの種の詐欺から保護しますが、これは暗号化されたトラフィックにのみ適用され、中間者操作を許可するために独自の「ルート証明書」をインストールすることが一般的です。
使用されているキーを注意深く確認すると、そのような手口が見つかる可能性があります。 送信されるすべてのデータが RSA などの非対称コードで暗号化されている場合は、発信元のサーバーによってすでに署名されていると見なすこともでき、問題はほぼ解消されます。 ただし、SSL ではパフォーマンス上の理由から、非対称方式はより高速な対称暗号化のためのキー フレーズを送信するためにのみ使用されます。 そのため、実際に送信されたデータの暗号化コードのログを偽造することは、クライアントがその対称キーを知っているため、理論的には可能です (ただし、おそらくプラグインのリバース エンジニアリングよりもさらに難しいでしょう)。
これらすべての問題を回避するには、ブラウザを自分のコンピュータで実行しないでください。 必要なのは、高度なセキュリティ施設でまったく別の理由で使用される、いわゆる「リモート制御ブラウザ」(ReCoBS) です。 これは別のコンピュータ上で実行され、サードパーティによって制御されるブラウザであり、ウィンドウのビデオ ストリームのみをクライアントに送信し、限られたコマンド セットのみを受け入れます。 このリモート ブラウザは、ユーザーが操作できないため、すべてのログ記録と署名の操作を実行できます。
このシステムに対するどのような攻撃経路を考慮する必要がありますか? まず、実際に ReCoBS 全体をハッキングする可能性があります。 ブラウザがリモートの未知のユーザーによって制御されること自体がリスクを引き起こします。 ブラウザは厳重にロックされたサンドボックス内で実行する必要があり、システムをハッキングから保護するだけでなく、同じコンピュータ上の並行セッションまたは後続のセッション間の相互依存を防ぎます。
Web セッションの結果を偽装する場合、DNS キャッシュ ポイズニングが最も危険なオプションであると思われます。 これは、DNSSEC が Web 全体に及ぶ場合には DNSSEC を使用することによって、あるいはおそらく世界中にマシンのネットワークを構築し、ランダムなリクエストによって DNS リクエストをルーティングすることによって対処できます。 訪問した Web サイトへのスクリプト インジェクションは、操作された結果を得る 2 番目の方法ですが、インジェクションが第 4 パーティからのものである場合、ReCoBS による有効な対抗策はあり得ず、そもそもそのような攻撃に対してオープンであることの方が大きな問題になるはずです。これにより作成されたログよりも影響を受けるサイトに送信されます。
これらの問題を考慮しても、ReCoBS が少なくとも理論的に信頼できる証拠の可能性を提供する唯一の選択肢であるように見えます。 正しく実装されていれば機能する可能性があります。 他のほとんどのテクノロジーには設計上の欠陥があり、エクスプロイトが公開されるのは時間の問題です。
.
