Considerações de segurança para o JScript
Escrever código seguro é um desafio em qualquer linguagem.JScript inclui algumas áreas onde os desenvolvedores podem inadvertidamente usar a linguagem de maneira não segura porque o idioma não força os desenvolvedores usem práticas mais efetivo. Embora JScript foi projetado com segurança sistema autônomo um meta, seu principal meta é elevar o desenvolvimento rápido de aplicativos úteis. Em alguns casos, essas duas metas estão em oposição.
Você pode evitar problemas de segurança se você estiver ciente dos problemas potenciais em várias áreas importantes que estão listados abaixo.Essas considerações de segurança, exceto o eval método, devido a nova funcionalidade que o .NET Framework apresenta.
O método eval
Mais com com facilidade usado incorretamente o recurso de JScript é o eval método, que permite a execução dinâmica do JScript código-fonte. Porque um JScript aplicativo que usa o eval método pode executar qualquer código que um programa passa para ele, cada telefonar para o eval método representa um risco à segurança. A menos que seu aplicativo requer a flexibilidade de executar qualquer código, considere explicitamente escrever o código que o aplicativo passa para o eval método.
Para aumentar a segurança de aplicativos que exigem a total flexibilidade oferecida pelo eval o código de método, passou para eval é executado em um contexto restrito por padrão. O contexto de segurança restrito ajuda a evitar todo o acesso aos recursos do sistema, sistema autônomo o sistema de arquivos, a rede ou a interface do usuário.Uma exceção de segurança é gerada se o código tenta acesso esses recursos.No entanto, o código executado pelo eval método ainda pode modificar as variáveis locais e global. Para obter mais informações, consulte Método Eval.
Códigos escritos em versões anteriores de JScript pode exigir o eval método para executar o código no mesmo contexto de segurança sistema autônomo o código de chamada. Para habilitar esse comportamento, você pode passar a seqüência de caracteres "não seguro" sistema autônomo o segundo parâmetro opcional para oeval método. Somente seqüências de código obtidas de fontes conhecidas sistema autônomo no modo "não seguro" da seqüência do código é executado com sistema autônomo mesmas permissões que o código de chamada deve ser executado.
Atributos de segurança
Os atributos de segurança do .NET Framework pode ser usado para substituir explicitamente as configurações de segurança padrão em JScript. No entanto, os padrões de segurança não devem ser modificados, a menos que você saiba exatamente o que você está fazendo.Em particular, algo que você deve aplicar não é o AllowPartiallyTrustedCallers atributo atributo personalizado (APTCA) porque chamadores não confiáveis não é possível chamar com segurança JScript código, em geral. Se você criar um assembly confiável com APTCA, em seguida, é carregada por um aplicativo, um chamador parcialmente confiável poderia acessar assemblies totalmente confiável no aplicativo.Para obter mais informações, consulte Diretrizes para Codificação Segura.
Código parcialmente confiável e código de JScript hospedados
O mecanismo que hospeda JScript permite que qualquer código chamado modificar partes do mecanismo, tais sistema autônomo variáveis global, variáveis locais e cadeias de protótipos de qualquer objeto. Além disso, qualquer função pode modificar as expando propriedades ou métodos de qualquer objeto expando passado para ele.Conseqüentemente, se um JScript aplicativo chama o código parcialmente confiável ou se ele estiver sendo executado em um aplicativo com Outros código (por exemplo, de um Visual Studio para aplicativos [VSA] host), o comportamento do aplicativo pode ser modificado.
Uma conseqüência disso é que qualquer JScript código em um aplicativo (ou em uma instância de um AppDomain classe) deve ser executado em um nível de confiança não maior que o restante do código no aplicativo.Caso contrário, Outros código pode manipular o mecanismo para o JScript classe, que por sua vez pode modificar os dados e afeta o Outros código no aplicativo. Para obter mais informações, consulte _AppDomain.
Acesso de assembly
JScript pode fazer referência a assemblies usando nomes de alta segurança e nomes de texto simples. Uma referência de nome forte inclui sistema autônomo informações de versão do assembly, além de uma assinatura criptográfica que confirma a integridade e a identidade do assembly.Embora seja mais fácil de usar um nome simples quando se referem a um assembly, ajuda um nome forte para proteger seu código caso outro assembly em seu sistema tem o mesmo nome simples, mas funcionalidade diferente.Para obter mais informações, consulte Como: Referência um assembly de nome forte.
Threading
The JScript tempo de execução não foi projetado para ser thread-safe. Conseqüentemente, multithread JScript código pode ter um comportamento imprevisível. Se você desenvolver um assembly em JScript, tenha em mente que pode ser usada em um contexto multithread. Você deve usar classes a partir de sistema.Threading namespace, sistema autônomo a Mutex classe, para garantir que o JScript o código no conjunto de módulos (assembly) é executado com a sincronização adequada.
Como é difícil de código de uma sincronização adequada gravar em qualquer linguagem, você não deve tentar gravar assemblies de uso Geral em JScript a menos que você tenha um mercadoria entendimento de como implementar o código de sincronização necessário. Para obter mais informações, consulte System.Threading.
.gif "Observação") Observação: |
|---|
Você não precisa escrever um código de sincronização para ASP.NET aplicativos escritos em JScript porque ASP.NET gerencia a sincronização de todos os threads que ele gera. No entanto, Web controles escritos em JScript deve conter código de sincronização porque eles se comportam como assemblies. |
Erros em tempo de execução
Porque JScript é uma linguagem sem rigidez de tipos, é mais tolerante a falhas de possíveis incompatibilidades de tipos de alguns idiomas, sistema autônomo Visual Basic e Visual C#. sistema autônomo incompatibilidades de tipos podem causar erros em time de execução em aplicativos, é importante descobrir incompatibilidades de tipos possíveis à medida que você desenvolver o código.Você pode usar o /warnaserror sinalizar com o compilador de linha de comando ou o WarningLevel atributo de do @ página diretiva em ASP.NET páginas. Para obter mais informações, consulte /warnaserror and @ página.
Modo de compatibilidade
Módulos (assemblies) compilados no modo de compatibilidade (com o /Fast-opção de ) são menos criptografados daqueles compilado no modo rápido (o modo padrão).The /Fast- opção permite que recursos de linguagem que não estão disponível por padrão, mas são necessários para compatibilidade com scripts escritos para JScript versão 5.6 e anterior. Por exemplo, expando propriedades podem ser adicionadas dinamicamente ao objetos intrínsecos, sistema autônomo a String objeto no modo de compatibilidade.
Modo de compatibilidade é fornecido para ajudar os desenvolvedores a construir executáveis autônomos de legado JScript código. Ao desenvolver novos arquivos executáveis ou bibliotecas, use o modo padrão.Não apenas isso ajuda a proteger os aplicativos, mas ele também ajuda a fornecer um melhor desempenho e melhor interação com outros assemblies.Para obter mais informações, consulte / rápido.
Consulte também
Conceitos
Atualizando aplicativos criados em versões anteriores do JScript