Considerazioni sulla sicurezza per JScript
La scrittura di codice sicuro è un'operazione impegnativa in qualsiasi linguaggio. In alcune aree di JScript gli sviluppatori potrebbero utilizzare inavvertitamente il linguaggio in modo non sicuro, non essendo presente alcuna limitazione. Benché la sicurezza abbia costituito un obiettivo nel progettare JScript, l'obiettivo principale di tale linguaggio consiste nel consentire lo sviluppo rapido 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 relative al metodo eval, le informazioni sulla sicurezza incluse in questo argomento sono dovute a nuove funzionalità introdotte in .NET Framework.
Metodo eval
La funzionalità più soggetta a errori di JScript è il metodo eval, che consente l'esecuzione dinamica del codice sorgente di JScript. Poiché un'applicazione JScript che utilizza il metodo eval può eseguire tutto il codice passato da un programma, ogni chiamata al metodo eval rappresenta un rischio per la sicurezza. 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.
Attributi di sicurezza
È possibile utilizzare gli attributi di sicurezza di .NET Framework per eseguire l'override esplicito delle impostazioni di sicurezza predefinite in JScript. Le impostazioni di sicurezza predefinite dovrebbero essere modificate solo da utenti esperti. In particolare, è consigliabile non applicare l'attributo personalizzato AllowPartiallyTrustedCallers (APTCA), in quanto è generalmente 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 Linee guida per la generazione di codice sicuro.
Codice parzialmente attendibile e codice JScript contenuto
Il motore che ospita JScript consente a qualsiasi codice chiamato di modificare parti del motore stesso, ad esempio variabili globali, variabili 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 codice parzialmente attendibile o viene eseguita in un'applicazione con altro codice, ad esempio da un host di Visual Studio for Applications, è possibile che il comportamento dell'applicazione venga modificato.
Per questo motivo, qualsiasi codice JScript incluso in un'applicazione o in un'istanza di una classe AppDomain deve essere eseguito a un livello di attendibilità non superiore al resto del codice nell'applicazione. In caso contrario, l'altro codice potrebbe modificare il motore per la classe JScript, provocando la modifica dei dati e influendo sull'altro codice nell'applicazione. Per ulteriori informazioni, vedere _AppDomain.
Accesso agli assembly
JScript può fare riferimento ad assembly utilizzando sia nomi sicuri sia 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. Di conseguenza, il codice JScript multithreading potrebbe avere un comportamento imprevisto. Se si sviluppa un assembly in JScript, è necessario tenere presente che l'assembly potrebbe essere utilizzato in un contesto con multithreading. È consigliabile utilizzare classi dello spazio dei nomi System.Threading, ad esempio 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, è consigliabile evitare di tentare di scrivere assembly di utilizzo generale in JScript, a meno che non si sia in grado di 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, in quanto ASP.NET gestisce la sincronizzazione di tutti i thread generati. I controlli Web scritti in JScript, tuttavia, devono contenere codice di sincronizzazione, in quanto si comportano come assembly.
Errori di runtime
Poiché JScript è un linguaggio che non impone vincoli per l'utilizzo dei tipi di dati, risulta più tollerante verso possibili corrispondenze errate tra tipi di dati rispetto ad altri linguaggi quali Visual Basic e Visual C#. 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 della 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 non disponibili per impostazione predefinita, ma necessarie per la compatibilità con JScript versione 5.6 e 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à semplifica la compilazione di file eseguibili autonomi da codice JScript legacy per gli sviluppatori. 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