なぜこんなにたくさんのJava=不確実性について聞いているのですか？他の言語の方が安全ですか？
私はJavaプログラミング言語が本当に好きですが、それがどれほど安全でないかについて絶えず聞いています。「Javaの安全でない」または「Javaの脆弱性」をググリングすると、なぜアンインストールまたは無効にする必要があるかについて話している複数の記事が表示されます= Javaお使いのコンピュータを保護します。Javaは、一度に膨大な数のセキュリティパッチをリリースすることがよくありますが、それでもなお、パッチを当てるべき脆弱性がたくさん残っています。
ソフトウェアには常にバグが存在することを理解していますが、脆弱性の量Javaが持っていたものは正常ではないように見えます（または私はそれを想像していますか？）。さらに混乱があるのは、これらの脆弱性を生み出している単一のアーキテクチャ上の決定、その設計を変更してみませんか？この問題がない他のプログラミング言語がたくさんあるので、何でもできるより良い方法があるはずですJava =は間違っています。では、なぜJavaがまだ安全でないのですか？
他のほとんどのプログラミング言語と同様にJavaを使用する場合、たとえばスタンドアロンアプリケーションを作成する場合、バッファオーバーフローがないため、他の言語よりも安全であり、CまたはC++よりも安全です。
ただし、JavaはWebブラウザー内でプラグインとして定期的に使用されます（例：Flashと同様）。この場合、ユーザーは明示的にインストールせずに信頼できないコードを実行するため、コードを実行することが考えられます。限られたサンドボックス内で、システムまたはユーザーに対して何らかの方法で動作できないようにする必要があります（たとえば、ローカルファイルを読み取り、それらをWebサイトに送信し、ローカルネットワークをスキャンするなど）。これがJava近年失敗しました。たとえば、サンドボックスからの脱出を可能にする毎日新しいバグが時々ポップアップしました。
また、バイトコードインタープリタまたはネイティブライブラリのバグが原因でバッファオーバーフローが発生し、システムが危険にさらされることもありますが、この点に関しては、Flashの方が通常は悪いと考えられています。
他の言語の方が優れています。これらは通常、サンドボックス内で信頼できないコードとして実行することもできません（例外はJavaScriptで、おそらくFlashです）。したがって、システムとの対話を制限する固有の方法がないため、さらに悪いでしょう。 。
報告されたセキュリティの脆弱性はJava（プログラミング言語）に関するものではなく、JVMが メモリの安全性 を強制しているため、実際には、CやC++などの言語よりも堅牢であり、バッファオーバーフローやバッファオーバーリードは依然として脅威であり、Heartbleedのような混乱を引き起こす可能性があります。
代わりに、報告された脆弱性はJavaサンドボックスにあります。サンドボックスは、信頼できないコードの安全な実行を許可する特権モデルを適用しようとし、Javaの自動実行を許可するために最も有名に使用されますブラウザのアプレット。そのサンドボックスは穴だらけです。また、Oracleはパッチ（「重要なパッチの更新」）を年に4回だけリリースします。言うまでもなく、ブラウザベンダーはこれに満足していません。たとえば、Firefoxでは Firefox 26以降、Javaアプレット を起動するためのユーザー認証が必要です。
プレスレポートがその区別をしない理由は、Oracleがプログラミング言語と アプレットを実行するブラウザプラグインの両方に「Java」の商標を使用しているためです 。実際、一般ユーザーがJava商標に出会った場合、おそらく後者を指します。
サンドボックスが脆弱なままである理由は、いくぶん推測的です。私に尋ねると、1つの理由は、サンドボックスの有無にかかわらず同じAPIが使用され、ほとんどのJavaコードがサンドボックスなしで実行されることです（コードが信頼されているため）。その結果、Java APIまたはその実装を変更するときに、開発者がそのあいまいな機能を忘れて、誤って保護する必要があるものを公開してしまう可能性があります（簡単さを説明するために、 Java SE のセキュアコーディングガイドライン。もう1つの関連する理由は、Java API（ 5800クラスと50,000近くのメソッド、Java SE 6 ）。
この問題がない他のプログラミング言語はたくさんあります。そのため、Javaが間違っていることを何でも行うためのより良い方法がなければなりません。
それはかなり高い主張ですが、どこでその印象を得ましたか？ Javaと同じペースで進められていないか、ユビキタスに使用されている「他のプログラミング言語のトン」があります。
原則として、非常に多くのセキュリティパッチがある理由は、Javaが他の言語にはない多くのセキュリティ重視の機能を備えて安全に設計されているためです。
Java言語環境
1.2.2堅牢で安全
Javaテクノロジは分散環境で動作するように設計されているため、セキュリティが最も重要です。言語とランタイムシステムに組み込まれたセキュリティ機能を備えたJavaテクノロジーにより、外部から侵入できないアプリケーションを構築できます。ネットワーク環境では、Javaプログラミング言語は、舞台裏に侵入してウイルスを作成したり、ファイルシステムに侵入しようとする不正なコードによる侵入から保護されています。
プログラミング言語の仕様に「セキュリティで保護された」を含めない場合、セキュリティパッチをリリースする必要はほとんどありません。一方、それがあなたの表明した目標の1つである場合、あなたはハードプレッシャーになりますしないでください。
Javaはそれ自体、セキュリティ、つまりバッファオーバーフローとメモリ管理エラーへの固有の耐性という点で優れた資産です。
すべての配列アクセスは、割り当てられた配列の長さに関してチェックされます。したがって、バッファオーバーフローは確実にトラップされ、例外がトリガーされます。これにより、リモートコード実行の脆弱性が単なるサービス拒否に変わります。
メモリの割り当ては、ガベージコレクタを介して管理されます。これにより、解放後使用および二重解放エラーが防止されます。また、GCを使用すると、文字列（Javaでは文字列は不変）を簡単に処理できるため、バッファオーバーフローのバグが発生する可能性がほとんどなくなります。
厳密なタイピングが強制されます。コードは、そうでないデータバイトにアクセスできません。これもまた、脆弱性を防ぎます（データ型が違反されたバグは、コンパイル時に、または最悪の場合、ランタイム
ClassCastExceptionとして報告されます）。
これにより、セキュリティに関して、Java多くのより強力な（多くのプログラミング言語（特に、地獄のカップルC/C++））よりも強力になります。
ただし、Java設計者は、この強化されたセキュリティを利用して、何か applets を作成しようとしました。問題はattack surface：アプレットは潜在的に敵対的なコードであるため、実行するすべてのことを制御する必要があります。しかし、敵対的なコードは、「標準Javaクラス」を使用できる必要があります。すべての標準Javaクラスに「コントロールポイント」を適用する必要があります。したがって、攻撃対象は数千のメソッドを含む数百のクラスで構成され、すべてが適切なチェックを実施する必要があります。
Javaデザイナーは野心に罪を犯しました。何もせずに何千ものチェックを実装することの難しさは、彼らが想像していたよりもはるかに高かったです。すべての「Javaバグ」はこの事実に起因します。
ここでは、JavaとJavascriptを比較できます。たとえば、Javaはディスク上のファイルへのアクセスを許可しますが、この権限をアプレットに付与することはできません。ただし、アプレットはそれを要求し、ユーザーは同意します（これはアプレット署名ビジネス全体を必要とします）Javascriptはそれほど野心的ではなく、単にファイルアクセスメソッドが欠けています。
要約すると：Javaは問題なく安全です。Javaappletsは、セキュリティを確保するのが非常に難しい巨大な攻撃面を意味します。ただし、スタンドアロンのアプリケーションとサーバーでは、Javaを使用することをお勧めします。セキュリティが必要です（これはC＃にも同様に適用されます）。
最近、より多くの脆弱性を見つけても、ソフトウェアがどれほど安全でないかを示すものではないかもしれません。問題は、各ソフトウェアベンダーのセキュリティレスポンスチームがそれにどのように反応するか、そしてパッチがどれだけ早くリリースされるかです。
FirefoxとChrome=にパッチが適用される速度を確認してください。多くの脆弱性がそれらにも発見され、解決されています。
私が覚えているように、Oracleには、重要なパッチ更新（CPU）と呼ばれるプログラムがあり、四半期ごとに多くのパッチを提供します。また、 ゼロデイ脆弱性 がある場合、CPUなしでパッチをリリースします。しかし、問題はOracleがパッチをリリースするのにかかる時間です。
過大評価の恐怖.. Java自体は問題ありません。問題はWebブラウザ内で実行されている旧式のJavaアプレットで発生しますが、実際にはもう誰もがアプレットを作成しているとは思いません。ほとんどの開発会社がFlashまたはHTML4を使用しています。/5少なくとも過去10年間のフロントエンドWebインターフェース。
最近Javaは、主にバックエンドJEE、フロントエンドGUIクライアント（JFX/AWT/SWING）、コンソールアプリ、およびモバイルアプリで使用されるため、問題はありません。