問題タブ [defensive-programming]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
7 に答える
531 参照

security - Webアプリケーションの攻撃であり、防御方法が必要です

XSSSQLインジェクションサービス拒否などの一般的なWeb攻撃に対する防御方法は何ですか?

編集:ウィキペディアからの説明の下であなたの回答を集めました。そして、完全なリファレンスを得るためにいくつかの質問を追加します。

SQLインジェクション

SQLインジェクションは、アプリケーションのデータベース層で発生するセキュリティの脆弱性を悪用するコードインジェクション手法です。この脆弱性は、SQLステートメントに埋め込まれた文字列リテラルのエスケープ文字に対してユーザー入力が誤ってフィルター処理されているか、ユーザー入力が強く入力されていないために予期せず実行された場合に発生します。これは、あるプログラミング言語またはスクリプト言語が別の言語に埋め込まれている場合に発生する可能性がある、より一般的なクラスの脆弱性のインスタンスです。

  • ユーザー入力を信頼せず、できるだけ早く検証してください。
  • 生のユーザー入力からSQLを構築しないでください。代わりにパラメーターを使用してください。

クロスサイトスクリプティング(XSS)

クロスサイトスクリプティングは、悪意のあるWebユーザーによる他のユーザーが表示するWebページへのコードインジェクションを可能にするWebアプリケーションに通常見られる一種のコンピューターセキュリティの脆弱性です。このようなコードの例には、HTMLコードやクライアント側のスクリプトが含まれます。攻撃者は、悪用されたクロスサイトスクリプティングの脆弱性を利用して、同一生成元ポリシーなどのアクセス制御を回避できます。

  • ユーザーが送信したコンテンツを逐語的に出力または実行しないでください。
  • すべての出力をHTMLエンコードします。

サービス拒否攻撃

サービス拒否攻撃(DoS攻撃)または分散型サービス拒否攻撃(DDoS攻撃)は、対象のユーザーがコンピューターリソースを利用できないようにする試みです。DoS攻撃を実行する手段、動機、および標的はさまざまですが、一般に、インターネットサイトまたはサービスが一時的または無期限に効率的またはまったく機能するのを防ぐための1人または複数の人の協調的で悪意のある取り組みで構成されます。 。

プログラムでサービス拒否攻撃を回避することは不可能に思えますが、どう思いますか?

ブルートフォース攻撃

暗号解読では、ブルートフォース攻撃は、多数の可能性を体系的に試すことによって暗号解読スキームを打ち負かす方法です。たとえば、メッセージを復号化するためのキースペース内の多数の可能なキー。ほとんどのスキームでは、ブルートフォース攻撃の理論的な可能性が認識されていますが、計算上実行不可能になるように設定されています。

  • あまりにも多くのログイン試行が失敗したときはいつでもアカウントをロックしてください。無制限の再試行を許可しないでください。
  • 入力したパスワードが間違っている場合は、遅延を追加します。

いくつかの追加の質問:

  • コンテンツに応じて入力を投稿しようとするWebロボットについてどう思いますか?たとえば、SOは画像検証を使用しています。

  • javascript eval関数についてどう思いますか?

  • 外部に公開されていないサーバー上のコンテンツにアクセスする方法はありますか?たとえば、いくつかの重要なレコードをデータベースに挿入するページがありますが、それがURLであることを知っているのは私だけです。この種のファイルを取得する方法はありますか?私はあなたがそれにいくつかのセキュリティルールを設定できることを知っています。

注:ディレクトリリストは無効になっており、このファイルをホストしています。)

返信ありがとうございます!

0 投票する
3 に答える
341 参照

c# - 外れ値がデータベースに挿入されるのを防ぐには?

MS SQL DBには、式に基づいて計算された変数のコレクションを表すテーブルのセットが含まれています。すべての変数は、事前に定義された精度の数値です (整数部の n 桁と小数部の m 桁として nm の数値データ型を使用しています)。

