Javaでの脆弱性の悪用
私はJavaに精通していないので、これは愚かな質問かもしれません。
Cプログラムでは、バッファオーバーフローが見つかるか、カスタムコードを実行するためのROPベースのエクスプロイトである可能性があります。 Javaのコンテキストではどのように行われますか？それも可能ですか？ Java文字列または他のデータ型はすべて制限されているため、メモリの上書きは不可能です。ROPの種類の攻撃はどうですか？
または、より一般的には、Javaプログラムの典型的な攻撃ベクトルは何ですか？
Javaの単純なコーディングエラーを介してコードを直接実行できるケースを見つけることができれば非常に幸運です。 JVMの実装にバグがあると、無害なコードによってメモリが破損する可能性がありますが、最悪の場合はまれです。
ただし、JRE（OpenJDK）内でもライブラリの一部はCで記述されているため、信頼できないデータで使用すると、メモリ破損の脆弱性が含まれます。悪意のあるJPEGのレンダリングは、標準的な例です。
インジェクション（HTML、SQL、LDAP、HTTPヘッダーなど）など、メモリに関連しない多くのバグがありますが、それらは一般的にリモートコード実行に直接つながりません。
あまりにも一般的な状況は、便利なライブラリが、アプリケーションプログラマーによって意図的に有効にされることなく意図的にリモートコードを実行する場合です。セキュアコーディングガイドラインのJava SE（5.0） ガイドライン3-8/INJECT-8：信頼できないコードの解釈に注意 の例は、スクリプトAPIの特定の機能です、LiveConnect、XSLT拡張機能、JavaBeansコンポーネントの長期永続性、Javaサウンド、RMI、LDAP、および特定のJDBC/SQL実装。アプリケーションがモバイルコードを意図的にロードする可能性があり、それが他の世界全体につながる。
短い答えは「残りすべて」ですが、生のメモリバッファオーバーフローの悪用による単純化した種類のエラーは含まれません。バッファをオーバーランせずにメモリが誤って使用される可能性がある他の多くの方法があります。
Javaでバッファオーバーフローの問題として分類される可能性があるものの例は、アプリケーションが試行/キャッチを使用して、試行されたバッファオーバーフローをインターセプトし、それをキャッチした結果、いくつかの重要なコードをバイパスした場合です。文字数が多すぎるパスワードを与えられた場合に「success」を返すことになった、不適切に記述された「checkpassword」関数を想像できます。
1つのオプションは、JVM自体を悪用することです。Javaコードにより、実際の仮想マシンが「破壊」され、サンドボックスの外部で任意の操作が実行される可能性があります。このような悪用が行われています。 Java実行のためのコード（つまり、ブラウザのサンドボックスコンテキストで））を犠牲者に送信することに依存しているようですが、ランダムなJavaプログラムを悪用していません。
別のオプションは、プログラムのロジックの問題を特定して悪用することです。 Cのエクスプロイトでは、典型的なシナリオは、特定のチェックに関係のない完全に未定義の動作（任意のコードの実行など）を取得する方法として不良境界チェックを使用することです。ただし、それがない場合、some境界チェックが正しくないか、論理の問題が原因で、（意図せずに）元のコードにあり、希望どおりのコードパスが得られる場合があります。
そしてもちろん、マルチレイヤーアプリの複雑さのすべての喜びには、攻撃ベクトルの可能性があります-SQLインジェクションがJavaアプリがデータベースにリンクしている場合など）.
一般的なJavaセキュリティ上の欠陥には以下が含まれます：
- インジェクション攻撃-SQLインジェクション、クロスサイトスクリプティング、XPathインジェクション、XML外部エンティティなど。私は約20種類の注射を知っています。
- ビジネスロジックの欠陥-パラメータの改ざん、強制的なブラウジング、負の数の受け入れなど.
- 認証とセッションの欠陥-アカウントのロックアウト、セッションの固定、予測可能なセッションIDなどはありません。
- その他-情報漏えい、実行ファイルのアップロードなど.
今述べた欠陥は、Javaアプリケーション自体に当てはまります。一般的なシナリオは、Java Webアプリケーションであり、悪意のあるWebクライアントによって攻撃される可能性があります。 JVM自体は100％安全です。アプリケーションには独自の弱点があります。
別のシナリオはJavaアプレットです。これは実際には非常に異なる状況です。信頼できないJavaアプレットがブラウザのサンドボックス内で実行されており、ここでは、JVM自体のセキュリティが重要です。