サードパーティサイトで実行されているJavaScriptを保護します

Question

サードパーティのWebサイトで実行される「ウィジェット」、つまり、私たちのサービスにサインアップしてJavaScriptを埋め込む人は誰でもあります。

現時点では、すべての通信にJSONPを使用しています。 IFRAMEと魔法を使用して、ロードイベントを検出することにより、人々に安全に署名し、アカウントを作成できます。 （本質的に、IFRAMESソースがクライアントドメインを指してから、タイトルのタイトルから成功価値を読むまで待ちます）。

JSONPで実行されているため、ブラウザHTTP Cookieを使用して、ユーザーがログインしているかどうかを検出できます。

ただし、システムを移行して、リアルタイムおよびWebソケットを介して実行する過程にあります。認証のための同じ方法はまだありますが、JSONPを使用して他の電話をかけることは必ずしもありません。代わりに、これらの呼び出しはWebSocketsで発生します（ライブラリFayeを使用）

どうすればこれを確保できますか？潜在的なセキュリティホールは、誰かが既存のサイトからJavaScriptをコピーし、それを変更し、代わりに人々にサイトにアクセスしてもらう場合です。これは、悪意のあるJavaScriptがそれを読むことができるので、ログイン時に安全なトークンを送り返すという私の当初のアイデアを打ち負かすと思います。

通常のJSONPとWebSocketsでの更新を介して実行されている安全なアクションを維持したほうがいいですか？

Answer 1

WebSocket接続は、開口部の握手中にのみCookieを受け取ります。 WebSocket Connectionにアクセスできる唯一のサイトはそれを開いたサイトです。したがって、認証後に接続を開いている場合、あなたのセキュリティは現在のJSONP実装に匹敵すると思います。

それは、JSONPの実装が安全であるということではありません。そうではないことはわかりませんが、JSONPリクエストのリファラーをチェックして、ログインしたのと同じ第3パーティのサイトから実際に来ていることを確認していますか？そうでない場合は、javaScriptを埋め込む他のサイトからすでにセキュリティの問題があります。

いずれにせよ、XSSの脆弱性を持つサードパーティも 非常に大きな問題, 、しかし、おそらくあなたはすでにそれを知っています。

Answer 2

BROWSERによるWebSocket Handshakeを開く際にCookieを送信するかどうか（およびその場合、Cookie）はWS仕様では指定されていません。ブラウザベンダーに任されています。

WS接続を開くことができます どれか サイトは、元々接続を行うJSに役立つサイトだけでなく、サイトだけではありません。ただし、ブラウザは、WSオープニングハンドシェイクに「Origin」HTTPヘッダーを、元々JSを使用したものに設定する必要があります。サーバーは、接続を自由に受け入れるか拒否できます。

IEはJSでランダムな文字列を生成し、そのクライアント側を保存して、それに加えてクライアントIPがWSの認証トークンの計算に参加することができます。