Considerazioni sulla protezione per JScript

Aggiornamento: novembre 2007

La compilazione di codice protetto è un'operazione alquanto difficile in qualsiasi linguaggio. In alcune sezioni di JScript gli operatori potrebbero inavvertitamente effettuare operazioni pericolose perché non ricevono alcun avviso. Benché JScript sia stato progettato per fornire protezione, l'obiettivo principale consiste nel favorire il rapido sviluppo di applicazioni utili. In alcuni casi questi due obiettivi sono in contrasto tra loro.

Di seguito sono descritti i potenziali problemi che possono verificarsi in alcune aree. Ad eccezione delle considerazioni fatte per il metodo eval, le informazioni qui di seguito sono legate alle nuove funzionalità introdotte da .NET Framework.

Metodo eval

La funzionalità di JScript che più facilmente può essere utilizzata in modo improprio è il metodo eval, che consente l'esecuzione dinamica di codice sorgente JScript. Qualsiasi codice passato da un programma a un'applicazione JScript che utilizza il metodo eval verrà eseguito, con la conseguenza che ogni chiamata al metodo eval pone un problema di protezione. A meno che l'applicazione non richieda la flessibilità di eseguire qualsiasi codice, si consiglia di scrivere in modo esplicito il codice che l'applicazione deve passare al metodo eval.

Per aumentare il livello di protezione delle applicazioni che necessitano della completa flessibilità fornita dal metodo eval, il codice passato a eval viene eseguito per impostazione predefinita in un contesto limitato. Il contesto di protezione limitato impedisce l'accesso a risorse di sistema, quali il file system, la rete o l'interfaccia utente. Se il codice tenta di accedere a tali risorse, viene generata un'eccezione di protezione. Il codice eseguito dal metodo eval può comunque modificare le variabili locali e globali. Per ulteriori informazioni, vedere Metodo eval.

Il codice scritto in versioni precedenti di JScript potrebbe richiedere al metodo eval di essere eseguito nello stesso contesto di protezione del codice chiamante. Perché ciò avvenga, è possibile passare la stringa "unsafe" come secondo parametro facoltativo al metodo eval. Si consiglia di eseguire solo stringhe di codice ottenute da risorse affidabili poiché in modalità "unsafe" la stringa di codice viene eseguita con le stesse autorizzazioni del codice chiamante.

Attributi di protezione

Gli attributi di protezione di .NET Framework possono essere utilizzati per eseguire l'override esplicito delle impostazioni di protezione predefinite in JScript. Le impostazioni di protezione predefinite dovrebbero essere modificate solo da utenti esperti. In particolare, si consiglia di non applicare l'attributo personalizzato AllowPartiallyTrustedCallers (APTCA) poiché è preferibile impedire a chiamanti non attendibili di chiamare il codice JScript. Se si crea un assembly attendibile con APTCA che viene poi caricato da un'applicazione, un chiamante parzialmente attendibile potrebbe accedere ad assembly completamente attendibili dell'applicazione. Per ulteriori informazioni vedere Indicazioni per la generazione di codice protetto.

Codice parzialmente attendibile e codice JScript contenuto

Il modulo di gestione in cui è contenuto JScript consente a qualsiasi codice chiamato di modificare parti del modulo, quali variabili globali o locali e catene di prototipi di qualsiasi oggetto. Qualsiasi funzione, inoltre, può modificare le proprietà o i metodi expando di qualsiasi oggetto expando che le viene passato. Di conseguenza, se un'applicazione JScript chiama del codice parzialmente attendibile oppure viene eseguita in un'applicazione insieme ad altro codice, ad esempio in un host Visual Studio for Applications (VSA), è possibile che il comportamento dell'applicazione venga modificato.

Per questo motivo, qualsiasi codice JScript in un'applicazione, o in un'istanza di una classe AppDomain, dovrebbe essere eseguito a un livello di attendibilità non superiore al resto del codice dell'applicazione. In caso contrario, l'altro codice potrebbe modificare il modulo di gestione della classe JScript, che a sua volta potrebbe modificare i dati e influire sull'altro codice dell'applicazione. Per ulteriori informazioni vedere _AppDomain.

Accesso agli assembly

JScript può fare riferimento ad assembly utilizzando sia nomi sicuri che nomi in testo semplice. Il riferimento con nome sicuro include le informazioni sulla versione dell'assembly e una firma crittografata che conferma l'integrità e l'identità dell'assembly. L'utilizzo di un nome semplice per fare riferimento a un assembly è un metodo più facile, tuttavia un nome sicuro protegge il codice nel caso un altro assembly nel sistema disponga dello stesso nome semplice ma di una diversa funzionalità. Per ulteriori informazioni vedere Procedura: aggiungere un riferimento a un assembly con nome sicuro.

Threading

Il runtime JScript non è progettato per essere thread-safe. L'utilizzo del multithreading con il codice JScript potrebbe pertanto comportare conseguenze impreviste. Se si sviluppa un assembly in JScript, occorre ricordare che questo potrebbe venire utilizzato in un contesto con multithreading. Si consiglia di utilizzare classi dello spazio dei nomi System.Threading, come la classe Mutex, per garantire che il codice JScript nell'assembly venga eseguito con la corretta sincronizzazione.

Poiché è difficile scrivere codice di sincronizzazione corretto in qualsiasi linguaggio, è bene evitare di tentare di scrivere assembly di utilizzo generale in JScript a meno che non si sappia con esattezza in che modo implementare il codice di sincronizzazione necessario. Per ulteriori informazioni vedere System.Threading.

Nota:
Non è necessario scrivere codice di sincronizzazione per applicazioni ASP.NET scritte in JScript poiché ASP.NET gestisce la sincronizzazione di tutti i thread generati. I controlli Web scritti in JScript devono tuttavia contenere codice di sincronizzazione dal momento che si comportano come assembly.

Errori di runtime

Poiché JScript è un linguaggio che non impone vincoli per l'utilizzo dei tipi di dati, rispetto ad altri linguaggi quali Visual Basic e Visual C#, risulta più tollerante verso possibili errate corrispondenze tra tipi di dati. Dal momento che tipi di dati non corrispondenti possono causare errori nelle applicazioni in fase di esecuzione, è importante che vengano rilevati mentre si sviluppa il codice. È possibile utilizzare il flag /warnaserror con il compilatore basato su riga di comando o l'attributo warninglevel della direttiva @ Page nelle pagine ASP.NET. Per ulteriori informazioni, vedere /warnaserror e @ Page.

Modalità di compatibilità

Gli assembly compilati in modalità di compatibilità (con l'opzione /fast-) sono meno sicuri rispetto a quelli compilati in modalità veloce (predefinita). L'opzione /fast- abilita funzionalità del linguaggio che per impostazione predefinita non sono disponibili ma che sono necessarie per la compatibilità con gli script scritti per la versione 5.6 di JScript e le versioni precedenti. Le proprietà expando, ad esempio, possono essere aggiunte dinamicamente a oggetti intrinseci, come l'oggetto String, in modalità di compatibilità.

La modalità di compatibilità aiuta gli sviluppatori nella generazione di file eseguibili autonomi da codice JScript preesistente. Quando si sviluppano nuovi file eseguibili o librerie, utilizzare la modalità predefinita. In questo modo non solo si facilita la protezione delle applicazioni ma si garantiscono anche migliori prestazioni e maggiore interazione con altri assembly. Per ulteriori informazioni, vedere /fast.

Vedere anche

Concetti

Aggiornamento di applicazioni create in versioni precedenti di JScript

Altre risorse

Sicurezza nel codice nativo e nel codice .NET Framework