web-dev-qa-db-ja.com

JavaScriptでクロスiframeキーのログ記録を防止する

他のパートナーが自分のページをiframeとして含めることができるWebアプリケーションがあります。サーバー間でiframeのユーザーを認証する方法を実装しましたが、1つのパートナーがそれを実装したくありません。

悪い点は、JavaScriptキーロガーに対して脆弱にならないようにするために、ログインページをiframeに表示したくないことです。

私たちは常にsandbox="allow-forms allow-scripts allow-top-navigation-by-user-activation allow-same-Origin"を使ってiframeにバインドします。もちろん、これは私たちのセキュリティを保証するためです。iframeサーバーがサンドボックスのアクティブ化を要求できる場所を見つけることができませんでした。彼らがそれを行う方法はありますか、それとも彼らは私たちを信頼する必要がありますか?

また、sandbox属性は、フォーカスがiframeにある間に作成されたキーストロークを記録できないことを保証しますか? -保証されると思っていましたが、文書化されている場所にはありませんでした。

Iframeが悪意のあるページに読み込まれないようにするサーバーに関しては、ヘッダーでホワイトリストを作成するだけです https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options または?

1
peter

あなたが述べたように、彼らの最善の方法はX-Frame-Optionsヘッダーをオンにすることです。

これを指摘しても問題は解決しませんが、ヘッダーがない場合は、いずれにしても、iframe関連のさまざまな攻撃に対して脆弱であることが現実です。彼らのサイトをiframeにロードしようとしても、もはや脆弱ではありません-とにかく彼らがすでに脆弱であるという脅威に気づくだけです。とにかく、あなたがやっていることを制限しようとする彼らは、おそらく彼らをより安全にすることはありません。あなたがあなたの意図を発表しているとしても、攻撃者はそうしないからです。

より一般的な回答として、同じOriginポリシーにより、サイトはiframeanyway内のキーストロークをリッスンできません(-を参照)。 この質問 出発点)。結果として、彼らの差し迫った懸念は実際には根拠のないものです。 iframeでは、 clickjacking を気にする必要があります。これはX-Frame-Optionsヘッダーを介して解決されます。

ただし、ここでも実際には関係ありません。要約すると、ユーザーがサイトにログインし、システムを介してサードパーティのサイトにアクセスするソリューションを実装しようとしています。本質的に、これはSSOのバリエーションです。それを理解し、彼らの視点から物事を見ると、元の提案(サーバー間認証)は本当に理想的なソリューションです。それらの利点は、特定のユーザーセッションが自分からのものであることを簡単に記録できることです。その結果、そのセッション中に「異常」が発生した場合、発生する可能性のあるすべての問題について、潜在的に(かつ正確に)責任を負う可能性があります。もちろん、彼らは単に(何らかの理由で)あなたが達成しようとしていることに参加したくないだけかもしれません。明らかに、彼らは彼らのビジネスにとって最善であると彼らが感じる場合、彼らはその決定をする権利を持っています。

1
Conor Mancone