0

私の C# asp.net webform には、検索の一部として「使用できる」約 20 の要素を持つ検索ページがあります。後でさらに追加されます。

私が行ったことは、テキストボックスとドロップダウンリストボックスを拡張して、いくつかの変数を含めることです:

fieldname: Tablename.columnname dbtype: DbType.Int32 Joinparam: LEFT Join on otherTable ON xy = ab

これらはすべてビューステートに保存され、再度読み込まれます。これを行う理由は、すべてのコントロールを反復処理して、自分のタイプのすべてのコントロールを引き出すことができるようにするためです。次に、それらを検証して、入力があり、正しい型であることを確認できます。その場合、それらをデータベース アクセス レイヤーに渡し、コードで動的に SQL ステートメントを生成することができます。

これから SELECT ステートメント以外は何も発生させません。選択して返されたフィールドは変更できず、db パラメータを使用して SQL インジェクションを回避しようとしています。

私の心配は、検索条件で使用されるテーブルとフィールド名、および必要な JOINS をすべてビューステートに配置することです。これは本当に悪い考えですか？

DB にこの情報を保持するテーブルにいくつかの int インデックスを作成するだけでこれを曖昧にすることができますが、これはまだビューステートに入れる必要があり、理解するための追加のレイヤーがあることを意味します。

私がこのアプローチを採用した理由は、ステートメントを作成するために DB レイヤーに大量の IF ステートメントを配置する必要がなかったからです。それは地獄のように醜く、維持するのは苦痛です。

これに関するすべてのアドバイスに感謝します。

ジョン

編集

アドバイスをありがとう。ありがたいことに、このアプリは内部のみのものであるため、被害は限定的です。しかし、私はこの手法を二度と使用することはなく、代わりに検索テンプレートのアイデアに取り組みます.

乾杯 ：）

4

3 に答える 3

3

ビューロジックでデータアクセスレイヤーの一部をエンコードするのは、実際の設計ミスだと思います。セキュリティ上の懸念は別として、これを維持し、あなたの後に続く人が理解するのは非常に困難です。さまざまな選択された入力から特定のクエリを生成するためのファクトリ クラスは、長期的にはおそらく作業が容易になると思います。または、入力から "検索テンプレート" を設定し、検索テンプレートをクエリを生成するためのファクトリとして機能させることもできます。これは、UserPrincipal が System.DirectoryServices.AccountManagement 名前空間で PrincipalSearcher と対話する方法とよく似ています。

于 2009-01-24T22:00:57.720 に答える
2

ビューステートは暗号化されておらず、base64でエンコードされています。ページのビューステートをデコードできるユーティリティがすぐに利用できます。

ただし、1つのページまたはすべてのページのビューステートを暗号化することは可能です：http： //msdn.microsoft.com/en-us/library/aa479501.aspx

そうは言っても、私はこのアプローチをお勧めしません。アプリケーション設計の最良のアプローチは、UIをビジネスおよびデータアクセスロジックから切り離すことです。この場合、明らかなメリットがないため、それらを緊密に結合することになります。

より堅牢なアドホッククエリ機能をデータアクセス層に組み込んだ場合は、アプリケーションのバックエンドに付加価値を付けている可能性があります。Webサービス、Windowsフォームアプリなどを介して検索機能を提供できます。このタイプの機能が近い将来に発生することを想定していない場合でも、このアプローチを採用すると、大幅な時間（および$$$）の節約になります。

UIに組み込んだロジックは、ある種のクエリエンジンに簡単に組み込むことができます。回避したいIFの代わりに、基準を動的に追加することによってクエリをアセンブルするメソッドを構築できます。

于 2009-01-24T22:21:35.617 に答える
1

さて、ViewState はデフォルトでMACedに設定されており、オプションで暗号化することもできます。したがって、(デフォルトで)ビューステートを読み取ることはできますが、改ざんは簡単ではありません。

このようにクエリを動的に構築すると、間違いなく Sql インジェクションが可能になります。検索語をパラメーター化していますが、;DROP TABLE ステートメントを JOIN 句に挿入できれば、うんざりします (十分に注意していない限り)。もちろん、DBレベルのセキュリティを設定します）。

そうは言っても、JOIN句などをViewStateに含める必要がある理由はわかりません。ASPXマークアップでサブクラス化されたテキストボックスのプロパティとしてそれらを設定すると思います-それらを変更する理由はありません。ViewState が必要になる唯一のものは、適切にパラメータ化された検索条件自体です。これは、SqlDataSource が SelectCommand プロパティを保護する方法に似ています。情報が漏洩しないように (または改ざんのリスクがありますが、重大な脆弱性ではないと思いますが)、ViewState に格納しないでください。

これが維持可能かどうかというより大きな問題については、まあ、あなたはその電話をかける必要があると思います。

于 2009-01-24T22:38:21.310 に答える