1

私は websocket でいくつかの作業を行っており、セキュリティに対処する必要があります。私が読んだことから、私の状況では SSL が最良のアプローチであることは明らかなので、WSS を使用することをお勧めします (これは問題ではなく、単なる事実の表明です)。

サーバーは大量のデータをクライアントにストリーミングする場合があります。データはプライベートでも機密でもないので、誰かがデータを盗聴する心配はありません. 私の主な懸念は、サーバーでコマンドを受信すると有害で破壊的な可能性があるため、WS 接続が検証されることです。クライアントは信頼されている必要があります。

サーバーは、処理能力が制限された組み込みデバイスになります。したがって、データは WS を介して平文で送信できるというのが私の見解です。

したがって、私のアプローチは、クライアントが wss してサーバーに接続し、認証してセッション キーを要求することです。次に、クライアントは wss 接続から切断し、ws を介してサーバーに接続し、前の wss 接続から受け取ったセッション キーを渡します。サーバーは、接続が有効なセッション キー (セッション キーの適切な有効期限付き) をすぐに渡す場合にのみ ws 接続を受け入れます。クライアントごとに ws 経由でのみ 1 回の接続試行が許可され、wss 接続が成功するとリセットされます。

したがって、私の質問は、このアプローチが合理的かどうか、または私のアプローチに深刻な脆弱性があるかどうかです。私は ws と wss に制限されています。サーバーでは websocket-node で node.js を使用し、クライアントでは純粋な javascript を使用しています。

4

1 に答える 1

1

これはかなり妥当に思えます (サーバーからクライアントへのアクセスが本当に秘密でないと仮定すると)。ただし、いくつかのバリエーションをお勧めします。

  • クライアントからサーバーへの 2 つの WebSocket 接続を保持するだけです。1つ目はwssで、トークン交換とクライアントからサーバーへのコマンドに使用されます（これは有害である可能性があると述べました）。最初の接続が切断またはタイムアウトした場合は、ws 接続も終了する必要があります。
  • ws 接続を介したサーバー コマンド/制御をクライアントに許可しないでください。
  • タイムアウトに加えて、トークンは一度しか使用できないことを確認してください。そうしないと、攻撃者が ws 接続を傍受し、トークンをリプレイして接続を取得する可能性があります。

また、最初の wss 接続が (暗号化されているだけでなく) 許可されていることも確認する必要があります。つまり、サーバーは、クライアントが本人であり、この接続を確立する権限を持っていることを確認できる必要があります。また、ws 接続が本当に保護されていないサーバーからクライアントへのデータであり、傍受されても問題ない場合、帯域幅とサーバー CPU を使い果たしているだけなので、攻撃者が接続を確立できたとしても、世界の終わりではありません。 (これも、クライアントからサーバーへのコマンドが wss 接続に限定されていることを前提としています)。

また、サーバーからクライアントへの接続を ws と wss の両方でベンチマークしてみます。追加の CPU 負荷は、予想よりも許容できる場合があります (一部の組み込みデバイスには、ハードウェアにも SSL/TLS オフロードがあります)。

于 2013-01-08T16:41:20.933 に答える