WebSocket Attacks
Last updated
Last updated
Leer & oefen AWS Hacking:HackTricks Opleiding AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Opleiding GCP Red Team Expert (GRTE)
WebSocket-verbindinge word gevestig deur 'n aanvanklike HTTP handdruk en is ontwerp om langdurig te wees, wat bidireksionele boodskappe op enige tyd moontlik maak sonder die behoefte aan 'n transaksionele stelsel. Dit maak WebSockets veral voordelig vir toepassings wat lae latensie of bediener-geïnisieerde kommunikasie vereis, soos lewendige finansiële datastrome.
'n Gedetailleerde verduideliking oor die vestiging van WebSocket-verbindinge kan hier verkry word. In samevatting, WebSocket-verbindinge word gewoonlik geïnisieer via kliënt-kant JavaScript soos hieronder getoon:
Die wss
protokol dui 'n WebSocket-verbinding aan wat met TLS beveilig is, terwyl ws
'n onbeveiligde verbinding aandui.
Tydens die verbinding tot stand kom, word 'n handdruk tussen die blaaier en die bediener oor HTTP uitgevoer. Die handdrukproses behels dat die blaaiers 'n versoek stuur en die bediener antwoordgee, soos in die volgende voorbeelde geïllustreer:
Blaaier stuur 'n handdrukversoek:
Server se handdruk antwoord:
Die verbinding bly oop vir boodskapuitruiling in beide rigtings sodra dit gevestig is.
Belangrike Punten van die WebSocket Handshake:
Die Connection
en Upgrade
koptekste dui die begin van 'n WebSocket-handshake aan.
Die Sec-WebSocket-Version
koptekst dui die verlangde WebSocket-protokolweergawe aan, gewoonlik 13
.
'n Base64-gecodeerde ewekansige waarde word in die Sec-WebSocket-Key
koptekst gestuur, wat verseker dat elke handshake uniek is, wat help om probleme met kasproxies te voorkom. Hierdie waarde is nie vir outentisering nie, maar om te bevestig dat die antwoord nie deur 'n verkeerd geconfigureerde bediener of kas gegenereer is nie.
Die Sec-WebSocket-Accept
koptekst in die bediener se antwoord is 'n hash van die Sec-WebSocket-Key
, wat die bediener se bedoeling om 'n WebSocket-verbinding te open, verifieer.
Hierdie kenmerke verseker dat die handshake-proses veilig en betroubaar is, wat die pad baan vir doeltreffende regte-tyd kommunikasie.
Jy kan websocat
gebruik om 'n rou verbinding met 'n websocket te vestig.
Of om 'n websocat-bediener te skep:
As jy vind dat kliënte verbind is met 'n HTTP websocket vanaf jou huidige plaaslike netwerk, kan jy 'n ARP Spoofing Attack probeer om 'n MitM-aanval tussen die kliënt en die bediener uit te voer. Sodra die kliënt probeer om te verbind, kan jy dan gebruik maak van:
Jy kan die tool https://github.com/PalindromeLabs/STEWS gebruik om bekend kwesbaarhede in websockets outomaties te ontdek, te vingerafdruk en te soek.
Burp Suite ondersteun MitM websockets kommunikasie op 'n baie soortgelyke manier as wat dit vir gewone HTTP kommunikasie doen.
Die socketsleuth Burp Suite uitbreiding sal jou toelaat om beter Websocket kommunikasies in Burp te bestuur deur die geskiedenis te verkry, afluisterreëls in te stel, ooreenkoms en vervang reëls te gebruik, Intruder en AutoRepeater te gebruik.
WSSiP: Kort vir "WebSocket/Socket.io Proxy", hierdie tool, geskryf in Node.js, bied 'n gebruikerskoppelvlak om te vang, af te luister, pasgemaakte boodskappe te stuur en al WebSocket en Socket.IO kommunikasies tussen die kliënt en bediener te sien.
wsrepl is 'n interaktiewe websocket REPL wat spesifiek vir penetrasietoetsing ontwerp is. Dit bied 'n koppelvlak om inkomende websocket boodskappe te observeer en nuwe te stuur, met 'n maklik-om-te-gebruik raamwerk vir outomatisering van hierdie kommunikasie.
https://websocketking.com/ dit is 'n web om te kommunikeer met ander webs deur middel van websockets.
https://hoppscotch.io/realtime/websocket onder ander tipes kommunikasies/protokolle, bied dit 'n web om te kommunikeer met ander webs deur middel van websockets.
In Burp-Suite-Extender-Montoya-Course het jy 'n kode om 'n web te begin met websockets en in hierdie pos kan jy 'n verduideliking vind.
Cross-site WebSocket kaping, ook bekend as cross-origin WebSocket kaping, word geïdentifiseer as 'n spesifieke geval van Cross-Site Request Forgery (CSRF) wat WebSocket handdrukke beïnvloed. Hierdie kwesbaarheid ontstaan wanneer WebSocket handdrukke slegs via HTTP koekies outentiseer sonder CSRF tokens of soortgelyke sekuriteitsmaatreëls.
Aanvallers kan dit benut deur 'n kwaadaardige webblad te huisves wat 'n cross-site WebSocket verbinding na 'n kwesbare toepassing inisieer. Gevolglik word hierdie verbinding as deel van die slagoffer se sessie met die toepassing beskou, wat die gebrek aan CSRF beskerming in die sessie hanteringsmeganisme benut.
Let daarop dat wanneer 'n websocket verbinding gestig word, die koekie na die bediener gestuur word. Die bediener mag dit gebruik om elke spesifieke gebruiker met sy websocket sessie gebaseer op die gestuurde koekie te verbind.
Dan, as die websocket bediener die geskiedenis van die gesprek van 'n gebruiker terugstuur as 'n boodskap met "READY" gestuur word, dan sal 'n eenvoudige XSS wat die verbinding tot stand bring (die koekie sal automaties gestuur word om die slagoffer gebruiker te magtig) wat "READY" stuur, in staat wees om die geskiedenis van die gesprek te herwin.
In hierdie blogpos https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/ het die aanvaller daarin geslaag om arbitraire Javascript in 'n subdomein van die domein waar die web socket kommunikasie plaasgevind het, te voer. Omdat dit 'n subdomein was, is die cookie gestuur, en omdat die Websocket nie die Origin behoorlik nagegaan het nie, was dit moontlik om met dit te kommunikeer en tokens van dit te steel.
Kopieer die webtoepassing wat jy wil naboots (die .html-lêers byvoorbeeld) en voeg hierdie kode by die skrip waar die websocket kommunikasie plaasvind:
Nou laai die wsHook.js
-lêer af van https://github.com/skepticfx/wshook en stoor dit binne die gids met die weblêers.
Deur die webtoepassing bloot te stel en 'n gebruiker te laat aansluit, sal jy in staat wees om die gestuurde en ontvangde boodskappe via websocket te steel:
Wedreningsvoorwaardes in WebSockets is ook 'n ding, kyk hierdie inligting om meer te leer.
Aangesien Web Sockets 'n meganisme is om data na die bediener- en kliëntkant te stuur, afhangende van hoe die bediener en kliënt die inligting hanteer, kan Web Sockets gebruik word om verskeie ander kwesbaarhede soos XSS, SQLi of enige ander algemene web kwesbaarheid te benut deur die invoer van 'n gebruiker vanaf 'n websocket.
Hierdie kwesbaarheid kan jou toelaat om omgekeerde proxybeperkings te omseil deur hulle te laat glo dat 'n websocket kommunikasie gevestig is (selfs al is dit nie waar nie). Dit kan 'n aanvaller toelaat om verborgene eindpunte te benader. Vir meer inligting, kyk na die volgende bladsy:
Upgrade Header SmugglingLeer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)