WebSocket biztonsága és hibakeresése

Célok

A lecke végére meg tudod mondani, mit véd és mit nem véd az Origin-ellenőrzés, hogyan kell a tartós kapcsolatnál a hitelesítést és a jogosultságot kezelni, és hogyan lehet a kapcsolati hibákat megkülönböztetni és követni.

Miért kell?

Tartós kapcsolatnál a hitelesítés nem egyszeri felmentés minden jövőbeli üzenetre. A kapcsolat hosszabb ideig élhet, mint a token vagy a felhasználó jogosultsága. A feliratkozást, a beérkező műveleteket és a kimenő adatokat egyaránt védeni kell.

Handshake és Origin

Az RFC 6455 szerint a csak bizonyos oldalaknak szánt szervernek ellenőriznie kell az Origin fejlécet, és ha az nem várt, 403 Forbidden státusszal kell elutasítania a kapcsolatot (10.2). Ez véd a cross-site WebSocket hijacking (CSWSH) ellen, amikor egy másik webhelyről indított szkript a felhasználó böngészőjének sütijét használva nyit kapcsolatot. Az OWASP szerint az Origin-t minden handshake-nél explicit engedélyezési listával kell összevetni (nem helyettesítő karakterekkel vagy részszövegekkel), és a munkamenet-sütin SameSite beállítás ajánlott. Az Origin nem erős kliensazonosság: nem böngészős kliens tetszőleges értéket küldhet.

Az RFC 6455 (10.5) szerint a protokoll nem írja elő, hogyan hitelesíti a szerver a klienst a handshake alatt; bármely általános HTTP-mechanizmus (süti, HTTP-hitelesítés, TLS-hitelesítés) használható. A natív böngészői konstruktor nem ad tetszőleges fejlécbeállítást. Az OWASP ajánlása: a token ne kerüljön az URL lekérdezési részébe (naplókba juthat), inkább az első üzenetben kell küldeni; addig nem szabad védett adatot küldeni, a hitelesítés elmaradásakor vagy időtúllépésekor pedig le kell zárni a kapcsolatot; hosszú életű kapcsolatnál a tokent rotálni kell. Titkosítás: wss://, a kapcsolat bizalmasságát és integritását a TLS adja (RFC 6455, 10.6).

Jogosultság minden üzenetnél

Egy orders:customer-42 csatornanév ismerete nem ad hozzáférést. A szerver a hitelesített felhasználó és bérlő alapján ellenőrzi a feliratkozást, és a kimenő eseményeket is szűri. Az OWASP szerint ne tekintsük a WebSocket-kapcsolatot korlátlan hozzáférésnek: minden művelet jogosultságát ellenőrizni kell, nem csak a kapcsolódáskor, ami összecseng a rekordszintű jogosultság elvével (6.7). Jogosultságváltozáskor vagy a munkamenet lejártakor a hozzáférést frissíteni, vagy a kapcsolatot bontani kell; az OWASP időszakos újraellenőrzést javasol.

Üzenetkorlátok

Az OWASP ajánlása: a bejövő üzenetek megbízhatatlanok, ezért séma szerinti validáció, üzenetméret-korlát, műveletsebesség-korlát, kapcsolatok számának korlátja (összesen és felhasználónként), tétlenségi időkorlát és Ping/Pong a halott kapcsolatok eltakarítására. Egy apró üzenet is drága lehet, ha ezer belső hívást indít, ezért a korlát nem csak bájtszámot vizsgál. A hibaválasz ne adjon részletes belső információt.

Hibakeresés több rétegen

Kapcsolati hiba lehet handshake-elutasítás, proxy-időtúllépés, hitelesítési hiba, üzleti elutasítás vagy lassú fogyasztó; ezek kapjanak külön naplókódot. A kapcsolat azonosítója, a felhasználó biztonságos azonosítója és a műveletazonosító köti össze az eseményeket. A „socket closed” kevés: tudni kell, hogy a művelet végrehajtódott-e, a kliens lemaradt-e, és milyen helyreállítási út következik.

HTTP- és RPC-hívásoknál a W3C Trace Context a hívási láncot köti össze: a traceparent fejléc egy kérés helyét rögzíti a nyomkövetésben (verzió, trace-id, parent-id, jelzők), az opcionális tracestate gyártóspecifikus adatot visz. Üzenetküldésnél vagy hosszú életű kapcsolatnál a termelő és a fogyasztó kapcsolatát továbbvitt kontextus vagy nyomkövetési hivatkozás jelezheti; nem minden háttérmunka egy rövid életű kérés folytatása. A mérőszámok ne használjanak minden kapcsolat vagy felhasználó azonosítóját címkeként (korlátlan kardinalitás); az egyedi részletek inkább naplóba vagy nyomkövetésbe kerüljenek.

Jellemzők

Szempont	Biztonság és diagnosztika
Irány	Handshake: kliens → szerver (hitelesítés); utána mindkét irányban
Kezdeményező	A kapcsolatot a kliens; a lezárást bármelyik fél
Kapcsolat tartóssága	Hosszú: a hitelesítés elévülhet
Késleltetés	A hitelesítés és az ellenőrzés plusz költsége
Terhelés	Korlátok nélkül a rosszindulatú kliens kimeríthet erőforrást
Hibatűrés	Bontás, újrahitelesítés, lejáratkezelés
Mikor jó?	Védett, hiteles tartós csatorna
Mikor nem?	Ha a hitelesítés egyszeri belépésnek számít

Gyakori tévhitek

Állítás	Pontosítás
„Az Origin-ellenőrzés kiváltja a hitelesítést.”	Csak böngészős támadás ellen véd; nem erős azonosság.
„A csatorna nevének ismerete hozzáférést ad.”	A szervernek ellenőriznie kell a jogosultságot.
„A hitelesítés a kapcsolódáskor egyszer elég.”	A jogosultság és a token lejárhat.
„A token az URL-ben kényelmes.”	Naplókba kerülhet; az első üzenet vagy rövid életű jegy jobb.

Röviden

• Az Origin-t ellenőrizni kell CSWSH ellen, de nem azonosság.
• A tokent ne tedd URL-be; az első üzenet vagy rövid életű jegy jobb.
• Minden műveletnél ellenőrizd a jogosultságot; korlátozd az üzenetméretet, sebességet és kapcsolatszámot.
• A hibakódok és a Trace Context segítik a követhetőséget; ne használj kapcsolatazonosítót metrikacímkének.

Ellenőrző kérdések

1. Miért nem helyettesíti az Origin a hitelesítést?
2. Hogyan szűnik meg egy visszavont jogosultság egy tartós kapcsolatban?
3. Milyen adat alapján különítenéd el a proxyhibát és az üzleti elutasítást?

Források

• WebSocket Security Cheat Sheet (OWASP)
• RFC 6455, 10: Security Considerations
• Trace Context (W3C)