Perché nessun supporto per i socket TCP in JavaScript

7

So che ora ci sono WebSockets, ma qual è il problema con la fornitura di un'API socket per consentire l'interazione con i protocolli esistenti?

Voglio dire, dopo tutto, posso usare un oggetto flash nascosto per fare lo stesso già. C'è un vettore di attacco che mi manca?

    
posta Simon Farshid 22.09.2015 - 03:06
fonte

3 risposte

15

... but what is the issue with providing a socket API to allow interacting with existing protocols?

Questa non è una restrizione del linguaggio in sé ma del suo uso all'interno della sandbox all'interno del browser. Immagina che uno script da qualche parte su Internet venga caricato nel browser e che dall'interno del browser possa accedere a tutti i computer raggiungibili dal browser con protocolli arbitrari. Si può facilmente abusare di questo per inviare spam attraverso un server di posta interno di un'azienda o attaccare / utilizzare impropriamente altre risorse interne ed esterne.

Il che significa che devono esserci alcune restrizioni e che i diversi ambienti sandbox per i diversi runtime linguistici forniscono diversi tipi di restrizioni:

  • Con il flash, l'host di destinazione deve consentire esplicitamente l'accesso fornendo un file di criteri socket appropriato. Questo è simile al meccanismo all'interno di HTML5 CORS .
  • Le applet Java non attendibili sono limitate alle comunicazioni con l'host che fornisce l'applet.
  • E con JavaScript nel browser puoi parlare con quasi tutti i siti, ma sei limitato dal protocollo che puoi usare, cioè HTTP (limitato da CORS) e WebSockets.
risposta data 22.09.2015 - 07:06
fonte
3

Non sono sicuro di quale sia l'API socket che accede a un oggetto Flash, ma ci sono ottimi motivi per non consentire il semplice TCP o UDP (molto meno qualsiasi altro tipo di) socket in JavaScript.

Il più grande, probabilmente, è che stai fondamentalmente fornendo un modo per bypassare i firewall se lo fai. Ogni servizio sulla tua macchina in ascolto su socket di rete loopback, normalmente irraggiungibile da parte di aggressori esterni, può ora essere attaccato dal browser. A ogni computer della tua rete, normalmente isolato da Internet dal tuo gateway e dal tuo firewall, ora puoi accedere o essere attaccato dal codice Internet.

Ci sono anche altre ragioni. La scansione delle porte e gli attacchi DDOS diventano molto più semplici quando i browser possono eseguirli senza un plug-in ( sì, i browser possono tentare di avviare DDOS su server HTTP (S), ma potrebbero essere molto più efficienti con i socket di livello inferiore ). I worm di rete (in particolare quelli a cui è vulnerabile solo una piccola percentuale di macchine) possono propagarsi molto più velocemente quando tutti coloro che visualizzano un annuncio su un sito web popolare inizia a inviare attacchi, anziché solo quelli che vengono effettivamente infettati.

I Websocket esistono per dare un modo di fare comunicazione socket con elementi che desiderano esplicitamente comunicare con un browser che esegue codice non affidabile. Il tipico server Internet è altrettanto resistente, aspettandosi client maligni di tutte le strisce. Il problema deriva da servizi che non si aspettano traffico dannoso, perché sono raggiungibili solo dai client fidati. Le prese controllate da JS lo spezzerebbero completamente.

    
risposta data 22.09.2015 - 06:43
fonte
0

I browser equivalenti a un tipico socket TCP è l'API WebSockets specifica .

Se vuoi che i socket in JavaScript dia un'occhiata alla socket API in node.js

    
risposta data 22.09.2015 - 03:13
fonte

Leggi altre domande sui tag