html5 websocketを使用してファイアウォールをバイパスするTCPポリシー
私は、html5が「websocket」機能でクライアント側からtcpソケットを開くことができることを読みました。
私が覚えているファイアウォールは、SYNパケットを探すことによって「外部」から開始されたtcp接続をブロックするように構成されているかもしれませんが、このhtml5機能を利用すると、このポリシーを単純化してバイパスできます。
ここで何か不足していますか？これらの暗黙的なオープンソケットコールを監視するのは誰ですか？この動作は無料で提供される「リバースtcpシェル」のようです...
最初に、WebSocket接続は、クライアントのWebブラウザによって実行されるJavaScriptから初期化されます。つまり、一般的なWebSocket接続は、受信接続ではなく送信接続です。インバウンドWebSocket接続は、ホストがWebSocketserverを実行している場合にのみ可能です。通常のブラウザは通常これを行いません。そして、ホストが何らかの理由でwebsocketサーバーを実行している場合でも、通常のクライアントネットワークで適切に構成されたファイアウォールは、これを回避できます。
第二に、websocketは正常ではありませんTCPソケット。TCPに加えてカスタムフレーミングプロトコルを使用します。つまり、websocket接続は、websocketプロトコルを理解するサービスに対してのみ開くことができます。 websocket APIを使用してユーザーをリモートホストに接続（試行）させることはできますが、websocket経由での使用を目的としていないサービスを使用させることはできません。
第三に、これは「リモートTCPシェル」ではありません。これは、websocketがwebブラウザーのjavascriptエンジンと現在アクセスしているHTMLドキュメントのコンテキストにのみ存在するためです。ユーザーがローカルマシンで何かを行うために持っている以上の権限を訪問しているWebサイト。確かに、それはJavaScriptアプリケーションにリモートサーバーと通信する機能を提供しますが、これを行う方法はすでにたくさんありました。 AJAX。
では、どのような虐待の可能性が残っているのでしょうか？
悪意のあるWebサイトの所有者として、ユーザーをWebSocketサーバーに接続させ、それに悪意のある活動を実行させるJavaScriptを広めることができました。これを使用して、訪問者をスパムゾンビに変え、他の誰かがWebSocketベースのアプリケーションをスパムすることができます。 しかしwebsocketにはこれを防ぐための組み込み機能があります。ユーザーのWebブラウザーは、すべてのWebソケット接続でWebサイトのURLを送信します。つまり、サービスは既知のURLに由来しない接続を簡単に無視できます。
詳細については、プロトコル自体を説明する RFC-6455 とWebブラウザのJavaScript APIの W3C標準 をお勧めします。
WebSocketは単純ではありませんTCPソケットですが、TCPソケットはHTTPトンネル内で動作します。実際にそれらを使用して任意のポートに接続するために、 「実際の」TCP= WebSocketから要求されたポートへの接続を行うサーバー側のバックエンドがあります。
それとは別に、この質問はsecurity.stackexchange.comでよりよく尋ねられます。