私の質問は、列のサイズに違反する外れ値や無効な値を防ぐ方法ですか? 現在、ADO.net が無効な値に対して例外をスローするため、単純な "try catch" を行っていますが、他に良い方法はありますか? さらに、この外れ値に対して、この列に有効な値を設定したいと考えています (つまり、ゼロの可能性があります)。私は C#3、MSSQL 2000 を使用しており、SqlBulkCopyクラスを使用して挿入しています。

PS:DB側またはdotnet側からの解決策について質問しています

0 投票する
3 に答える
547 参照

c++ - カスタム コピー コンストラクターとフィールドの追加

これの複製。

C++ では、コピー コンストラクターを自分で実装する必要がある場合があります (通常、メンバーとしてポインターがある場合)。コンパイラで生成されたコピー コンストラクターでは、メンバー フィールドを追加し、コピー コンストラクターにコピー行を追加するのを忘れた場合に問題が発生し、多くの場合、追跡が困難になるという欠点があります。私は防御的にプログラミングするのが好きで、これは少し心配です。

解決策の 1 つは、memcpy を使用してポインタを適切に処理することですが、これはお勧めできません。

0 投票する
8 に答える
1372 参照

c# - リストへのアイテムの追加/防御プログラミング

C#リストに追加するときにエントリの最大数が2 ^ 31-1(?)に達していないことを明示的にチェック/処理することは、狂気です。

(これは、リストの平均サイズが100未満のアプリであると想定しています。)

0 投票する
15 に答える
1573 参照

defensive-programming - 私のコードはどの程度「防御的」であるべきですか?

私は同僚の 1 人と、コードがどの程度防御的であるべきかについて話し合っていました。私は防御的なプログラミングを得意としていますが、どこでやめるべきかを知っておく必要があります。私たちは他の人によって維持されるプロジェクトに取り組んでいますが、これは、開発者が行う可能性のあるクレイジーなことをすべてチェックする必要があるという意味ではありません. もちろん、それを行うこともできますが、これによりコードに非常に大きなオーバーヘッドが追加されます。

線を引く場所をどうやって知るのですか?

0 投票する
9 に答える
30010 参照

c++ - exeまたはdllで文字列を非表示にする方法は?

ハードコーディングされた文字列をバイナリから抽出できることを発見しました。
たとえば、Process Explorerのプロパティ ビューには、3 文字を超えるすべての文字列が表示されます。

これは、単純にテストするために作成した単純な実行可能ファイルのコードです。

文字列は、対応する実行可能ファイルから明確に抽出できます。
代替テキスト

文字列を見つけるのは少し簡単すぎると思います。

私の質問は次のとおりです。

  1. 実行可能ファイルでhiddenString1またはhiddenString2単純に非表示にする方法は?
  2. あいまいな隠し入力よりも「チートコード」を使用する安全な方法はありますか?
0 投票する
8 に答える
5286 参照

java - clone() は本当に使われたことがありますか? ゲッター/セッターでの防御的コピーはどうですか?

防御的なゲッター/セッターを実際に使用する人はいますか? 私にとっては、99% の確率で、別のオブジェクトに設定したオブジェクトが同じオブジェクト参照のコピーになることを意図しており、それに加えた変更は、それが設定されていたオブジェクトでも行われることを意図しています。あなたsetDate ( Date dt )と後で dt を変更します。誰が気にしますか? プリミティブと Date のような単純なものだけを持つ基本的な不変データ Bean が必要でない限り、私はそれを使用しません。

クローンに関しては、コピーがどれだけ深いか浅いかという問題があるため、オブジェクトをクローンしたときに何が出るかを知ることは、一種の「危険」に思えます。clone()別のスレッド (つまり、セッション内の同じオブジェクトにアクセスする別の HTTP 要求) がオブジェクトを変更している可能性があるため、オブジェクトの現在の状態をコピーするために、1 回か 2 回しか使用したことがないと思います。

編集 - 私が以下に行ったコメントは、より多くの質問です:

しかし、繰り返しになりますが、あなたは日付を変更したので、それはあなた自身のせいであり、「防御的」という用語の全体的な議論です. 小規模から中規模の開発者グループの間ですべてのアプリケーション コードが自分の管理下にある場合、オブジェクトのコピーを作成する代わりに、クラスを文書化するだけで十分でしょうか? または、セッター/ゲッターを呼び出すときに何かがコピーされていないと常に想定する必要があるため、これは必要ありませんか?

