ASP.NET MVC JQueryデータval-regex-patternセキュリティ

Question

クライアントの検証にのみ依存しないことについて多く書かれています。これはユーザーにとって便利な機能であり、サーバーの処理を軽減します。これは、この質問が何であるかではありません。

これはASP.NET MVCまたはすべてのJQuery検証に固有のものかどうかわかりませんが、これは私の質問がどこから来るかです。 ReqularExpressionAttributeをclientsidevalidationを有効にして使用すると、HTMLの出力は基本的な例を投げるためにdata-val-regex-pattern = "^ [0-9a-zA-Z] {3,12} $"のように出力されます。

これはあまり安全ではないので、あなたの式がチェックしているものを明示的に示していますが、チェックしていませんか？ユーザーが正確に何を正確に読むことができる場合、検証スキームでホールを利用するほうがずっと簡単なようです。そして、サーバが使用するのと同じ表現であるため、サーバが何をチェックするかを見ることができます。

UPDATE

私の例の式は、問題を説明するための非常に良いではありません。これは、非常に厳密なフォーマットを持つより複雑なデータ値についてのもので、間違いなくいくつかの抜け穴を見過ごしています。

Answer 1

検証する内容に応じてセキュリティホールになる可能性があります。しかし、N層アプリケーションのほとんどの場合、フロントエンドモデルはバックエンドモデルとは異なります。そして、あなたのバックエンドはまだそれを検証し、適切な例外をスローします。

unobstrusive検証に関するいくつかの情報：

jQueryのunobstrusive検証はデータ - 属性を使用しています。

あなたがunobstrusive検証をしたくない場合は、あなただけのweb.config

でそれを無効にすることができますweb.configファイルに行くと、これを発見してみてください。

<appSettings> 
    <add key="ClientValidationEnabled" value="true" /> 
    <add key="UnobtrusiveJavaScriptEnabled" value="true" /> 
</appSettings> 

をfalseにUnobtrusiveJavaScriptEnabled設定。しかし、それ以上の鍵があるかもしれません。

Answer 2

説明していることは、あいまいさによるセキュリティです。つまり、攻撃者が攻撃方法を知らない場合、何かが安全であるという考えです。

これはセキュリティではなく、脆弱性が存在する場合は安全ではありません。 「あいまいさによる安全保障はまったく安全ではない」という言葉があります。

悪用されやすくなっていますか？たぶん、正直なところ、あなたのコードを修正するのが解決策です。

別の言い方をすると、攻撃者が誤って脆弱性を突き抜けてしまう可能性があります。あなたはまだ脆弱で、それはまだ安全ではありません。

Answer 3

この質問をして1年後、私は以前の自分に言えば、検証の目的は入力されたデータの種類を検証することであり、要求を検証することではないと私は考えます。したがって、これは心配する問題ではありません。