Web アプリケーションに対してクライアント側とサーバー側の両方の検証を行う高レベルの理由はありますか?
7078 次
8 に答える
11
クライアント側の検証が覆される可能性があるためです。
たとえば、Web では、検証に JavaScript を使用している場合、JavaScript をオフにするか、FireBug などのツールを使用してその動作を変更するのは非常に簡単です。
他のクライアント/サーバー方式のイベントでは、データ リンクが破壊され、「検証済み」データがサーバーへの途中で変更される可能性があります ( Man In The Middle攻撃)。
一般に、「クライアントを信頼しない」という格言が、サーバーで常に検証する必要がある理由です。
その場合、なぜクライアントで検証するのかと尋ねるかもしれません。すぐにフィードバックを提供するため。
于 2010-11-02T10:53:53.383 に答える
3
ユーザーはローカルで検証 JavaScript を変更できます (ページを保存して、それに対して何かを実行できます)。または、ブラウザーで JavaScript を無効にすることができます。したがって、この場合、クライアント側の検証は役に立ちません。したがって、サーバーでも確認する必要があります
于 2010-11-02T10:53:33.603 に答える
3
クライアント側の検証は、次の目的で使用されます
。1) 長さおよびフォーマットの制約に対するデータの適合
2) ユーザーへの即時の表示またはフィードバック
サーバー側の検証
1) ビジネス ロジックに対するより高度な検証
2) 基準の変更を確認します。たとえば、Amazon に本を注文し、チェックアウトした直後に、他の誰かがその直前に購入した可能性があるため、その本が在庫切れであるという指示が表示され
た場合 3) 対象のユーザーがデータを投稿したかどうかを確認します。Cookie や JavaScript などのクライアント側のものは操作できるため、サーバーは認証を行い、通過するデータを汚染チェックする必要があります。
したがって、サーバー側の検証は、悪意のあるデータに対する主要な防御策として、また高度なビジネス ロジックに対してデータをチェックするためにも必要です。
于 2010-11-02T11:05:38.027 に答える
2
リアルタイムのクライアント側検証の目的（つまり、ユーザーがSUBMITを押した後ではなく、ユーザーがフィールド間を移動するとき）は、ユーザーにできるだけ早くフィードバックを提供することです。たとえば、社会保障番号に9桁が必要で、ユーザーが8と入力した場合、検証が行われたとしても、ユーザーがフォームの残りの部分に入力し、[送信]をクリックしてエラーを指摘するまで待つ必要はありません。クライアント側で発生します。SUBMITがクライアント側を検証するまで待つことは、ほとんど意味がありません。サーバーと帯域幅を節約するだけです。エラーが発生したときに指摘する通常、ユーザーにとって全体的にシンプルなエクスペリエンスであるため、フォームの完了率が高くなります。エラーのリストは表示されません。「以下のすべてのエラーを修正してください」。ただし、どのような場合でもデータの整合性を確保するには、サーバー側の検証が必要です。ナイトクラブの用心棒は、通りの向かいの駐車場ではなく、クラブのドアの前に立っています。
于 2010-11-02T11:21:45.000 に答える
2
クライアント側の検証により、ページが読み込まれるのを待たずに、ユーザーに即座にフィードバックが提供されます。ただし、クライアントがクライアント側のスクリプトを無効にしている場合 (たとえば、JavaScript が無効になっている場合)、検証は実行されないため、サーバーで値も確認する必要があります。
于 2010-11-02T10:54:15.927 に答える
2
クライアント側は、(理論的には) サーバーに到達する前に検証の問題の大部分を取り除きます (ただし、これは、JavaScript が無効になっている/編集されている場合などには常に当てはまるとは限りません)。これにより、検証を実行する責任がクライアント デバイスに課せられるため、サーバーから「負担」/不必要な処理が取り除かれます。
サーバー側は、何らかの理由でクライアント側の検証では検出されなかった検証の問題を検出します。
于 2010-11-02T10:55:24.373 に答える
2
クライアント側の検証はプラスですが、必須ではありません。ユーザー情報を受け入れるときは、常に「敵対的」と見なす必要があるため、サーバー側の検証 (ssv) を使用する必要があります。そのデータもデータベースにフィードされる場合、ssv は最後の防衛線となります。データベースに不要なデータや無効なデータを入れたくないからです。
クライアント側の検証は防弾ではないため、クライアント側で何かが検証されたとしても、それがサーバーに到着したときに有効であるとは限りません。
于 2010-11-02T10:59:43.403 に答える
0
データベースに複数のテーブルを持つアプリケーションがある場合、サーバー側の検証は一連の制限 (データ テーブル設計の一部) にすぎない可能性があります。サーバー側は中間サーバー層ではなく、DB 層の制限なので、検証はしていないと思うかもしれません。
次に、リレーショナル データベースの利点を利用して、整合性に基づいていると言えます (データ構造が安全であることはわかっています)。ほとんどの場合、クライアント側の検証のみを使用して、クライアントのアクションに対するインスタンス フィードバックを提供します。サーバー側のレイヤー、サーバー側のコードのコントローラーで追加の検証を行わないことは、重大な問題ではない可能性があります。
したがって、一部/ほとんどの場合、クライアント側の検証のみを使用する可能性があると言えます。サーバー側の検証は、クライアントが購入フォームを送信したときに、何かがすでに購入されているかどうかを確認するような特別なケースです。
両側で検証を繰り返さないことは悪い考えではありません。
もちろん、データに多くの注意を払う必要があるアプリケーションもあります。その場合、サーバー側の検証だけでなく (ビジネス モデルの安全性の一部と同様に、ほとんどのユース ケースのテスト カバレッジ - クライアントの入力など) も重要です。
しかし、それが複数のフォームを持つ単なるサイトである場合は、データベースの制限とクライアント側の検証が適切な選択だと思います。
于 2013-02-18T19:24:30.503 に答える