Programmering av WebSockets og sanntidssystemer · leksjon

Forebygging av vanlige WebSocket-angrep

Lær om og reduser trusler som Cross-Site WebSocket Hijacking, DDoS og meldingsinjeksjon.

Leksjon 3 av 411 trinn

Forebygging av vanlige WebSocket-angrep er en gratis leksjon i Programmering av WebSockets og sanntidssystemer på CoddyKit. Dette er leksjon 3 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Programmering av WebSockets og sanntidssystemer, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Programmering av WebSockets og sanntidssystemer inneholder totalt 4 leksjoner.

Hvorfor WebSocket-sikkerhet er viktig

WebSockets muliggjør effektiv kommunikasjon i sanntid, men denne muligheten medfører særlige sikkerhetshensyn. I motsetning til tradisjonelle HTTP-forespørsler er WebSocket-tilkoblinger vedvarende og toveis, noe som skaper nye angrepsvektorer.

Hvis sikkerheten ignoreres, kan applikasjonen og brukerne Deres utsettes for betydelig risiko, fra datalekkasjer til tjenestenekt.

Forstå vanlige trusler

La oss se på noen utbredte angrepstyper som rammer WebSocket-applikasjoner:

  • Cross-Site WebSocket Hijacking (CSWH): Å lure en brukers nettleser til å koble til en ondsinnet server.
  • Denial of Service (DoS/DDoS): Å overbelaste serveren med for mange tilkoblinger eller meldinger.
  • Meldingsinjisering: Å sende ondsinnede data i WebSocket-meldinger for å utnytte sårbarheter.

Cross-Site WebSocket Hijacking (CSWH)

CSWH er et angrep der et ondsinnet nettsted forsøker å opprette en WebSocket-tilkobling til den legitime WebSocket-serveren Deres ved hjelp av offerets nettleser og informasjonskapsler.

Selv om nettleserens Same-Origin Policy begrenser AJAX-forespørsler, er reglene mindre strenge for initiering av WebSocket-tilkoblinger. Det betyr at et ondsinnet nettsted kan forsøke å koble til serveren Deres, og hvis det lykkes, potensielt sende meldinger på brukerens vegne.

Hindre CSWH: validering av opprinnelse

Det viktigste forsvaret mot CSWH er validering av opprinnelse på serversiden. Når en WebSocket-tilkobling initieres, sender nettleseren et Origin-hode som angir domenet forespørselen kommer fra.

Serveren bør kontrollere dette hodet og bare tillate tilkoblinger fra klarerte opprinnelser (Deres eget domene).

// 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
  }
});

Tjenestenekt (DoS/DDoS)

Et DoS-angrep forsøker å gjøre en tjeneste utilgjengelig ved å overbelaste den med trafikk. For WebSockets kan dette innebære:

  • Tilkoblingsflom: Å åpne for mange samtidige tilkoblinger slik at serverressursene tømmes.
  • Meldingsflom: Å sende enorme mengder meldinger som bruker opp prosessor- og båndbreddekapasitet.

Et DDoS-angrep er tilsvarende, men bruker flere kompromitterte systemer (et botnett) til å utføre angrepet, noe som gjør det vanskeligere å blokkere.

Begrense DoS: hastighetsbegrensning

Hastighetsbegrensning er et viktig forsvarstiltak. Det begrenser hvor mange forespørsler eller tilkoblinger en klient kan opprette innenfor et bestemt tidsrom. Dette hindrer én enkelt klient (eller noen få klienter i et DDoS-scenario) i å overbelaste serveren.

De kan implementere hastighetsgrenser basert på IP-adresse, autentisert bruker eller til og med antall tilkoblinger.

// 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!

Beskyttelse mot meldingsinjisering

Meldingsinjisering oppstår når en angriper sender ondsinnede data i en WebSocket-melding, som deretter behandles eller vises av serveren eller andre klienter uten tilstrekkelig rensing.

Vanlige former omfatter:

  • Cross-Site Scripting (XSS): Å injisere JavaScript som kjøres i andre brukeres nettlesere.
  • SQL Injection: Hvis WebSocket-meldinger brukes direkte i databaseforespørsler (sjeldent, men mulig i komplekse systemer).

Validering av inndata og koding av utdata

Det beste forsvaret mot meldingsinjeksjon er en strategi med to deler:

  • Validering av inndata: Valider alle innkommende WebSocket-meldinger strengt på serveren. Kontroller datatyper, lengder og forventede formater, og avvis alt som virker mistenkelig.
  • Koding av utdata: Kod alltid brukergenerert innhold før det vises i en nettleser. Da blir potensielt skadelig HTML/JS gjort om til ufarlig tekst.
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.");

Lagvis beskyttelse

Ingen enkeltstående sikkerhetstiltak er helt sikkert. En robust WebSocket-applikasjon bruker flere lag med beskyttelse:

  • Autentisering og autorisering: (Dekket i tidligere leksjoner) Sørg for at bare legitime og autoriserte brukere kan koble til og sende meldinger.
  • Validering av opphav: Forhindrer CSWH.
  • Frekvensbegrensning: Reduserer virkningen av DoS-angrep.
  • Validering av inndata og koding av utdata: Beskytter mot meldingsinjeksjon.
  • TLS (WSS): Krypterer all kommunikasjon (dekket i leksjon 1 i dette kurset).

Kort kontroll: strategier for skadebegrensning

Hvilke av følgende er effektive strategier for å redusere virkningen av vanlige WebSocket-angrep?

Oppsummering: Sikring av WebSocket

I denne leksjonen utforsket vi kritiske sikkerhetstrusler mot WebSocket-applikasjoner og hvordan de kan håndteres:

  • Vi lærte om Cross-Site WebSocket Hijacking (CSWH) og forhindret det med validering av opphav på serversiden.
  • Vi lærte om Denial of Service (DoS/DDoS)-angrep og hvordan frekvensbegrensning kan redusere virkningen av dem.
  • Vi håndterte meldingsinjeksjon ved å bruke grundig validering av inndata og nøye koding av utdata.

Husk alltid å bruke flere lag med sikkerhet for best mulig beskyttelse!

Gratis å komme i gang

Lær deg Programmering av WebSockets og sanntidssystemer med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs
12
Leksjoner
47

Ofte stilte spørsmål

Er leksjonen «Forebygging av vanlige WebSocket-angrep» gratis?

Ja – hele teksten i «Forebygging av vanlige WebSocket-angrep» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av Programmering av WebSockets og sanntidssystemer-kurset, kan du oppgradere til CoddyKit PRO. Kurset i Programmering av WebSockets og sanntidssystemer inneholder totalt 4 leksjoner.

Hva lærer jeg i «Forebygging av vanlige WebSocket-angrep»?

Lær om og reduser trusler som Cross-Site WebSocket Hijacking, DDoS og meldingsinjeksjon. Du øver på Programmering av WebSockets og sanntidssystemer med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Programmering av WebSockets og sanntidssystemer?

Ingen tidligere erfaring er nødvendig. Programmering av WebSockets og sanntidssystemer på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 3 av 4.

Hvor lang tid tar leksjonen «Forebygging av vanlige WebSocket-angrep»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne Programmering av WebSockets og sanntidssystemer-leksjonen?

Ja. Alle Programmering av WebSockets og sanntidssystemer-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

  1. WebSocket Secure (WSS) og TLS
  2. Autentisering og autorisasjon
  3. Forebygging av vanlige WebSocket-angrep
  4. Ratebegrensning og forebygging av misbruk
← Tilbake til Programmering av WebSockets og sanntidssystemer