0 投票する
6 に答える
1460 参照

c++ - 防御的プログラミングは DRY 原則に違反しますか?

免責事項: 私は現在プログラミングを学んでいる素人です。プロジェクトに参加したことも、500 行を超えるものを書いたこともありません。

私の質問は次のとおりです。防御的プログラミングは、自分自身を繰り返さないという原則に違反していますか? 私の防御的プログラミングの定義が正しいと仮定すると (呼び出し関数が逆ではなく入力を検証するようにする)、それはあなたのコードに有害ではないでしょうか?

たとえば、これは悪いですか:

これと比較して:

繰り返しになりますが、素人の私には、単純な論理ステートメントがパフォーマンスに関してどの程度不利になるかわかりませんが、防御的なプログラミングはプログラムや魂にとって良くないことは確かです。

0 投票する
14 に答える
2667 参照

c# - どのくらい防御的にプログラムする必要がありますか?

データベース接続を作成するために使用される小さなルーチンを使用していました。

次に、.NET フレームワークのドキュメントを調べて、ドキュメントに記載されているさまざまな動作がどのようなものかを確認し、それらを処理できるかどうかを確認しました。

例えば:

ドキュメントには、コレクションを取得できなかった場合にConnectionStringsを呼び出すとConfigurationErrorExceptionがスローされることが記載されています。この場合、この例外を処理するためにできることは何もないので、手放します。


次の部分は、 connectionNameを見つけるためのConnectionStringsの実際のインデックス付けです。

この場合、ConnectionStrings のドキュメントには、接続名が見つからない場合、プロパティはnullを返すと記載されています。私はこれが起こっていることを確認し、例外をスローして、無効な接続名を与えたことを誰かに知らせることができます:


私は同じ演習を繰り返します:

GetFactoryProviderNameメソッドには、指定されたのファクトリが見つからなかった場合に何が起こるかについてのドキュメントがありません。を返すようnullに文書化されていませんが、私はまだ防御的で、nullをチェックすることができます:


次は、DbConnection オブジェクトの構築です。

繰り返しますが、ドキュメントには、接続を作成できなかった場合に何が起こるかは記載されていませんが、null の戻りオブジェクトを確認できます。


次に、Connection オブジェクトのプロパティを設定します。

ドキュメントには、接続文字列を設定できなかった場合にどうなるかは記載されていません。例外をスローしますか?それは無視しますか?ほとんどの例外と同様に、接続の ConnectionString を設定しようとしたときにエラーが発生した場合、そこから回復するためにできることは何もありません。だから私は何もしません。


最後に、データベース接続を開きます。

DbConnectionのOpen メソッドは抽象的であるため、どのプロバイダーがスローする例外を決定するかは、DbConnection から派生しているプロバイダー次第です。エラーが発生した場合に何が起こるかについて、抽象 Open メソッドのドキュメントにもガイダンスはありません。接続中にエラーが発生した場合、それを処理できないことはわかっています。発信者がユーザーに UI を表示できる場所でバブルを発生させ、再試行させる必要があります。


概要

したがって、私の 4 行の関数は 12 行になり、5 分間のドキュメント検索が必要になりました。最後に、メソッドが null を返すことが許可されている 1 つのケースをキャッチしました。しかし、実際には、アクセス違反の例外 (null 参照でメソッドを呼び出そうとした場合) をInvalidArgumentExceptionに変換するだけでした。

また、 nullの戻りオブジェクトが存在する可能性のある 2 つのケースもキャッチします。しかし、繰り返しになりますが、1 つの例外を別の例外と交換しただけです。

良い面としては、2 つの問題を検出し、例外メッセージで何が起こったのかを説明した方が、後で悪いことが起こった (つまり、ここでお金が止まった) ということではありませんでした。

しかし、それは価値がありますか?これはやり過ぎですか?この防御的なプログラミングはうまくいかないのでしょうか?