WebSockets & Realtime Systems Programming · レッスン

一般的なWebSocket攻撃の防止

Cross-Site WebSocket Hijacking、DDoS、メッセージインジェクションなどの脅威について学び、対策を講じます。

「一般的なWebSocket攻撃の防止」はCoddyKit上の無料WebSockets & Realtime Systems Programmingレッスンです。これはレッスン3/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはWebSockets & Realtime Systems Programming学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 WebSockets & Realtime Systems Programmingコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Why WebSocket Security Matters

WebSockets enable powerful, real-time communication, but this power comes with unique security considerations. Unlike traditional HTTP requests, WebSocket connections are persistent and bidirectional, creating new attack vectors.

Ignoring security can expose your application and users to significant risks, from data breaches to denial of service.

Understanding Common Threats

Let's explore some prevalent attack types that target WebSocket applications:

Cross-Site WebSocket Hijacking (CSWH): Tricking a user's browser into connecting to a malicious server.
Denial of Service (DoS/DDoS): Overwhelming the server with too many connections or messages.
Message Injection: Sending malicious data within WebSocket messages to exploit vulnerabilities.

Cross-Site WebSocket Hijacking (CSWH)

CSWH is an attack where a malicious website attempts to initiate a WebSocket connection to your legitimate WebSocket server, using the victim's browser and cookies.

While the browser's Same-Origin Policy restricts AJAX requests, it's less strict for WebSocket connection initiation. This means a malicious site can try to connect to your server, and if successful, potentially send messages on behalf of the user.

Preventing CSWH: Origin Validation

The primary defense against CSWH is server-side Origin Validation. When a WebSocket connection is initiated, the browser sends an Origin header, indicating the domain from which the request originated.

Your server should check this header and only allow connections from trusted origins (your own domain).

// Example (Node.js with 'ws' library)
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });

const allowedOrigins = ['http://localhost:3000', 'https://your-app.com'];

wss.on('connection', function connection(ws, req) {
  const origin = req.headers.origin;
  if (allowedOrigins.includes(origin)) {
    console.log('Client connected from allowed origin:', origin);
    ws.send('Welcome!');
  } else {
    console.log('Client connection blocked from origin:', origin);
    ws.close(1008, 'Forbidden'); // 1008: Policy Violation
  }
});

Denial of Service (DoS/DDoS)

A DoS attack aims to make a service unavailable by overwhelming it with traffic. For WebSockets, this can involve:

Connection Flooding: Opening too many concurrent connections, exhausting server resources.
Message Flooding: Sending a massive volume of messages, consuming CPU and bandwidth.

A DDoS attack is similar but uses multiple compromised systems (a botnet) to launch the attack, making it harder to block.

Mitigating DoS: Rate Limiting

Rate limiting is a key defense. It restricts the number of requests or connections a client can make within a specific time frame. This prevents a single client (or a few clients in a DDoS scenario) from overwhelming your server.

You can implement rate limits based on IP address, authenticated user, or even connection count.

// Conceptual example for connection rate limiting
const clientConnections = new Map(); // Map<IP, count>
const MAX_CONNECTIONS_PER_IP = 5;

function allowConnection(ip) {
  const currentCount = clientConnections.get(ip) || 0;
  if (currentCount < MAX_CONNECTIONS_PER_IP) {
    clientConnections.set(ip, currentCount + 1);
    return true;
  }
  return false;
}

// On new connection:
// const clientIp = req.connection.remoteAddress;
// if (!allowConnection(clientIp)) {
//   ws.close(1008, 'Rate limit exceeded');
// }
// Remember to decrement count on disconnect!

Protecting Against Message Injection

Message injection occurs when an attacker sends malicious data within a WebSocket message, which is then processed or displayed by the server or other clients without proper sanitization.

Common forms include:

Cross-Site Scripting (XSS): Injecting JavaScript that executes in other users' browsers.
SQL Injection: If WebSocket messages are used directly in database queries (rare, but possible in complex systems).

Input Validation & Output Encoding

The best defense against message injection is a two-pronged approach:

Input Validation: On the server, strictly validate all incoming WebSocket messages. Check data types, lengths, expected formats, and reject anything suspicious.
Output Encoding: Before displaying any user-generated content in a web browser, always encode it. This turns potentially malicious HTML/JS into harmless text.

function processMessage(message) {
  // 1. Input Validation (server-side)
  if (typeof message !== 'string' || message.length > 100) {
    console.log("Invalid message format or length.");
    return;
  }
  // Basic check for script tags (use a robust library in production)
  if (/<script>/i.test(message)) {
    console.log("Potential script injection detected.");
    return;
  }

  // 2. Output Encoding (client-side before display)
  function encodeHTML(str) {
    const div = document.createElement('div');
    div.appendChild(document.createTextNode(str));
    return div.innerHTML;
  }

  const cleanMessage = encodeHTML(message);
  // In a real app, send cleanMessage to other clients
  console.log("Cleaned message for display: " + cleanMessage);
}

console.log("--- Testing Message Processing ---");
processMessage("Hello world!");
processMessage("User input: <script>alert('XSS');</script>");
processMessage("A very long message that definitely exceeds the 100 character limit set for this example validation process.");
processMessage("Another safe message.");

Layering Your Defenses

No single security measure is foolproof. A robust WebSocket application employs multiple layers of defense:

Authentication & Authorization: (Covered in previous lessons) Ensure only legitimate, authorized users can connect and send messages.
Origin Validation: Prevent CSWH.
Rate Limiting: Mitigate DoS attacks.
Input Validation & Output Encoding: Guard against message injection.
TLS (WSS): Encrypt all communication (covered in Lesson 1 of this course).

Quick Check: Mitigation Strategies

Which of the following are effective strategies to mitigate common WebSocket attacks?

Recap: Securing Your WebSockets

In this lesson, we explored critical security threats to WebSocket applications and how to defend against them:

We understood Cross-Site WebSocket Hijacking (CSWH) and prevented it with server-side Origin Validation.
We learned about Denial of Service (DoS/DDoS) attacks and how rate limiting can mitigate them.
We tackled message injection by applying rigorous input validation and careful output encoding.

Always remember to layer your security defenses for the most robust protection!

よくある質問

「一般的なWebSocket攻撃の防止」レッスンは無料ですか？

はい。「一般的なWebSocket攻撃の防止」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、WebSockets & Realtime Systems Programmingコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 WebSockets & Realtime Systems Programmingコースには全4レッスンが含まれています。

「一般的なWebSocket攻撃の防止」で何を学びますか？

Cross-Site WebSocket Hijacking、DDoS、メッセージインジェクションなどの脅威について学び、対策を講じます。ブラウザで直接実行するハンズオンコードでWebSockets & Realtime Systems Programmingを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

WebSockets & Realtime Systems Programmingを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのWebSockets & Realtime Systems Programmingは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン3/4です。

「一般的なWebSocket攻撃の防止」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このWebSockets & Realtime Systems Programmingレッスンでコードを書いて実行できますか？

はい。すべてのWebSockets & Realtime Systems Programmingレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← WebSockets & Realtime Systems Programmingに戻る