Socket.IO Client Security

Question

Socket.IO Client Security

#1 da (2 voti)
#2 da (2 voti)
#3 da (0 voti)

4

Sono nuovo su Node.js e Socket.IO. Secondo la documentazione il codice lato client è qualcosa del tipo:

<script src="/socket.io/socket.io.js"></script>
<script>
  var socket = io('http://localhost:3000');
  socket.on('news', function (data) {
    console.log(data);
    socket.emit('my other event', { my: 'data' });
  });
</script>

È semplice e facile, ma anche se è perfetto per i test locali, non sono sicuro che sia sicuro su una pagina live poiché espone le informazioni sull'evento del server.

Come posso nascondere le informazioni sensibili su una pagina come questa?

node.js websocket

posta Cemre 18.10.2014 - 20:44

fonte

3 risposte

Leggi altre domande sui tag node.js websocket

Memorizza la password di un utente in modo recuperabile in modo sicuro cambiando la distribuzione, c'è una strategia per ottenere un'immagine senza distro?

score 2 · Answer 1

Socket.io crea un WebSocket , e WebSockets seguono le normali regole dei criteri Same-Origin. Tuttavia, è possibile creare un WebSocket in una risorsa di origine incrociata utilizzando l'intestazione HTTP Access-control-allow-origin , che è comunemente nota come CORS. Se per qualche motivo CORS è stato utilizzato per creare un WebSocket di origine incrociata, è possibile che questo WebSocket possa essere dirottato da un dominio non attendibile .

Inoltre, un WebSocket è come qualsiasi altra API in quanto espone la logica dell'applicazione agli aggressori. Assicurati di affrontare le comuni vulnerabilità delle applicazioni Web come quelle che si trovano nella OWASP Top 10 . Di particolare interesse è Riferimento ad oggetti diretti non sicuri , Injection Attacks e Broken Autenticazione e gestione delle sessioni .

score 2 · Answer 2

Esistono due soluzioni generiche a questo problema. Entrambe le soluzioni si basano sull'approccio a non pubblicare informazioni nel pubblico che non dovrebbero essere pubbliche. Ciò implica che devi implementare una sorta di meccanismo di autenticazione nella tua applicazione, ad es. un modulo di accesso che crea una nuova sessione (e nuove chiavi di sessione temporali). Inutile dire che dovresti usare https / wss invece di http / ws .

Il primo metodo è pubblicare solo eventi pubblici e recuperare i dati degli eventi privati su un canale separato (ad esempio una nuova richiesta HTTP). Questo è ciò che lo Stack Exchange fa con le notifiche di casella di posta in arrivo: i socket vengono utilizzati solo per informare gli iscritti dei nuovi messaggi di posta in arrivo, mentre il contenuto effettivo viene recuperato solo su http quando l'utente fa clic sul fumetto di notifica.

Il secondo metodo consiste nell'autenticare la connessione Socket.IO prima di archiviare il socket sul lato server. In Socket.IO, puoi passare informazioni extra con l'handshake tramite l'opzione query . Sul server, leggi questo valore e consenti agli utenti di creare il socket solo dopo aver eseguito correttamente l'autenticazione ( esempio ^{la risposta accettata è per socket.io 0.9, guarda qui per socket.io 1.x}). Questa chiave dovrebbe essere trattata come un cookie di sessione. Quando l'utente si disconnette, il socket associato a questa chiave dovrebbe essere distrutto e il token invalidato. Idealmente, questa chiave dovrebbe essere usata una sola volta (cioè invalidata dopo il primo utilizzo), ma in pratica non funziona se la connessione non è affidabile e devi continuare a riconnetterti a Socket.IO.

In alternativa al rifiuto del socket (metodo 2), è possibile anche accettare il socket e utilizzare i dettagli di autenticazione per controllare se un utente è autorizzato a iscriversi a un evento oa entrare in una stanza. Il client riceverà un evento solo se lo invii al server, quindi se non invii l'evento (ad es. Perché l'utente non si trova nella stanza in cui è trasmesso l'evento), non ci sono perdite di informazioni.

score 0 · Answer 3

Come per tutte le domande di sicurezza, devi descrivere quali sono i tuoi obiettivi di sicurezza. Sicuro da chi? Sicuro da che tipo di accesso? Quanto deve essere sicuro dall'accesso indesiderato? Quali livelli di autenticazione e crittografia sei disposto ad aggiungere per impedire ai telespettatori indesiderati le informazioni?

Lo schema che hai impostato sopra ti permette di:

Qualsiasi agente può connettersi al tuo server con una websocket e iscriversi agli eventi "news". Pertanto, qualsiasi informazione viene trasmessa utilizzando il messaggio news è disponibile a chiunque.
In realtà, qualsiasi agente può connettersi al server con un websocket e leggere tutti i messaggi che trasmette a tutti i socket connessi. Questo non è solo limitato all'evento news . Se il tuo server invia i dati a qualsiasi websocket connesso in modo casuale, qualsiasi agente casuale può connettersi tramite websocket e leggere tali informazioni.
Per quanto riguarda i dati inviati in altro modo (dal tuo client al server), tali informazioni sono disponibili solo per qualcuno che spii sulla connessione (presso il tuo ISP, nel trasporto via Internet al data center in cui il server è all'interno del data center prima che raggiunga il tuo server o chiunque abbia accesso fisico al tuo server. Questi dati non sono prontamente disponibili per gli agenti esterni senza accesso al trasporto su cui i pacchetti stanno scorrendo.

La breve risposta a come rendere i dati più sicuri è praticamente la stessa della maggior parte delle domande di sicurezza.

Proteggi l'accesso, richiedendo una sorta di accesso sicuro prima che l'accesso venga concesso.
Proteggi il trasporto con crittografia (come SSL supportato da certificati appropriati).
Invia solo informazioni che richiedono sicurezza sui canali che hanno già messo in atto la sicurezza appropriata.

Su Internet, non esiste un accesso basato su API o websocket basato su server a cui è possibile accedere SOLO dalle proprie pagine Web. L'accesso dalle tue pagine web è solo l'accesso da alcuni endpoint casuali su Internet e generalmente non vi è alcuna differenza di accesso tra una pagina del browser, un hacker con i propri strumenti di connettività o qualche server canaglia in Internet che tenta di accedere al tuo sito . In genere non puoi dire la differenza. Ci sono alcuni trucchi per far sì che terze parti possano avere più problemi (come includere credenziali sempre mutevoli in ogni pagina web che deve essere utilizzata), ma senza i precedenti tre titolari di sicurezza, non è davvero sicuro.