有効/無効な入力文字をユーザーに通知するのはセキュリティの脆弱性ですか？
Webサイトでの入力検証の場合、特定のフィールドで有効または無効な文字をユーザーに正確に開示することでセキュリティ上の懸念はありますか？
CWE-200：情報漏えい 「攻撃に役立つ可能性があるが、通常は攻撃者には利用できない」情報を開示しないようにすべきだと述べています。具体的な例は、システムがスタックトレースを公開できないようにすることです（ CWE-209：エラーメッセージによる情報の漏えい で対処）。
「入力したテキストに無効な文字が含まれています」などのエラーメッセージが曖昧であることを確認する必要がありますか？
攻撃者に表示される可能性があるJavaScriptなどのクライアント側コードの入力を検証するために使用される正規表現を含めることはセキュリティの脆弱性ですか？サーバー側で入力を検証する別の方法では、より多くのバックエンド通信が必要になるため、使いやすさが多少低下します（たとえば、サイトの応答が遅くなり、エラーの表示が遅くなる可能性があります）。
または、ユーザー/攻撃者がさまざまな文字を繰り返し送信してエラーが発生するかどうかを確認することにより、有効な文字を推測できるため、これは「あいまいさによるセキュリティ」の形式ですか？
攻撃を遅くする可能性があることは、ユーザーエクスペリエンスに影響を与える価値がありますか？
私が知る限り、OWASPの Input Validation Cheat Sheet および Data Validation開発ガイド は、このトピックに関する指示を提供しないことに注意してください。
編集2020-01-17：
なぜなぜすべきかについていくつかの質問（私がコメントを書くために私が行った回答を含む）がありました入力検証。
まず、21ページと22ページのパスワードに関するガイダンスを提供するOWASPの Application Security Verification Standard を指すコメントについて@Loekに感謝します。「文字のタイプを制限するパスワード構成ルールがないことを確認します。許可されています。大文字、小文字、数字、特殊文字は必要ありません。」.
パスワードの文字数を制限することは一般的に悪い考えであると私たちは皆同意できると思います（ @ Merchakoの回答 を参照）。 @ emoryが指摘する おそらく、これは難しくて速い規則ではありません（たとえば、他の誰かがアクセスできる場合でも、アプリを保護するために使いやすいセカンダリ「PIN」を使用する多くのモバイルアプリを見てきました）デバイスにログインします。）この質問をしたとき、私は本当にパスワードを考えていませんでしたが、それはコメントと回答が進む方向の1つです。 したがって、この質問の目的では、パスワード以外のフィールド用であると考えてみましょう。
入力検証は、インジェクション攻撃を防ぐためのWebサイト、Webサービス、およびアプリの「多層防御」の一部です。 OWASPで述べられているように、インジェクション攻撃は「データの損失、破損、または権限のない当事者への開示、説明責任の喪失、またはアクセス拒否を引き起こす可能性があります。インジェクションは、ホストの完全なテイクオーバーにつながる可能性があります。ビジネスへの影響は、アプリケーションとデータ。」
詳細については、OWASPの1番目の脆弱性、 A1-Injection 、および CWE-20：不適切な入力検証 を参照してください。どちらも、入力検証は完全な防御ではなく、ソフトウェア製品の「徹底的な防御」の1つの層であると述べています。
...攻撃に役立つ可能性がありますが、通常、攻撃者は利用できません
無効な入力文字の知識は有用ですが、攻撃者は数回試行するだけで簡単に見つけることができます。したがって、この情報は実際には秘密ではなく、すべてのユーザーが正確に何が悪かったのかを知らなくても、実際には攻撃者を阻止することはできません。
ユーザーにとって心理的に苛立たしい状況を作り出すと、安全性の低い決定に傾く可能性があります。たとえば、彼らはスウェーデン語でパスワードを書き込もうとしますが、あなたの入力は説明なしで文字åを拒否します。 åを使用せずに別の適切なパスワードを選択する代わりに、手を上げてpassword123を使用します。これは、辞書攻撃で簡単に破られます。
このように、あいまいさを介して「より安全な」システムを作成しようとしましたが、ユーザーの行動を説明すると、実際には安全性が低下します。
有効なキャラクターは、最終的には体系的な方法で見つけられます。それらを非表示にすることは、ユーザーの行動に与える可能性のある損害に値しません。
詳細については、「 セキュリティと認知バイアス：心の役割の調査 」および「 認知行動エージェントベースのモデリングを使用したパスワードポリシーのセキュリティへの影響の測定 」を参照してください。ショーン・スミス他.
場合によります。
メッセージが「3番目の文字は数字でなければならない」などの通常のユーザーの観点からのエラーを説明している場合、セキュリティの脆弱性ではありません。ただし、検証に使用される正規表現を表示するということは、実装の詳細を開示することを意味しますcanは弱点です。一部のライブラリは再帰呼び出しを広範囲に使用し、一部の式はスタックオーバーフローを引き起こしたり、メモリとCPUの使用率が高くなり、DoSにつながる可能性があります。
CWE-200は、ユーザーその情報へのアクセスを明示的に許可されていない場合の場合にのみ、情報の開示を弱点と定義しています。ユーザー入力を検討しています。つまり、ユーザーは許可でこの情報を入力できるため、この情報を表示でき、当然、この入力に関連する検証エラーメッセージを表示できます。
スタックトレースと他の技術メッセージは、アプリケーションで使用されているテクノロジー（使用されているライブラリのバージョンなど）、環境（ディレクトリのレイアウトと権限、OSタイプとバージョンなど）などに関する情報を提供します。攻撃者は、この情報を使用して、これらの特定のテクノロジー、ライブラリ、OSなどのエクスプロイトを効果的に選択します。そのため、そのような情報をユーザーに開示することは潜在的に弱点です。
ユーザーの入力の何が間違っているのかをユーザーに説明しないのは間違いなく悪いUXですが、セキュリティの改善はありません。
データが機密であり、それに関連する検証が機密である場合、同様のケースと混同しないでくださいcan機密です。たとえば、ユーザーが1年を期待するフィールドに文字を入力した場合、そのようなエラーをユーザーに説明することは安全です。しかし、ユーザーが電子メールアドレスを入力し、そのようなアドレスがシステムに登録されているかどうかを確認した場合、any情報（アドレスは既知、アドレスは不明）が脆弱になる可能性があります。そのため、ユーザー入力に関する検証メッセージやその他のフィードバックを実装するときは、結果を評価してください。ただし、すべてのフィールドに対してデフォルトでフィードバックを禁止することは、falseの安心感を伴う貧弱なUXになる可能性があります。
これは、システムの使いやすさを優先してセキュリティのトレードオフが予想される多くのシナリオの1つにすぎません。
ただし、スタックトレースの表示（エラー処理が不十分）と、入力フィールドで予期または禁止されている文字の否認には大きな違いがあります。
ほとんどのシナリオでは、他のセキュリティメカニズムがある場合、入力フィールドで予期または禁止されている文字を放棄することはセキュリティの脆弱性ではまったくないと主張できます。パスワードの試行を制限するなどの適切な設定。
脅威モデリングフレームワークを使用して、これがシステムのリスクとして認められていると判断できます。
あいまいさはセキュリティではありません。優れたシステムは、攻撃者がシステムについてすべて知っていても安全です。あなたの場合、無駄なクラッキングの推測を一定の割合、たとえば25％削減しても、クラッキングの実用性を損なうことはありません。1兆年は0.75兆年と同じくらい実用的です。実装の詳細が隠されていないことも、新しい善良な人の防御に役立ちます。
社会的な考慮事項もあります。 「BEWARE OF DOG」の標識はセキュリティ実装の詳細を漏らす可能性がありますが、一定の規模の一般的な攻撃を阻止することにもなります。犬は手助けをしますが、既知または未知ですが、標識はフェンスのメンテナンスコストを削減し、他の戦闘と戦うためのリソースを解放します。
他の回答は、これを開示することがセキュリティの問題ではないことを示しています。
私は本当の逸話で、開示しないとユーザーを苛立たせるだけでなく、セキュリティを低下させる可能性があると主張します。
これは、許可されている文字が明確でないサイトで2回以上発生しました。当時、私はパスワードジェネレーターを使用していなかったので、パスワードを記憶するためのメンタルスキームがありました。 $@.&のようないくつかの特殊文字を使用する必要がありました。私が得たのは「パスワードの無効な文字」だけだったいくつかのイライラした試みであり、私は徐々に特殊文字を排除し始めました。次に、「パスワードが十分に安全ではありません。数字と記号を追加してみてください」...そうです...この時点で私は間違いなくリラックスしています。
やっとパスワードを受け取れます。これは、特殊文字が1つだけ含まれているだけでなく、パスワードを記憶するためのどのスキームにも適合しなかったため、別の場所に保存する必要がありました。私がそれをどのように確保したか想像できます。ヘリコプターのようで、ひものようだったと伝えます）。
ユーザーが選択できる文字のセットを公開しても、これらのルールが適用され、チェックされている限り、問題は発生しません。つまり、ユーザーがフィールドで\を使用することを許可されていない場合、これをJS入力でチェックするだけではなく、これを入力する前、つまりDBに入力するとき、およびデータが使用されるときにチェックするだけでは不十分です。したがって、ルールは常に適用される必要があります（TOCTOU）。もう1つは、エントロピーが与えられている限り、文字セットを減らすことは問題ありません。パスワードの文字を「a」と「b」に減らすことはできますが、それに応じて最小PWの長さを増やす必要があります（十分な長さになるまで「a」キーを押し続けているだけではないことを確認してください）。十分に長い（ランダムな）パスワードを使用すると、これも安全なパスワードになります。結局のところ、文字に必要なものはすべてビットであり、誰もがこれらが0と1であることを知っているので、（実際の）アルファベットは常にわかっています。