Desidero utilizzare node.js (o altra soluzione SSJS), eseguendo il mio codice interno + codice scritto esterno all'interno (non attendibile).Protezione SSJS da codice non verificato
Un modo per separare e proteggere il mio codice? Potrei limitare i moduli e l'effetto di sistema del codice non attendibile (limitare l'accesso a file, porte non HTTP, ecc.)?
È possibile controllare questo progetto, sembra molto promettente:
http://github.com/gf3/node-sandbox
Personalmente, io non uso il nodo di fare esecuzione arbitraria SSJS. Probabilmente non piacerà questa soluzione, ma ha funzionato bene per me per circa un anno:
C'è un'implementazione Perl di API Spidermonkey (Spidermonkey è il motore JS di Firefox) that's available. L'ho collegato con l'aiuto di alcuni CGI. Puoi specificare esattamente quali funzioni vuoi esporre (garantito, è in Perl ... blech) ed eseguire qualunque codice tu voglia. Non vi è alcun rischio di vulnerabilità poiché l'intera configurazione è completamente in modalità sandbox. Non simula il DOM.
Il modo in cui l'ho implementato sul mio server (per prevenire l'abuso) era di rilasciare token che concedevano un accesso monouso tramite un'API REST su un server diverso. È una semplice implementazione HMAC che include un timestamp per rafforzare la legittimità del token. Quando lo script Perl riceve una richiesta, convalida il token ed elabora lo script (lo script dovrebbe essere solo parte di una richiesta POST). Lo script Perl quindi scrive solo i risultati. Il mio server è impostato per raggiungere un timeout di circa 10 secondi.
Spero che questo aiuti!
@Rook In realtà, ti sbagli. Non è nemmeno la crittografia, è l'autenticazione. È la stessa tecnica utilizzata da Amazon AWS. Più tecnicamente, non è una "bacchetta magica", è un mezzo legittimo per proteggere qualsiasi API REST frontale. Non importa ciò che viene usato come segreto HMAC. Salta su qualsiasi generatore di testo casuale e usa i primi 30 caratteri all'incirca, non importa. Anche se hai reso evidente che non capisci molto della sicurezza. – mattbasta
@mattbasta crypto è l'abbreviazione di crittografia e una funzione di hash crittografica come sha256 rientra in questa categoria. Chiaramente la sicurezza è un argomento molto approfondito e tutti hanno ancora molto da imparare. In breve, non mi piace molto questo approccio alla gestione di una vulnerabilità legata all'esecuzione di codice in modalità remota. C'è una buona citazione "Se eval() è la risposta, allora stai ponendo la domanda sbagliata". Non c'è assolutamente nessuna buona ragione per qualcuno per eseguire codice come questo. È probabile che l'OP stia prendendo una scorciatoia e sarà bruciato da questa risposta parziale. – rook
@Rook Per l'ultima volta, non è una vulnerabilità. Non c'è "eval", in quanto il codice è in esecuzione in un ambiente con letteralmente nulla da rompere. Non c'è letteralmente modo di modificare le informazioni sensibili, accedere al disco o effettuare richieste in uscita. Questa è l'idea alla base di una sandbox: chiaramente un argomento che il tuo professore di sicurezza deve aver sfogliato. Certo, l'esecuzione di codice in un'istruzione 'eval' non è buona, ma se l'OP vuole eseguire il JS di un utente, eseguirlo in un'impostazione sandbox è il modo più sicuro e più efficace per raggiungere tale obiettivo. Assegna un nome a una vulnerabilità esposta da una sandbox. – mattbasta
Dai un'occhiata allo Caja. Traduce il codice di terze parti in un modulo in cui il codice ha accesso solo agli oggetti che lo concedi in modo esplicito.
caja è bello, devi solo passare attraverso lo sforzo di convincerlo e capire cosa stai facendo (e hai bisogno di java, ecc.) –
Partenza questo dalla documentazione node.js
script.runInNewContext ([sandbox])
Simile a Script.runInNewContext (nota capitale 'S'), ma ora essere un metodo di un oggetto Script precompilato. script.runInNewContext esegue il codice dello script con sandbox come oggetto globale e restituisce il risultato. Il codice in esecuzione non ha accesso all'ambito locale. sandbox è facoltativo.
Fai attenzione, dai documenti attuali: nota che l'esecuzione di codice non affidabile è un affare difficile che richiede grande cura. Per evitare perdite accidentali di variabili globali, script.runInNewContext è piuttosto utile, ** ma l'esecuzione sicura del codice non affidabile richiede un processo separato **. –
Sì, ma in realtà dipende da come privilegiare l'attuale processo. Questo probabilmente implica che dovresti creare un nuovo processo con privilegi minori, il che richiede più privilegi per iniziare (ad esempio avviando il demone come root). Quindi, sì, il sandboxing di un'esecuzione globale per un nuovo processo è buono, ma se stai lavorando come utente non privilegiato per iniziare, probabilmente stai bene. Dipende anche da quanto è critica la missione. Se è il blog del tuo gatto, probabilmente stai bene qualunque cosa tu faccia. Se si tratta di un sito conforme allo standard PCI transazionale, sarebbe un po 'diff. Non proprio detto in questione ... –
Wow non si vede js lato server molto spesso. ; – rook