Se un'applicazione dannosa è stata trovata su un computer che esegue solo un server WebSocket con localhost, sarebbe di aiuto se le comunicazioni usassero SSL?
In caso affermativo, come potrebbe fallire SSL se un'app dannosa
SSL di solito non aiuta.
Se l'attaccante ha il controllo completo sul computer, allora vince. Può ispezionare e modificare la memoria di tutti i processi nel computer.
Se l'attaccante è solo un utente non amministrativo, quindi non sarà in grado di spiare il processo da altri utenti. Tuttavia, se l'utente malintenzionato può eseguire codice come lo stesso utente del server o del client della tua connessione con localhost-only (o entrambi), allora può saccheggiare la RAM del processo coinvolto e vince. Inoltre, supponendo che un utente malintenzionato non amministrativo possa confidare nel fatto che il suddetto intruso possa entrare nella macchina ma non ha trovato alcun foro sfruttabile per l'escalation dei privilegi: si tratta di una ipotesi piuttosto ottimistica.
Se l'utente malintenzionato può solo ascoltare le comunicazioni, ma non dare un'occhiata alla memoria del processo, allora SSL può essere d'aiuto, poiché impedisce lo spionaggio. Tuttavia, questo non è uno scenario molto realistico: spiare le connessioni localhost richiede i privilegi di amministratore locale.
Dove SSL può aiutare riguarda l'autenticazione : un utente malintenzionato locale, con diritti non di amministratore, può provare a connettersi al server e impersonare il client, o viceversa. SSL fornisce l'autenticazione: il client convalida il certificato del server e, se il server richiede un certificato client, il server convalida il certificato del client. Si noti, tuttavia, che su localhost esistono modi più efficienti per un server di sapere chi si trova all'altro estremo del socket (ad esempio getpeereid() ).
Leggi altre domande sui tag permissions tls windows-permissions defense websocket