TCP JavaScriptのソケットがサポートされない理由
現在WebSocketがあることは知っていますが、既存のプロトコルとの対話を可能にするソケットAPIを提供することの問題は何ですか？
つまり、結局のところ、非表示のフラッシュオブジェクトを使用して既に同じことができます。私が見逃している攻撃ベクトルはありますか？
...しかし、既存のプロトコルとの相互作用を可能にするソケットAPIを提供することの問題は何ですか？
これは言語自体の制限ではなく、ブラウザ内のサンドボックス内での使用です。インターネット上のどこかにあるスクリプトがブラウザに読み込まれ、ブラウザ内から任意のプロトコルでブラウザが到達可能なすべてのコンピュータにアクセスできると想像してみてください。これを簡単に悪用して、企業の内部メールサーバーを介してスパムを送信したり、他の内部および外部リソースを攻撃/悪用したりすることができます。
つまり、いくつかの制限を設ける必要があり、言語ランタイムごとに異なるサンドボックス環境では、異なる種類の制限が提供されます。
- フラッシュでは、ターゲットホストは適切なソケットポリシーファイルを提供することにより、明示的にアクセスを許可する必要があります。これは HTML5 CORS 内のメカニズムに似ています。
- Untrusted Javaアプレットは、アプレットを提供するホストとの通信に限定されます。
- また、ブラウザ内のJavaScriptを使用すると、ほぼすべてのサイトと通信できますが、使用できるプロトコル、つまりHTTP（CORSによって制限されます）とWebSocketによって制限されます。
FlashオブジェクトがどのソケットAPIアクセスを提供するかはわかりませんが、JavaScriptで単純なTCPまたはUDP（他の種類の）ソケット）を許可しないことには非常に十分な理由があります。
おそらく、最大のものは、ファイアウォールをバイパスする方法を基本的に提供していることです。ループバックネットワークソケットをリッスンするマシン上のすべてのサービスは、通常、外部の攻撃者からは到達できませんが、ブラウザーから攻撃される可能性があります。ネットワーク上のすべてのマシンは、通常ゲートウェイとファイアウォールによってインターネットから隔離されていますが、インターネットコードによってアクセスまたは攻撃される可能性があります。
他の理由もあります。ブラウザーがプラグインを使わずにポートスキャンとDDOS攻撃を実行できると、はるかに簡単になります（はい、ブラウザーはHTTP（S）サーバーでDDOSを起動しようとすることができますが、低レベルでははるかに効率的ですソケット）。ネットワークワーム（特に、マシンのごく一部のみが脆弱であるワーム）は、実際に感染しているものだけでなく、人気のあるWebサイトで広告を表示するすべての人が攻撃を送信し始めると、はるかに速く伝播します。
WebSocketは、信頼できないコードを実行しているブラウザと明示的に通信したいものとソケット通信を行う方法を提供するために存在します。典型的なインターネットサーバーも同様に強化されており、あらゆる種類の悪意のあるクライアントを想定しています。問題は、信頼できるクライアントからしか到達できないため、悪意のあるトラフィックを予期するnotのサービスから発生します。 JS制御のソケットはそれを完全に壊します。