実行中に出力ファイルを削除したり、sw の 2 つのインスタンスを同じ IO に転送したりしますか?
7 に答える
ユーザーがそれを行うのを防ぐためにできることはあまりありませんが、できることは防御的プログラミングを適用することです。
あなたの2つの例では、リソースにアクセスするたびに、障害状態を検出し、例外をスローして終了するか、そのリソースにアクセスせずに続行するかのいずれかで適切に対応する必要があります。
リソースの割り当てが成功すると仮定しないでください。制御できないことを常に確認してください。要するに、できるだけ仮定を少なくして、すべてを検証してください。
「このファイルにアクセスして書き込むように言われました。すでに開いていますか?権限はありますか? 期待される形式を持っていますか?ディスクに十分なスペースがありますか? 等。'
これについては他にもたくさんあります。防御的プログラミングについてはGoogleだけで、多くのことを読むことができます.
各テキスト ボックスまたは UI の編集コントロールに最大入力長を配置します。無効なデータを入力してテストし (例: 数値が期待される編集内のテキスト)、その種の入力をチェック/処理する一般的な方法を導入します。
また、検索語による SQL インジェクション攻撃についても考えてみてください。例: 姓が ___ で、ユーザーが「*smith」と入力する人を探します。select * from users*". データベース層はそれで何をしますか?
ユーザーが入力したデータがユーザー (またはさらに悪い場合は他のユーザー) に表示される場合は、表示時に UI を悪用する可能性のあるマークアップまたは制御シーケンスをデータに埋め込むことができるかどうかを確認してください。
ターゲットにしている OS と言語はわかりませんが、実行するために必要な最小限の特権をアプリケーションに与えることを検討してください。たとえば、.Net では、宣言型のセキュリティ属性を見てください。これは、攻撃者がアプリの制御を取得した場合に、攻撃者がアプリでできる損害が少なくなることを意味します。
意図的に不適切な入力を使用して単体テストを作成し、アプリケーションがそれに対処できることを確認します。
何も仮定しないでください。毎回、IO を使用するすべての操作を確認します。ビルトイン チェックを使用して、IO 用にソフトウェアに追加のレイヤーを配置します。
ここにはいくつかの良い答えがありますが、何に対して防御するかを検討する必要があると思います.
そのプログラムは、それを使いたい人に使われるつもりですか? もしそうなら、あなたは破壊工作よりも愚かさから(現実的な範囲で)防御する必要があります。それでもすべての入力をチェックしたいのですが、ユーザーが愚かなことをした場合、最適とは言えない結果が得られるのは理にかなっています。ユーザーがシステムにアクセスできる場合、出力ファイルの削除などを防ぐことができない可能性があるため、それをコーディングすることはできません。トレーニングの問題だけのものもあります。
プログラムは、パンチインとパンチアウトを記録するタイムレコーダーアプリケーションなど、それを望まない人々によって使用される予定ですか? 誰かが物理的なセキュリティ (商用バージョンは悪用に耐えられるように設計されています) とソフトウェアのセキュリティ (誰も時間を変更できないようにするため) を考慮する必要があります。非常にシンプルなインターフェースを提供し、入力を詳細にチェックする必要があります。
ユーザーの悪用をシミュレートする優れたテスターを周りに配置するのはどうですか?
VirtualPCの下で信頼できないものを実行している人がいると聞いたことがあります。これにより、基本システムが何があっても損傷を受けることはありません。
これは難しい質問です。ユーザー (愚かなユーザーでも) は、あなたが考えもしなかった方法でアプリケーションを賢く使用することができます。
私は防御的プログラミングの大ファンです (前述の Vinko による)。ハザード分析の観点からアプローチできます。アプリケーションが使用および変更するリソース (ファイル、デバイス、データなど) を確認し、それらのリソースで何が問題になる可能性があるかをブレインストーミングし、それを回避する計画を立てます。
たとえば、専用のハードウェア リソースがあり、アプリケーションの複数のインスタンスがそれぞれそのリソースに対して競合する場合、ユーザーが複数のインスタンスを実行できないように、アプリケーションのシングルトン パターンを強制できます。
これにはすべて、少しの計画と作業が必要ですが、それが私たちが支払われるものです:)