Kuidas oma WebSocket-ühendusi kaitsta

Veeb kasvab tohutult. Üha rohkem veebirakendusi on dünaamilised, ümbritsevad ja ei nõua lõppkasutajalt värskendamist. Väikese hilinemisega sidetehnoloogiatele, nagu veebipesad, on tekkimas tugi. Veebipesad võimaldavad meil reaalajas suhelda serveriga ühendatud erinevate klientide vahel.

Paljud inimesed ei tea, kuidas oma veebipesasid mõne väga levinud rünnaku eest kaitsta. Vaatame, mis need on ja mida peaksite oma veebipesade kaitsmiseks tegema.

# 0: lubage CORS

WebSocket ei ole sisseehitatud CORS-iga. Nagu öeldud, tähendab see seda, et iga veebisait saab luua ühenduse mis tahes muu veebisaidi pistikühendusega ja suhelda ilma igasuguste piiranguteta! Ma ei hakka põhjendama, miks see nii on, kuid selle kiire lahendamine on Originpäise kinnitamine veebipesa käepigistuses.

Muidugi saab ründaja võltsida päise Origini, kuid see pole oluline, sest selle kasutamiseks peab ründaja võltsima ohvri brauseris päise Origin ja tänapäevased brauserid ei luba veebibrauserites istuval tavalisel javascriptil muuta päise päist .

Veelgi enam, kui autentite kasutajaid, eelistatavalt küpsiseid kasutades, pole see teie jaoks tegelikult probleem (lisateavet selle kohta punktis 4)

# 1: Rakendage määra piiramine

Kiiruse piiramine on oluline. Ilma selleta saavad kliendid teadlikult või teadmatult teie serveris DoS-rünnaku sooritada. DoS tähistab teenuse keelamist. DoS tähendab, et üks klient hoiab serverit nii hõivatud, et server ei suuda teiste klientidega hakkama saada.

Enamasti on tegemist ründaja tahtliku serveriga allalöömise katsega. Mõnikord võivad kehvad rakenduse juurutamised viia ka tavaliste klientide DoS-i.

Kiiruse piiramise rakendamiseks meie veebipesades kasutame lekkivat ämberalgoritmi (mis on ilmselt võrkude jaoks väga levinud algoritm)

Idee on selles, et teil on kopp, mille põrandal on kindla suurusega auk. Hakkate sinna vett panema ja vesi läheb alt läbi augu välja. Kui nüüd on vee ämbrisse panemise kiirus suurem kui pikema aja jooksul august välja voolamise kiirus, saab mingil hetkel kopp täis ja hakkab lekkima. See on kõik.

Mõistame nüüd, kuidas see on seotud meie veebipesaga:

  1. Vesi on kasutaja saadetud veebipesa liiklus.
  2. Vesi läbib auku. See tähendab, et server töötles seda veebipesa taotlust edukalt.
  3. Vesi, mis on endiselt ämbris ja pole üle voolanud, ootab põhimõtteliselt liiklust. Server töötleb seda liiklust hiljem. See võib olla ka plahvatuslik liiklusvoog (st liiga palju liiklust väga väikeseks ajaks on okei, kuni kopp ei leki)
  4. Ülevoolav vesi on serveri poolt ära visatud liiklus (liiga palju liiklust tuleb ühelt kasutajalt)

Siin on asi selles, et peate kontrollima oma veebipesa tegevust ja määrama need numbrid. Määrate igale kasutajale ämbri. Otsustame, kui suur peaks olema ämber (liiklus, mida üks kasutaja saaks kindla ajavahemiku jooksul saata), sõltuvalt sellest, kui suur on teie auk (kui palju aega vajab teie server keskmiselt ühe veebipesa päringu töötlemiseks, öelge näiteks saadetud sõnumi salvestamine) kasutaja andmebaasi).

See on kärbitud rakendus, mida kasutan veebisaidil codedamn lekkiva ämberalgoritmi juurutamiseks. See on NodeJS-is, kuid kontseptsioon jääb samaks.

if(this.limitCounter >= Socket.limit) { if(this.burstCounter >= Socket.burst) { return 'Bucket is leaking' } ++this.burstCounter return setTimeout(() => { this.verify(callingMethod, ...args) setTimeout(_ => --this.burstCounter, Socket.burstTime) }, Socket.burstDelay) } ++this.limitCounter

Mis siin toimub? Põhimõtteliselt langeb veebipesa ühendus, kui ületatakse nii piir kui ka purskepiir (mis on seatud konstandid). Vastasel juhul lähtestame pärast erilist viivitust sarivõte. See jätab taas ruumi uue plahvatuse jaoks.

