2009-05-12 18 views
6

Javaの安全なコーディングが重要な理由を理解できません。たとえば、変数をプライベートに宣言することが重要な理由は何ですか?私は、クラス外からこれらの変数にアクセスすることが不可能になることを知っていますが、クラスを逆コンパイルして値を取得することができます。 同様に、クラスをfinalとして定義すると、このクラスをサブクラス化できなくなります。クラスをサブクラス化すると、セキュリティ上危険ですか?必要に応じて、元のクラスを逆コンパイルし、私が望む可能性のある悪意のあるコードで再実装することもできます。 アプリケーションがユーザーによって信頼されているときに問題が発生しますか?そして、人々はこの信頼をどうにか悪用することができますか? 基本的に私が探しているのは、安全なコーディングガイドラインを守るべき理由の良い例です。Javaセキュアなコーディングが重要な理由は何ですか?

答えて

15

プログラミングが難しいです。

厳密なAPIを定義すると、公開されない変数が公開されます(これはencapsulationと同じです)。APIを使用するユーザーを助け、プログラミングを容易にします。これは良いことと考えられています。

理由は、秘密のものを秘密にしておくこと、明快さ、簡潔さ、わかりやすさのように、主に「セキュリティ」ではありません。

ボーナスとして、APIのユーザーが背中の「自分の」変数を変更していないことが分かっていれば、正常に機能するようにする方がはるかに簡単です。

+1

なぜカプセル化は安全性に関して常に説明されていますか?また、カプセル化によってプログラミングが簡単になるのはなぜですか? – JDelage

4

「安全」とは、クラスの内部作業を誰でも使用することができないことを意味します。

セキュリティ保護という用語は、1つのクラスのユーザーがクラスが自分が望むタスクを実行する方法を心配する必要がないということを意図するために使用されています。

あなたの例を取る:たとえば、あなたがしたくない何かが、ある彼らのexistanceのクラスのノウハウ、のユーザーを聞かせクラスの変数を公開

:あなただけをオンにするボタンを押してくださいあなたが今そこにその仕事を実行するために必要な銅または船乗りがある必要はありません。

+0

面白い!最後に、この文脈での "セキュリティ"の良い説明。 – Jackson

1

他の人が既に言っていることを追加するだけで、これらの機能のいくつかは、単純に意図する方法として見ることもできます。私がメンバーを作る場合private他の人がそれにアクセスすることは「不可能」にします(それは可能ですが、それはここのポイントです)。しかし、もっと重要なのは、これは実装の詳細であり、 。

3

ここには2つの問題があります。

最初は変数をprotectedまたはprivateとして宣言すると、パブリックAPIの一部にはなりません。他のクラスは将来あなたのクラスに依存する可能性があります。新しい機能を追加したり、パフォーマンスを向上させたい場合は、できるだけ自由に変更することが重要です。すべての値が社内のすべての価値観と仕組みは一般に公開されている。それらを変更すると、あなたに依存する他のクラスが壊れる可能性があります。

変数を公開すると、他のクラスで値を変更できるようになります。あなたのプログラムを壊す可能性がある場合、彼らはあなたの内部の値を変更し、予期しない予期しない動作を作成します。クラスの正確なパフォーマンスに依存するシステムを作成し、内部の値が変更された場合、そのシステムに依存できなくなります。サブクラス化すると、これはより複雑になります。あなたのシステムは、期待される行動を実行するためにある種のクラスに頼っているかもしれません。サブクラス化することで、同じタイプであるように見えますが、期待されるアクションを実行しない新しいクラスを作成することは可能です。

たとえば、保護された関数getArea()を持つクラスの正方形がある場合、正方形の領域を返すと予想されます。しかし、正方形に広がる新しいクラスを作ることができます。たとえば、クラスの長方形が正方形に広がっているとします。 RectangleはgetArea()をオーバーライドすることができますが、依然として正方形であるため、squareの機能に依存するものがあります。あなたのクラスを最終的にすることによって、あなたのシステムでこれが起こることは決してないと主張しています。

この種の「安全なコーディング」は、ソースコードの閲覧を妨げることはありませんが、今後コードをより信頼性高く使いやすくするのに役立ちます。

+0

保護された変数はパブリックAPIの一部です。プライベートを使用するか、必要であれば、「パッケージプライベート」のデフォルトアクセス変数を使用します。 –

