非表示のフォームフィールドの保護
シナリオは次のとおりです。
- アプリケーションには、データを構成できるWebインターフェースがあります。この質問で考慮すべきデータは、グループと多対多の関係を持つユーザーです。
- 各グループには1人以上の管理ユーザーがいます。
- 異なるグループの複数の管理者ユーザーが同時にログインできます。
次の使用例を検討してください。
- 管理ユーザーはWebインターフェースにログインし、グループ内のユーザーのリストを表示することを選択します。
- 管理ユーザーは、編集するユーザーを選択します（特権の変更など）。
- 管理ユーザーは、編集ページの非表示フィールドに通常のユーザーのIDを持つ単一のユーザーの編集ページにリダイレクトされます。
- 管理ユーザーはフォームに新しい特権を入力し、フォームを送信します。
- Webアプリケーションは、データベース内の通常のユーザーの権限を更新します。
- Webアプリケーションのこの側面では、パフォーマンスの最適化は必要ありません。数秒程度の操作は許容されます。
通常のユーザーのIDがクライアント側で編集できないと信じて、赤のグループの赤の管理者ユーザーが青のグループの通常のユーザー（赤の管理者ユーザーはメンバーではない）の特権を変更できるようにするのは、世間知らずです。
編集中の通常のユーザーのIDの整合性を保護するためにサーバー側で何ができますか？
この質問では、Red Adminユーザーが正しく認証されており、Redグループの通常のユーザーの編集ページを表示できると想定しています。ここでは、他のグループのユーザーのプロパティを変更するために、レッド管理ユーザーがレッドグループの通常のユーザーの非表示のユーザーIDを悪意を持って変更することに関心があります。
具体的には、このシステムは、Glassfishサーバーで実行されているJava EEを使用して開発されています。
私は以下の解決策を検討しました：
- 編集フォームの非表示フィールドとしてユーザーIDを組み込んだ暗号化チェックサムを埋め込みます。 Red Adminユーザーは新しいハッシュを計算する必要があるだけなので、MD5ハッシュなどは不適切です。ハッシュは、サーバー側の秘密から派生する必要があります。明らかに、秘密は予測不可能で保護されている必要があります。
- 現在、システムはステートレスセッションBeanを使用して、編集する通常のユーザーのIDを赤のグループユーザーのリストからユーザー編集ページに移動します。セッションBeanをステートフルBeanに変更すると、サーバー内で編集されるユーザーIDが維持されますが、他の方法を検討しています。
この特定の脅威に対抗するには、他にどのようなオプションを検討する必要がありますか？ユーザー認証や安全な送信などのテーマは、この質問の範囲外です。
あなたは間違った目的に取り組んでいると思います。サーバーは、管理者がユーザーの編集を許可されているかどうかを確認するだけです更新の直前。管理者がフォームを変更したかどうかは無関係であり、とにかく実際に確認することはできません。重要なのは、ユーザーが変更を許可されている場合にのみ、変更を受け入れることです。これは、アプリケーションの他の場所と同様です。
パラメータを保護しようとすることには要点がありません。また、それは非常に困難であり、あらゆる種類の問題につながります。たとえば、グループRedの管理者が、この時点で実際にこのグループのメンバーであるユーザーAの編集を開始したとします。管理者はフォームにまったく触れませんが、待機します。それまでの間、ユーザーAはグループBlueに切り替えたため、管理者はこのユーザーを編集できません。ただし、フォームが変更されていないという観察に基づいて、おそらく彼らにそれを行わせるでしょう。
Flecheに同意し、あいまいさを介してセキュリティを確保することは決して良い考えではありません。ユーザーが特定のアクションを実行しているときに、要求されたリソースでそのアクションを実行できることを確認してください。
このようにして、悪意のある管理者は自分がやりたいことをすべて試すことができ、許可されたチームのデータしか変更できません。