10. Security Considerations (セキュリティに関する考慮事項)
WebSocketプロトコルの設計は、複数のセキュリティ脅威を考慮しています。本章では、主要なセキュリティ考慮事項と推奨される緩和策について説明します。
10.1 Non-Browser Clients (非ブラウザクライアント)
WebSocketプロトコルは、Webブラウザに限定されず、任意のクライアントで使用できます。非ブラウザクライアントには、ブラウザの同一生成元ポリシー保護がありません。
リスク:
- Originヘッダーを偽造できる
- CORS制限を回避できる
- 大量の接続を開始できる
緩和策:
- サーバー側で追加の認証を実装しなければならない (MUST)
- トークン検証を使用(例:JWT)
- レート制限を実装
- すべての入力データを検証
// サーバー側検証の例
function verifyClient(info, callback) {
const allowedOrigins = ['https://example.com'];
if (!allowedOrigins.includes(info.origin)) {
callback(false, 403, 'Forbidden');
return;
}
const token = info.req.url.split('?token=')[1];
if (!isValidToken(token)) {
callback(false, 401, 'Unauthorized');
return;
}
callback(true);
}
10.2 Origin Considerations (生成元に関する考慮事項)
Originヘッダーは重要なセキュリティメカニズムです。
推奨される実践:
- Originを検証: サーバーはOriginヘッダーを検証すべき (SHOULD)
- ホワイトリスト方式: ブラックリストではなくホワイトリストを使用
- 動的Origin: 動的Originをサポートする必要がある場合は、データベース設定を使用
注意: 非ブラウザクライアントはOriginを偽造できるため、Origin検証のみに依存すべきではありません。
10.3 Attacks On Infrastructure (インフラストラクチャへの攻撃)
キャッシュポイズニング攻撃
WebSocketは、キャッシュポイズニングを防ぐためにマスキングメカニズムを使用します:
- クライアントからサーバーへのすべてのフレームはマスクされなければならない (MUST)
- サーバーからクライアントへのフレームはマスクしてはならない (MUST NOT)
- ランダムなマスキングキーを使用
中間者攻撃
緩和策:
- wss://を使用 (TLS暗号化)
- サーバー証明書を検証
- 証明書ピンニングを実装
// ブラウザ: 常にwss://を使用
const ws = new WebSocket('wss://example.com/socket');
// サーバー: TLSを強制
if (!request.connection.encrypted) {
response.status(403).send('TLS required');
}
10.4 Implementation-Specific Limits (実装固有の制限)
実装は、リソース枯渇攻撃を防ぐために合理的な制限を設定すべきです (SHOULD)。
推奨される制限
1. メッセージサイズ制限
const MAX_MESSAGE_SIZE = 1024 * 1024; // 1MB
ws.on('message', (data) => {
if (data.length > MAX_MESSAGE_SIZE) {
ws.close(1009, 'Message too big');
}
});
2. 接続数制限 3. メッセージレート制限
10.5 WebSocket Client Authentication (WebSocketクライアント認証)
認証方法
- ハンドシェイク時のCookie認証
- URLパラメータ内のトークン
- 最初のメッセージ認証
- カスタムハンドシェイクヘッダー
10.6 Connection Confidentiality and Integrity (接続の機密性と完全性)
TLS/SSL要件
本番環境ではwss://を使用しなければならない (MUST):
✅ TLSの利点:
- すべての送信データを暗号化
- 盗聴を防止
- データの改ざんを防止
- サーバー認証
❌ ws://のリスク:
- 平文送信
- 傍受が容易
- サーバーIDを検証できない
10.7 Handling of Invalid Data (無効なデータの処理)
実装は、セキュリティ脆弱性を防ぐために無効なデータを適切に処理しなければなりません (MUST)。
無効なUTF-8テキスト
プロトコル違反
プロトコル違反が検出された場合、接続をクローズしなければなりません (MUST)。
10.8 Use of SHA-1 by the WebSocket Handshake (WebSocketハンドシェイクによるSHA-1の使用)
ハンドシェイクはSHA-1ハッシュアルゴリズムを使用します。SHA-1には既知の衝突攻撃がありますが、ハンドシェイクのコンテキストでは安全です。
セキュリティチェックリスト
WebSocketサービスを実装する際にチェックすべき項目:
- ws://ではなくwss:// (TLS)を使用
- Originヘッダーを検証
- 認証と認可を実装
- メッセージサイズ制限を設定
- 接続数制限を設定
- レート制限を実装
- すべての入力データを検証
- プロトコル違反を適切に処理
- セキュリティイベントをログに記録
- TLS設定を定期的に更新
- 異常な接続パターンを監視
- タイムアウトメカニズムを実装