Impedire all'utente javascript fornito di postare sul server esterno

8

Sto scrivendo uno strumento interno che supporterà plug-in scritti da altri sviluppatori. Idealmente, questi plugin avrebbero un componente Javascript per consentire alle persone di creare widget. Alcune delle pagine su cui agiscono questi widget potrebbero contenere dati sensibili. Quello che voglio evitare è lo sviluppatore che scrive un plugin che ha javascript che pubblica questi dati su un server esterno. Tuttavia, è essenziale per il funzionamento di questi widget che possano manipolare i dati sulla pagina. Fondamentalmente questi widget dovrebbero essere in grado di effettuare la presentazione dei dati, ma non dovrebbero essere in grado di rubarli.

Ho visto adsafe, ma questo è troppo restrittivo perché questi widget possono solo manipolare la dom fornita dal widget adsafe, e quindi non possono accedere ai dati di cui hanno bisogno. Ho anche guardato Google Caja, che potrebbe essere una soluzione accettabile, anche se la sua compilazione incrociata renderebbe il codice più lento in un ambiente critico dal punto di vista delle prestazioni (non ho anche giocato con esso, quindi non so in modo specifico se posso usarlo per evitare di postare).

Penso che la soluzione "ideale" potrebbe essere una sorta di strumento di analisi statica in grado di eliminare "solo" programmi che tentano di contattare un server esterno, ma accolgo con favore eventuali suggerimenti che potrebbero funzionare.

    
posta user17619 20.12.2012 - 23:43
fonte

3 risposte

6

Il codice è intrinsecamente dinamico ed è e sarà sempre impossibile controllare il comportamento del codice fornito dall'utente. Consentendo agli utenti di eseguire JavaScript, si sta implementando una vulnerabilità Cross-Site Scripting (XSS). XSS è anche comunemente usato per esporre gli utenti agli attacchi Drive By Download che sono stranamente assenti dal tuo modello di minaccia.

Un modo per mitigare la minaccia posta da XSS è quello di isolare gli script forniti dall'utente in un sottodominio in modo che non possano accedere alle informazioni sensibili a causa del Politica Same-Origin . Questo non fa nulla per impedire a un utente malintenzionato di eseguire BeEF sugli utenti della tua applicazione Web o eseguire un altro tipo di drive tramite attacco di download.

    
risposta data 21.12.2012 - 02:49
fonte
2

Potresti utilizzare Content-Security-Policy . Questo può aggiungere alcune restrizioni di script. Tuttavia non è utilizzato da tutti i browser e potrebbe non essere abbastanza granulare per te.

    
risposta data 21.12.2012 - 05:52
fonte
1

Recentemente ho creato un js-library ( link ) che potrebbe essere adatto al tuo scopo. L'idea è la seguente:

  • il codice non affidabile viene eseguito in una sandbox limitata (sottoprocesso limitato in Node.js o un web worker all'interno di un iframe sandboxed per un browser Web);

  • la sandbox non ha accesso a nulla, ma è possibile "esporre" un set di funzioni esterne nella sandbox, definendo con precisione l'API e le autorizzazioni di ciò che è consentito per il codice non affidabile da eseguire;

  • allora il codice può chiamare direttamente quelle funzioni per manipolare o interagire con l'applicazione principale nel modo consentito (sotto il cofano, questo viene emulato acutamente usando il meccanismo di messaggistica).

Potrebbe anche essere un po 'scomodo, il che significa che se si desidera consentire l'opportunità di manipolare i nodi DOM, ad esempio, è necessario descrivere in modo esplicito l'intera API in termini di funzioni esportate.

    
risposta data 18.01.2015 - 16:33
fonte

Leggi altre domande sui tag