0

DB2テーブルに対して基本的なCRUD操作を実行するASP.NETMVC2アプリケーションを使用しています。IEにロードするだけでアプリケーションをテストするときに、数値フィールドに文字を入力したり、日付フィールドに数値を入力したり、ビューモデルのデータ型と互換性のない他の形式のデータを入力したりすると、MVCはその最後で正しいエラー処理を実行しますビューは、Html.ValidationSummary（）mvcヘルパーによって表示される適切なモデル状態エラーメッセージとともに返されます。

ただし、IBM AppScanなどのプログラムでテストを実行したり、Fiddler2でPOST要求を偽造したりすると、アプリケーションが反転します。

私は2つの異なる方法で同じ種類のテストであると信じていることを実行しており、さまざまな結果を得ています。

私もMVCのAntiForgeryTokenシステムを使用していますが、これらのプログラムはリクエストデータをスキャンし、トークンを見つけて、偽造されたPOSTに含まれていることを確認するだけなので、あまり効果がありません。

また、サーバー側でDataAnnotationsを使用してこれらの検証のいくつかを処理しており、アノテーションが返すはずのエラーを取得する代わりに、キャッチされていない例外についてページがアプリケーションエラーページにリダイレクトされることにも注意してください。

私は実際、これらすべてにかなり困惑しています。私は何が欠けていますか？

4

1 に答える 1

0

LukLedのコメントは、私に物事の健全性チェックを行わせてくれました。彼は絶対に正しいです。私はそれを間違っています。Fiddlerでリクエスト本文の詳細を偽造したとき、データが正しくないことがわかっている方法でそれを行いましたが、データも正しい検証に該当するため、エラーがキャッチされました。数字のみのフィールドに文字を送信するなどの私のテスト（これは、AppScanがアプリをテストしたときにアプリを爆撃したようなものだと思っていました）は正しい結果をもたらしました。

ただし、LukLedのコメントにより、AppScanが送信したPOSTデータを実際に確認することができました。すべてのアプリケーションエラーで、フィールドはビューモデルの文字列でした。長さや「文字列データの正しい切り捨て」を徹底的にチェックせずに、データを渡すことができました。SQLエラーが発生しました。これにより、AppScanが送信した値の一部が次のようになっているため、データのサニタイズを改善する必要があることも明らかになりました。

'../../../../../../../../../../../../bin/id |' 口座番号フィールドの場合

説明フィールドのFoobar％0d％0aAppScanHeader：％20AppScanValue％2f1％2e2％2d3％0d％0aSecondAppScanHeader：％20whatever'。

これらのような特殊文字は、フォームの送信では許可されるべきではありません。

于 2012-06-07T13:12:18.147 に答える