validation - クライアント側の検証では不十分なのはなぜですか？

Question

私はここでそれを見ました：

おそらくすでにご存知のように、クライアント側の検証だけに依存することは非常に悪い考えです。常に適切なサーバー側の検証も実行してください。

サーバー側の検証が必須である理由を説明できますか？

score 64 · Accepted Answer

クライアント側の検証（ここでWebページについて話していると思います）はJavaScriptに依存しています。

JavaScriptを利用した検証は、ユーザーのブラウザでオフにしたり、スクリプトエラーが原因で失敗したり、手間をかけずに悪意を持って回避したりする可能性があります。

また、フォーム送信のプロセス全体を偽造することもできます。

したがって、サーバー側に到着するものがクリーンで安全なデータであるという保証はありません。

score 19 · Accepted Answer

サーバーアプリケーションの作成には、単純なルールがあります。ユーザーデータは決して信頼しないでください。

curl悪意のあるユーザーが意図しない方法でサーバーにアクセスすることを常に想定する必要があります (たとえば、この場合、意図した Web ページではなく、手動のクエリを介して)。たとえば、Web ページが SQL コマンドを除外しようとしている場合、攻撃者は、SQL コマンドで入力を渡すことが適切な攻撃ベクトルである可能性があるという良いヒントを既に持っています。

score 13 · Accepted Answer

基本的なJavaScriptを知っている人なら誰でも、クライアント側を回避できます。

クライアント側は、ユーザーエクスペリエンスを向上させるために使用されます（検証するためにページをリロードする必要はありません）

score 7 · Accepted Answer

あなたが話しているクライアントは、あなたが話していると思っているクライアントではないかもしれないので、あなたが要求している検証を無視している可能性があります.

Web コンテキストでは、ユーザーがブラウザーで JavaScript を無効にしている可能性があるだけでなく、ブラウザーとまったく通信していない可能性もあります。POST しているボットからフォーム送信を取得している可能性があります。フォームをまったく見ずに、送信 URL に送信します。

より広い文脈では、実際のクライアントが送信しないデータを送信しているハッキングされたクライアント (FPS ゲームのエイムボットなど) や、ワイヤプロトコルをリバースエンジニアリングした誰かによって作成された完全なカスタムクライアントを扱っている可能性があります。これは、実行することを期待している検証について何も知りません。

score 6 · Accepted Answer

Javascript および Web クライアントに固有のものではなく、より広く問題に対処するために、サーバーは (基盤となるデータベースと連携して) 独自のデータを維持する責任を負う必要があります。

クライアントサーバー環境では、サーバーは、多くの異なるクライアント実装がサーバーと通信する可能性があるという事実に備える必要があります。トレードエントリーシステムを考えてみましょう。クライアントは、GUI (例: 取引入力システム) および (たとえば) データアップロードクライアント (.csv ファイルから複数の取引をロードする) である可能性があります。

クライアントの検証はさまざまな方法で実行される可能性があり、すべてが正しく実行されるわけではありません。したがって、サーバーは必ずしもクライアントデータを信頼して、整合性チェックと検証自体を実行する必要はありません。

score 5 · Accepted Answer

5

攻撃者が独自のフォームを投稿した場合。

于 2010-08-14T14:02:22.183 に答える

score 3 · Accepted Answer

ユーザーエージェント (ブラウザなど) が偽物である可能性があるためです。カスタムアプリケーションを作成して、任意のヘッダーとコンテンツで HTTP 要求を作成するのは非常に簡単です。それは本物のブラウザであるとさえ言えます。違いを見分ける方法はありません。

リクエストの内容を見るしかないので、確認しないと有効かどうかわかりません。

score 3 · Accepted Answer

3

JavaScriptをオフ/編集できます。

于 2010-08-14T13:52:53.733 に答える

score 1 · Accepted Answer

クライアント側の検証では、検証されていないデータがサーバーに到着することが保証されないため、サーバー側の検証は必須です。

アクションの範囲が非常に制限されているため、クライアント側の検証は十分ではありません。検証は、ブラウザーのユーザーインターフェイスでのみ実行されます。

Web サーバーは、ブラウザーからのデータを含むHTTP 要求を「リッスン」して受信し、それを処理します。

悪意のあるユーザーは、さまざまな方法で悪意のある HTTP 要求を送信できます。ブラウザも必要ありません。

ブラウザーで JavaScript を使用して実行されるクライアント側の検証は、重要な使いやすさとユーザーインターフェイスの機能強化です。ただし、サーバーに送信される HTTP 要求を作成するブラウザーの既定の動作を回避する方法を知っているユーザーによって送信される悪意のあるデータを防ぐことはできません。これは、cURL などを使用して、一部のブラウザープラグインで簡単に実行できます。

score 1 · Accepted Answer

一般に、アプリのすべての部分が独自のチェック/検証を行うのが最善です。

クライアント側のチェックは、ユーザーエクスペリエンスを最大化し、何かを修正する必要があるというクライアントへのフィードバックを高速化し、サーバー側のチェックで発生する問題の量を減らすのに適しています。

次に、サーバー側コードの主要な移行ポイントごとに、そこにもチェックを配置する必要があります。アプリケーションコード内の入力を (できればホワイトリストの入力検証を使用して) 検証し、データベースとのやり取りでパラメーター化されたクエリを使用して、問題が発生しないことをさらに確認します。

score 0 · Accepted Answer

Client side validations presuppose a safe browser, a client side language, or HTML 5. All these elements could be disabled, partially unusable, or simply not implemented. Your website have to be used from every person, with every browser. The server side languages are safer, and -if they aren't bugs- the validation will be surely safer and right.

score 0 · Accepted Answer

バディ、ある人がブラウザで JavaScript をオフにすると、バリデーションが機能しなくなったとします。次に、そのフォームからサーバー側に悪意のあるコンテンツを投稿した場合。これは、SQL インジェクションや xss などの深刻な脆弱性やその他の問題につながる可能性があります。したがって、クライアント側の JavaScript 検証を実装する場合は注意してください。

ありがとうございました

score 0 · Accepted Answer

クライアント側の検証は、クライアントが間違ったデータを入力するのを防ぐためのものです。サーバー側の検証は、サーバーが間違ったデータを処理するのを防ぐためのものです。その過程で、送信プロセスにある程度のセキュリティも導入されます。

score 0 · Accepted Answer

無効な場合、データを投稿するエンティティ以外の誰かに害を及ぼす可能性があるデータに対して、サーバー側の検証を実行する必要があります。クライアント側の検証は、無効なデータがそれを投稿するエンティティ以外の誰かに悪影響を及ぼさない場合に適している場合があります。悪いデータによる悪影響がそれを投稿したエンティティ以外に広がらないことを確信できない場合は、サーバー側の検証を使用して、破壊行為やその他の不正なクライアントから身を守る必要があります。

validation - クライアント側の検証では不十分なのはなぜですか？

14 に答える 14

Related

Reference