品質コード：データ検証が必要

-555流域に関する投稿のコメントで生じた議論は、ユーザーから受け取った不正なデータにどのように反応するかが誰にも明らかではないことを示しています。





一方、さまざまなXSSと同様に負の量の商品の例は、SQLインジェクションはすべて「セキュアプログラミング」として知られるアプローチを必要とする特別なケースです。



このトピックは、専門文献で頻繁に広範に議論されています。たとえば、S。McConnellによる「Perfect Code」（コード完了）、第8章「Defensive Programming」を参照してください。



この本から小さな引用をします（誰かがそれを読んでいないなら、私はそれをお勧めします）：

防御的プログラミングは、「そのように機能する！」という言葉でコードを保護することを意味するものではありません。その考えは、他のドライバーのトリックに備えて慎重に運転するという考えと一致します。 他のドライバーが責任を負う場合、あなた自身の保護に責任を負います。

防御的プログラミングでは、主なアイデアは、誤ったデータがメソッドに送信された場合、別のプログラムの障害によりこのデータが破損しても、その動作は中断されないということです。 要約すると、プログラムには常に問題があり、プログラムは常に変更され、合理的なプログラマーはコードを開発する際に常にこれを考慮します。

この章では、不正確なデータ、決して起こらないイベント、その他のプログラミングエラーの冷酷な世界から身を守る方法を説明します。 経験豊富なプログラマーであれば、入力データの処理に関する次のセクションをスキップして、セクション8.2に進み、ステートメントについて説明します。

8.1。 不正な入力データからプログラムを保護します。

学校で「ゴミを入れて、ゴミを入れて」（「ゴミを入れて、ゴミを入れて」）という表現を聞いたことがあるかもしれません。 これは、ソフトウェア開発者から消費者への警告です。ユーザーに注意してください。



産業用ソフトウェアの場合、「ガベージイン-ガベージイン」の原則はあまり適していません。 良いプログラムは、入力に何があっても、決してゴミを出しません。 代わりに、「入力のガベージ-出力には何もありません」、「入力のガベージ-出力にエラーメッセージ」、または「入力のガベージは許可されません」という原則を使用します。 今日の標準では、「ガベージイン-ガベージイン」は不注意で安全でないコードの兆候です。



入力されたジャンクデータを処理するには、以下の3つの主な方法があります。



外部ソースからのすべてのデータを確認します

ファイル、ユーザー、ネットワーク、またはその他の外部インターフェイスからデータを受信した後、すべての値が許容範囲内に収まることを確認してください。 数値データに有効な値が含まれていること、および文字列が処理に十分な長さであることを確認してください。 行に特定の値セット（金融取引識別子など）が含まれている場合は、この場合、この値が有効であることを確認し、そうでない場合は拒否します。 セキュリティを必要とするアプリケーションで作業している場合は、システムを攻撃する可能性のあるデータに特に注意してください：バッファーオーバーフローの試み、埋め込みSQLコマンド、埋め込みHTMLまたはXMLコード、整数オーバーフロー、システムコールに転送されるデータなど。 n。



メソッドのすべての入力パラメーターの値を確認します

メソッドの入力パラメーターの値の確認は、外部ソースからのデータの確認とほぼ同じです。ただし、すべてのデータは外部インターフェースからではなく、別のメソッドからのものです。 セクション8.5では、入力をチェックするメソッドを決定する方法を学習します。



間違った入力を処理する方法を決定します。

間違ったパラメーターを見つけたらどうしますか？ 状況に応じて、セクション8.3で詳細に説明されている多数のアプローチのいずれかを選択できます。



保護プログラミングは、この本で説明されているプログラムの品質を向上させる他の方法に役立つ追加機能です。 安全にエンコードするための最良の方法は、最初にミスをしないことです。 反復設計、コーディング前の擬似コードとテストの記述、およびプロジェクトへの準拠の低レベルの検証のみが、欠陥の追加を回避するのに役立ちます。

検証メカニズムは異なる場合があり、データ/言語/ライブラリ/フレームワークなどのタイプに依存します。 これらは、アサーション、列挙データ型、プロパティなどです。 主なことは、アプリケーションアーキテクチャでは、検証はデータ処理プロセスから論理的に分離された不可欠な要素であるということです。



ユーザーインターフェイスを介して受信した誤ったデータに対する反応については、私の意見では、ユーザーに正直である必要があります。 存在しない郵便番号、負の量の商品、または自分の電子メールの代わりに間違ったテキストを指定することによって、ユーザーが何を取得したいかを予測しようとすると、自己欺wouldになります。 フォームに記入するときに、訪問者が実際に何を考えたかはわかりません。 ですから、私たちは本当に意味が何を意味していたのかわかりません。

彼はおそらく封印されていて、おそらくある種のカルハッカーがここですべてがどのように機能するかをチェックしたかもしれません。これはインターフェースの間違いです。

いずれにせよ、データ入力中にエラーが発生した場合、プログラムを一時停止し、入力されたデータが正しくないことをユーザーに通知することは論理的です。 （当然、ユーザーが理解できるメッセージについて話します。たとえば、「http / 500、UE throw ... wrong zip ... at class N」の代わりに、「そのようなインデックスとの決済はありません」）。



これにより、インターフェースの「使いやすさ」が低下すると考えられています。 そうではありません。 それどころか、ソフトウェアはユーザーにとっても開発者にとっても、より理解しやすく、予測可能で、安全になります。 これは実際には簡単に確認できます。このようなエラーをログに書き込み、後でその内容を分析するだけで十分です。



プログラムがすべてのコストで実行され続け、誤った値をデフォルトにリセットすることを保証したいという欲求は危険であり、開発者はこの価格がどうなるかをまったく理解していないことを示している可能性が高いです。