4

Javaは、object-oriented programming言語であり、オブジェクト指向プログラミングの重要な概念の1つはencapsulationです。

カプセル化の背後にある考え方は、オブジェクトの状態とアルゴリズムなどの内部動作を保持する内部変数などの実装の詳細を「隠す」ことであり、他のオブジェクトが実行するために使用できるインタフェースのみを提供しますオブジェクトとの関数。

この概念を使用して、private変数を使用して内部状態を非表示にして、他のオブジェクトが内部状態に直接影響しないようにしたいとします。 Javaでは、オブジェクトを操作するためにゲッターとセッター(例えば、getColorsetColor)を見るのが一般的です。

また、カプセル化はコードの堅牢性を高めることができます。

たとえば、内部状態へのアクセスを制限することによって、オブジェクトが変更される前にいくつかのサニティチェックを実行することができます。固体例として

0100percent値を有するようであったScoreオブジェクトがあったと言います。指定された値が許容範囲内であることを検証するsetPercent(int)メソッドを提供することにより、Scoreオブジェクトが許容できない状態に設定されるのを防ぎます。

setPercent方法は、エラーが発生したり、指定した値が受け入れられない場合Exceptionを投げるのであれば、直接score.percent = 150のような文を書き込むことによって内部状態を操作しようとする、防止することができました。

1

あなたのオブジェクトにプライベート(非表示)ではない内部プロパティがあり、このプロパティにアクセスするコードがマルチスレッド環境で実行されると想像すると、N個のスレッドが同時にアクセスし始めます。プロパティ、4を読み込みます。物事がきちんと動くかどうかを確認する方法はありません。どちらのスレッドが現在保持しているデータを知っているのでもなく、オブジェクトのプロパティを変更したこともありません。

シンクロナスアクセスの処理に責任を負う特別なコードをプログラムする必要がありますが、プログラムでそのプロパティにアクセスする残りの680クラスをチェックする必要があるため、コードが正常に機能することはありません直接アクセスすることができます。要するに

、あなたは大きな問題であり、およびデバッグは、スレッドがしたデータがchagnedれたときに知らないあなた以来の悪夢であり、そのことが起こったなど

ちょうど1つのシナリオから何あなたがカプセル化しないと起こっている...

あなたのコードは1%速く実行され、スタックにかかる負荷は少なくなります。システムの定期的なクラッシュと成功したデバッグのためのわずかなチャンスで、おそらく無視できるほどのパフォーマンスの向上が得られます。

1

「安全なコーディング」とは、C、Java、Ruby、アセンブリ言語などのセキュリティ脆弱性を回避しようとするソフトウェアの構築を指します。おそらく、安全な言語システムを選択した後の最も重要な部分は、良いプログラミング実践を続けることです。プログラムが不明瞭な場合は、それが自信を持っている可能性はほとんどありません。 2年前に更新

  • Secure Coding Guidelines for the Java Programming Language, version 2.0.、更新の必要がある:Java用の

    は注目に値する二つのガイドがあります。
  • The CERT Sun Microsystems Secure Coding Standard for Java. CERTとSunの両方でサポートされている新しいWikiは、気持ちが変わっても更新が可能です。これは、サンのガイドラインよりもはるかに広い視野をとっています。たとえば、Sunのガイドラインでは、すべての配列の境界がチェックされているので、整数オーバーフローは実際には関係しませんが、プログラムのエラーを引き起こす可能性があるため、wikiは行います。

セキュアなコーディングには2つの異なるモードがあります。

あなたは、あなたのコードが持つすべての特権を持っていない可能性があるコードを扱っています。たとえば、ライブラリや署名コードを書いている場合は、これを行う必要があります。悪質なコードが意図しない方法でアクセス許可を利用することは不可能です。これは難しいです!

もっと一般的には、信頼できないデータのみを扱うプログラムを扱っています。たとえば、信頼できないファイルを処理するWebサーバー(XSSとSQLインジェクションと考える)とデスクトップアプリケーションプログラム(通常はCのコードがバッファオーバーフローを起こしています - 純正のC++が優れています)。 DoS(サービス拒否)は、状況によっては深刻な問題になることがあります。

重複があります。例えば、インタプリタはインタプリタコードのパーミッションで実行され、かなり強力なものです。

関連する問題