# 2: Piirake kasuliku koorma suurust

See peaks olema rakendatud funktsioonina teie serveripoolses veebipesa teegis. Kui ei, siis on aeg see paremaks muuta! Peaksite piirama sõnumi maksimaalset pikkust, mida saaksite oma veebipesa kaudu saata. Teoreetiliselt pole piiri. Muidugi, tohutu kasuliku koormuse saamine riputab suure tõenäosusega selle konkreetse pistikupesa eksemplari ära ja sööb rohkem süsteemiressursse kui vaja.

Näiteks kui kasutate WS-i teeki Node'i jaoks veebiserverite loomiseks serveris, saate maxPayload-valiku abil määrata baitides maksimaalse kasuliku koormuse suuruse. Kui kasuliku koormuse suurus on sellest suurem, katkestab raamatukogu ühenduse loomulikult.

Ärge proovige seda iseseisvalt rakendada, määrates sõnumi pikkuse. Me ei taha kõigepealt kogu RAM-i süsteemi RAM-i lugeda. Kui see on isegi 1 baiti suurem kui meie seatud piir, siis visake see ära. Seda saaks rakendada ainult raamatukogu (mis käsitleb sõnumeid pigem baitide vooguna kui fikseeritud stringidena).

# 3: Looge kindel sideprotokoll

Kuna teil on nüüd dupleksühendus, võite serverile midagi saata. Server võib kliendile mis tahes teksti tagasi saata. Teil peaks olema võimalus mõlema tõhusaks suhtlemiseks.

Te ei saa toorsõnumeid saata, kui soovite oma veebisaidi sõnumside aspekti laiendada. Eelistan JSON-i kasutamist, kuid suhtluse loomiseks on ka teisi optimeeritud viise. JSONi arvestades võiks üldise saidi põhisõnumiskeem välja näha järgmine:

Client to Server (or vice versa):  status: "ok"

Nüüd on teil serveris lihtsam kontrollida kehtivaid sündmusi ja vormingut. Katkestage ühendus kohe ja registreerige kasutaja IP-aadress, kui sõnumi vorming erineb. Vorming ei muutu kuidagi, kui keegi ei sega käsitsi teie veebipesa ühendust. Kui olete sõlmes, soovitan kasutaja sissetulevate andmete edasiseks kinnitamiseks kasutada Joi teeki.

# 4: Kasutajate autentimine enne WS-ühenduse loomist

Kui kasutate veebipesasid autentitud kasutajate jaoks, on üsna hea mõte lubada autentitud kasutajatel luua edukas veebipesa ühendus. Ärge lubage kellelgi ühendust luua ja oodake, kuni nad veebipesa enda kaudu autentivad. Esiteks on veebipesa ühenduse loomine nagunii natuke kulukas. Nii et te ei soovi, et volitamata inimesed hüppaksid teie veebipesadesse ja hoiaksid ühendusi, mida teised inimesed saaksid kasutada.

Selleks edastage esipaneelil ühenduse loomisel mõned autentimisandmed veebipessa. See võib olla päis nagu X-Auth-Token:. Vaikimisi edastatakse küpsised ikkagi.

Jällegi, see pärineb tegelikult raamatukogust, mida kasutate veebiserverite juurutamiseks serveris. Kuid kui kasutate sõlme ja kasutate WS-i, on see funktsioon functionClient, mis annab teile juurdepääsu veebipesa ühendusele edastatud infoobjektile. (Täpselt nagu teil on juurdepääs HTTP-päringute objektile.)

# 5: SSL-i kasutamine veebipesades

See pole mõttetu, kuid tuleb siiski öelda. Kasutage ws: // asemel ws: //. See lisab teie suhtlusele turvakihi. Veebipesade pöördproksimiseks kasutage sellist serverit nagu Nginx ja lubage SSL nende kaudu. Nginxi seadistamine oleks täiesti teine ​​õpetus. Jätan direktiivi, mida peate Nginxi jaoks kasutama, neile inimestele, kes seda tunnevad. Lisateave siin.

location /your-websocket-location/ { proxy_pass ​//127.0.0.1:1337; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; }

Siin eeldatakse, et teie veebiserver kuulab porti 1337 ja teie kasutajad loovad teie veebipesaga ühenduse sellisel viisil:

const ws = new WebSocket('wss://yoursite.com/your-websocket-location')

Küsimused?

Kas teil on küsimusi või ettepanekuid? Küsige ära!