クライアント側の検証が潜在的なセキュリティリスクである理由、またはサーバー側の検証よりもセキュリティリスクが高い理由がよくわかりません。誰かが私にいくつかのシナリオを教えてもらえますか?
5 に答える
理想的には、クライアント側とサーバー側の両方を実行し、どちらか一方を実行することはありません。これらの3つのシナリオを見ると、どちらも安全でユーザーフレンドリーな唯一の方法です。
クライアント側のみ:前述のように、誰かが不正な形式のデータをサーバーに送信したい場合(SQLインジェクションなど)、これらの検証を回避するのにそれほど時間はかかりません。NoScriptはjavascript検証コードを実行しません。また、一部のブラウザーでは、ユーザーがロードされたすべてのjavascriptとhtmlをアクティブに変更できるため、ユーザーは検証javascriptをコントロールからフック解除できます。
サーバー側のみ:これは、クライアントのみよりも安全ですが、使いやすさが低下します。フォームをサーバーに送信し、検証して、特定のフィールドが無効であるというエラーページを受信する必要があります。厄介なのは、これらのフィールドのいずれかがパスワードフィールドである場合、それらの値はデフォルトで再入力されないことです。たとえば、ユーザーがアカウント作成フォームに電話番号を正しく入力しなかったとします。サーバーが電話番号が間違っていることについてページを吐き返すと、ユーザーはそれを確認し、電話番号を修正してもう一度送信を押すと、パスワードを入力しなかった(そして2番目にもう一度入力した)という別のエラーページが表示されます。 textbox)それが最初の問題ではなかったとしても。
クライアント側とサーバー側:サーバー側の検証のセキュリティ、ユーザーが干渉するのが難しいもの、ページを送信しなくても入力検証の使いやすさ(純粋にローカルのJavaScriptまたはAJAXを介して検証するかどうか)が得られます)。
どうしても1つを選択する必要がある場合は、サーバー側が最適です。しかし、どちらかを選ぶ必要はありません。
Fiddler、Noscript、Web Developerなどのさまざまなツールを使用して、クライアント側のjavascript検証を無効にし、サーバーに送信されるデータを変更することができます。データの種類とサーバーがそれをどのように処理するかに応じて、SQLインジェクション攻撃を開始したり、サーバーのセキュリティを侵害しようとしたり、単に偽のデータを保存したりする可能性があります。
軽量の例:郵便番号が5桁または5+4桁であることを確認するためのクライアント側の検証があるとします。クライアント側のスクリプトを無効にすると、24桁の値をそのままにしておくことができます。サーバーが値をさらにチェックせず、データベースが24桁すべてを保存できる場合、偽のデータを保存しました。
クライアント側でのみ検証を行う場合、誰かがjavascriptを無効にする可能性があります(または、たとえば、firebugを使用してjsコードを変更します)。したがって、jsで行われたすべての検証は役に立たず、ユーザーはシステムに無効なデータを挿入する可能性があります。
私はあなたがウェブシナリオについて話していると思いますか?
Javascriptを使用してクライアント側の検証を行っている場合、ユーザーがJavascriptを無効にするとどうなりますか?次に、検証されていないデータをサーバーに送信できます。
彼らが卑劣な場合、彼らはあなたのサーバーに直接データを投稿することさえできます(あなたのページを完全にバイパスします)。
クライアント側の検証に加えて、またはその代わりにサーバー側の検証を行う場合は、これらのシナリオから防御するための追加の機会があります。
実際、クライアント側の検証には(サーバー側の検証と組み合わせて)セキュリティ上の大きな利点があります。クライアントで慎重に検証する場合、サーバーに着信するすべてのトラフィックはクリーンである必要があります。攻撃者を除いて。これにより、サーバー側の攻撃の検出が大幅に向上します。大きな計画の中で、それはおそらくアプリケーションを保護するために実行できる最も重要なことです。詳細については、OWASPESAPIIntrusionDetectorまたはOWASPAppSensorを参照してください。
ああ、そして明らかに、攻撃がDOMベースのXSSのようにクライアントで開始および終了する場合は、クライアント側で検証およびエンコードする必要があります。