次のシナリオを検討してください。
事業主は最初に単一の顧客を選択し、それ以降、彼のセッションは選択された顧客にバインドされます。
私は一連のマイクロサービスを持っており、それぞれが処理のためにCustomer-ID
を必要とします。つまり.
GET /resource-a/{customer-id}
を公開しますPOST /resource-b/{customer-id}
を公開しますCustomer-Id
は機密情報と見なされるため、暗号化された形式になります。
ただし、それでもprivilege-escalationに対して脆弱です。つまり、あるビジネスオーナーが、暗号化された顧客IDをブックマークなどを介して誤って共有し、ビジネスオーナーが自分にマップされていない顧客の詳細にアクセスする可能性があります。 (正確には特権昇格ではありませんか?)
Customer-Id
を暗号化することはできません(ステートフルマイクロサービス/セッションがないため)この状況で特権の昇格を防ぐにはどうすればよいですか?
サーバー側でこれを実行したくないことを考えると、他に2つの可能性しかありません。
security through obscurity
を使用し、ユーザー向けにCustomer-Id
を公開しないでください(アドレスバー、UI、ブラウザーの履歴などに表示されるアクション)。これによって問題が修正されることはなく、専用の攻撃者から保護されることもありません。ある程度は効くかもしれませんが。customer-id's
をトークン自体に保存します。次に、サーバー側でセッショントークンを確認すると、同時に認証も取得されます。これは、パフォーマンスにまったくコストがかかりません。ただし、ユーザーにcustomer-ids
が大量にバインドされていない場合にのみ、ソリューションとして機能する可能性があります(明らかに、トークンにDB全体を含めたくない場合)。