CLRがバッファオーバーフロー攻撃を防ぐため、.Netプラットフォームの方が安全であると言うのは正しいですか?
管理対象OS( Cosmos、SharpOS、Singularityなど)で実行されているWebブラウザーがあったとすると、攻撃者がアプリにILコードを挿入することは技術的に可能でしょうか?
管理されていないアプリでは不可能な攻撃について心配する必要がありますか?
CLRがバッファオーバーフロー攻撃を防ぐため、.Netプラットフォームの方が安全であると言うのは正しいですか?
管理対象OS( Cosmos、SharpOS、Singularityなど)で実行されているWebブラウザーがあったとすると、攻撃者がアプリにILコードを挿入することは技術的に可能でしょうか?
管理されていないアプリでは不可能な攻撃について心配する必要がありますか?
ほとんどの場合、あなたは正しいです。安全な型システム(.NETやJavaだけでなく)を備えたアプリケーションは、アプリケーションがこれらの制約に違反することを許可しません。
これらの言語とランタイムの制約はチェックを提供せず、プログラムがメモリ内で任意のコードを実行するようなことをしないことを保証できないため、バッファオーバーフローや他の多くのリモートコードエクスプロイトが発生します。安全なシステムは、コードにこれらの影響がないことを確認します。
(補足として、C#は依然として安全でないアクションを実行し、任意のコードを実行するように設定することができます。これはかなり面倒で、実際のアプリケーションで使用される可能性はほとんどありません。)
マネージドブラウザに見られるセキュリティホールは、CLRを安全な環境として使用して、任意のコードをロードできるようにする場合です。CLRで生成されたコード(つまり、アプリケーションのJIT)は安全ですが、ローダーとベリファイア自体は通常、より低い言語で記述されています。悪意を持って形成されたアセンブリが実際のCLRに任意のコードを実行させる可能性のあるセキュリティホールがいくつかあります(.NETの場合は2つだと思いますか?)。ただし、これらは比較的まれな問題であり、表面積はそれ以外の場合よりもはるかに小さくなります。
したがって、はい、完全に安全な管理されたブラウザ自体は、これらの特定のエクスプロイトの餌食にはなりません。しかし、それはまた、プラグインを同様の方法で記述して実行する必要があることを意味します(Flash?)。最後に、標的にできる他のセキュリティホールがありますが、通常、それらは管理されていないアプリケーションで見られるよりも深刻ではありません。たとえば、クロスサイトスクリプティングは依然として問題です。しかし、少なくとも「ドキュメントを表示すると任意のコードを実行できる」タイプの問題は発生しません。
CLR(およびJVM)は、多くの一般的な攻撃を防ぎますが、すべての脅威を排除するわけではありません。CLRまたは任意のライブラリには、エクスプロイトを可能にするバグが含まれている可能性があります。アプリケーションエラーにより、エクスプロイトも発生する可能性があります。SQLインジェクションは、アプリケーションの入力検証が不足しているために発生する可能性のある攻撃の例です。