6

最近、ASP.NETMVC4コードベースを継承しました。私が指摘した問題の1つは、URLとhtmlフォームの送信でいくつかのデータベースID（int）が使用されていることでした。現在の状態のコードは、URLをいじくり回したり、異なる番号のカスタムHTML投稿を作成したりすることで利用できます。

これで、セッション状態または追加の認証チェックを使用してURLの問題を簡単に修正できますが、サイトが吐き出すHTMLに埋め込まれるデータベースIDについてはよくわかりません（つまり、ドロップダウンを使用して入力します）。IDが投稿に戻ってきたときに、有効なオプションとしてIDを確実に配置するにはどうすればよいですか？この問題に対処するという観点から、「ベストプラクティス」と見なされるものは何ですか？

私は「GUIDを上げる」ことができたことに感謝していますが、データベースをデバッグするときに操作するのが面倒なので、そうすることを躊躇しています。

ここに選択肢はありますか？IDを簡単に推測できないようにGUIDする必要がありますか、それともIDがサイトに戻ってきたときにIDの使用を検証するために使用できるDRYメカニズムのようなものがありますか？

更新：コメント投稿者は、私が期待しているエクスプロイトについて質問しました。「宝物」をインポートできるすべての場所のドロップダウンリストを含むHTMLフォームを吐き出したとしましょう。ユーザーが所有する場所のIDは1、2、および3であり、これらはHTMLで提供されます。しかし、ユーザーはhtmlを調べてそれをいじり、IDが4のPOSTを選択することにしました。4は彼の場所ではなく、他の誰かの場所です。

4

3 に答える 3

9

ユーザーが変更できる ID に対して、渡された ID を検証します。

面倒に思えるかもしれませんが、変更しようとしているものにユーザーが確実にアクセスできるようにする唯一の方法です。検証なしで GUID を使用することは、あいまいさによるセキュリティです。それらを推測するのは確かに困難ですが、十分なリソースがあれば推測できる可能性があります。

投稿されたデータで何かを行う前に、コントローラーの上部でこれを行うことができます。違反があった場合は、例外をスローして、グローバル例外ハンドラーにそれを処理させます。ユーザーがサポートされていない方法でデータを改ざんしていると安全に想定できるため、きれいな方法で処理する必要はありません。

于 2012-09-26T15:13:26.477 に答える
4

あなたが説明する問題は「安全でない直接オブジェクト参照」として知られており、OWASPグループはこの問題に対処するための 2 つのポリシーを推奨しています。

  1. セッションベースの間接オブジェクト参照を使用する
  2. オブジェクト参照へのすべてのアクセスを検証します。

提案 #1 の例は、ドロップダウン オプション 1、2、および 3 を使用する代わりに、各オプションに、ユーザー セッションのマップ内の元の ID に関連付けられた GUID を割り当てることです。そのユーザーから POST を受け取ったら、指定された ID が関連付けられているはずのオブジェクトを確認します。OWASP の ESAPI には、さまざまな言語でこれを支援するライブラリがいくつかあります。

しかし、多くの場合、提案 1 は実際には逆効果です。たとえば、多くの場合、あるユーザーから別のユーザーにコピー/貼り付けできる URL が必要です。プロセス #2 は、一般的に、この問題に対処する最も確実な方法と見なされています。

于 2012-09-26T15:20:08.797 に答える
2

安全でない ID を使用した壊れたアクセス制御について説明しています。脅威を特定し、特定のユーザーが所有する Id を決定したら、このサーバー側でチェックが行われていることを確認してください。

于 2012-09-26T15:21:24.167 に答える