私は、リクエスト パラメータとしてorgIdとレガシー システム (Java アプリケーション)で構成されるiFrameリンクを介して、salesforce.com をレガシー システムと統合する途中です。リクエスト パラメータとして orgId を取得すると、レガシー システムのデータベースをチェックします。存在するということは、Salesforce ユーザーが従来のシステム アプリケーションへのアクセス権を付与されていることを意味します)。したがって、侵入者が何らかの方法で orgId を取得した場合、侵入者は従来のシステム アプリケーションに簡単にアクセスできるため、そのような攻撃を阻止することが課題となります。参考までに、iFrame リンクとセールスフォース サイトは両方とも https プロトコルで実行されます。
2 に答える
Org Id に加えて、アクティブな Salesforce SessionId と ServerURL をクエリ文字列で渡すこともできます。その後、レガシー アプリケーションはこれらを使用して、Salesforce に戻る SOAP API セッションを確立し、OrgId がセッションの詳細と一致することを検証できます。
次に、侵入者は現在のユーザーの Salesforce セッションに完全にアクセスして、iframe 経由でレガシー アプリにアクセスする必要があります。そうした場合、セキュリティはすでに十分に侵害されており、より大きな問題が発生しています。
静的 orgId を使用する代わりに、動的トークンを使用できます。これを実装する方法はいくつかあります。たとえば、トークンを暗号化して orgId とタイムスタンプの両方を含めるように設計し、タイムスタンプを Salesforce で動的に生成して、X 分/秒有効なトークンのみを許可することができます (ユーザーがレガシー アプリをどのように使用するかによって異なります)。
侵入者が (orgId が保持されている) salesforce アカウントにアクセスできる場合、侵入者がレガシー アプリにアクセスするのを防ぐことはできません。誰かが悪用した場合に後で取り消すことができるトークン。
これは、legacyapp のユーザーがサインアップするとき (または、orgId を最初に Salesforce に保存するために必要なプロセス) であり、orgId を保持するのではなく、レガシー アプリを呼び出してトークンを生成します (これはレガシー アプリのデータベースに保存されます)。後で iFrame で使用できます。