Consideraciones de seguridad para JScript
Escribir código seguro es un desafío en cualquier lenguaje. JScript incluye algunas áreas en las que los desarrolladores podrían usar el lenguaje de manera insegura inadvertidamente porque el lenguaje no les obliga a usar los procedimientos más eficaces. A pesar de que uno de los objetivos que se plantearon al diseñar JScript fue la seguridad, su principal finalidad es promover el desarrollo rápido de aplicaciones útiles. En algunos casos, estos dos objetivos se contraponen.
Puede evitar los temas de seguridad si conoce los posibles problemas que existen en las distintas áreas que se enumeran a continuación. Estas consideraciones en materia de seguridad, excepto el método eval, son consecuencia de la nueva funcionalidad que ofrece .NET Framework.
El método eval
La característica de JScript que peor se usa es el método eval, que permite la ejecución dinámica del código fuente de JScript. Dado que las aplicaciones de JScript que usan el método eval pueden ejecutar cualquier tipo de código que les pase un programa, todas las llamadas al método eval suponen un riesgo para la seguridad. A menos que la aplicación requiera flexibilidad para ejecutar cualquier tipo de código, considere escribir sólo el código que la aplicación pasa al método eval.
Atributos de seguridad
Se pueden usar los atributos de seguridad de .NET Framework para reemplazar explícitamente la configuración de seguridad predeterminada de JScript. No obstante, no se deben modificar los valores predeterminados de seguridad a menos que se sepa exactamente qué se está haciendo. Concretamente, algo que no se debe aplicar es el atributo APTCA (AllowPartiallyTrustedCallersAttribute) personalizado ya que, en general, los llamadores que no son de confianza no pueden llamar a código JScript de forma segura. Si crea un ensamblado de confianza con APTCA que, más tarde, cargue la aplicación, un llamador de confianza parcial podría obtener acceso a los ensamblados de plena confianza de dicha aplicación. Para obtener más información, vea Instrucciones de codificación segura.
Código de confianza parcial y código hospedado de JScript
El motor que hospeda JScript permite a cualquier código al que se llame modificar partes del motor, como variables globales, variables locales y cadenas de prototipo de cualquier objeto. Asimismo, todas las funciones pueden modificar las propiedades o los métodos expando de cualquier objeto expando que se les pase. Por consiguiente, si una aplicación de JScript llama a código de confianza parcial o si se ejecuta en una aplicación con otro tipo de código (como en un host de Visual Studio para Aplicaciones [VSA]), se podría modificar el comportamiento de la aplicación.
Como consecuencia, cualquier código JScript de una aplicación (o de una instancia de una clase AppDomain) debe ejecutarse en un nivel de confianza que no sea superior al resto del código de la aplicación. De lo contrario, el otro código podría manipular el motor para la clase de JScript, lo que, a su vez, podría modificar los datos y afectar al código restante de la aplicación. Para obtener más información, vea _AppDomain.
Acceso al ensamblado
JScript puede hacer referencia a los ensamblados mediante nombres seguros y nombres de texto simple. Una referencia a un nombre seguro incluye la información de versión del ensamblado, así como una firma criptográfica que confirma la integridad y la identidad de dicho ensamblado. Si bien resulta más fácil utilizar un nombre simple al hacer referencia a un ensamblado, un nombre seguro ayuda a proteger el código en caso de que otro ensamblado del sistema tenga el mismo nombre simple, pero distinta funcionalidad. Para obtener más información, vea Cómo: Hacer referencia a un ensamblado con nombre seguro.
Subprocesamiento
El runtime de JScript no es seguro para subprocesos. Por consiguiente, el código JScript multiproceso puede tener un comportamiento impredecible. Si desarrolla un ensamblado en JScript, tenga en cuenta que es posible que se use en un contexto multiproceso. Debe usar clases del espacio de nombres System.Threading, como la clase Mutex, para garantizar que el código JScript del ensamblado se ejecute con la sincronización adecuada.
Dado que resulta difícil escribir código de sincronización apropiado en cualquier lenguaje, no debe intentar escribir ensamblados de propósito general en JScript, a menos que sepa exactamente cómo implementar el código de sincronización necesario. Para obtener más información, vea System.Threading.
Nota
No es necesario escribir código de sincronización para las aplicaciones ASP.NET escritas en JScript, ya que ASP.NET administra la sincronización de todos los subprocesos que genera. No obstante, los controles web escritos en JScript deben contener código de sincronización porque se comportan como los ensamblados.
Errores en tiempo de ejecución
Dado que JScript es un lenguaje en el que no es necesario declarar los tipos de datos, tolera mejor las posibles divergencias entre los tipos que otros lenguajes, como Visual Basic y Visual C#. Debido a que la divergencia entre los tipos puede producir errores en tiempo de ejecución en las aplicaciones, es importante detectarlas al desarrollar el código. Se puede usar la marca /warnaserror con el compilador de la línea de comandos o el atributo warninglevel de la directiva @ Page en las páginas ASP.NET. Para obtener más información, vea /warnaserror y @ Page.
Modo de compatibilidad
Los ensamblados compilados en modo de compatibilidad (con la opción /fast-) son menos seguros que los compilados en modo rápido (el modo predeterminado). La opción /fast- habilita características del lenguaje que no están disponibles de manera predeterminada, pero que son necesarias para la compatibilidad con los scripts escritos para la versión 5.6 y versiones anteriores de JScript. Por ejemplo, las propiedades expando se pueden agregar dinámicamente a los objetos intrínsecos, como el objeto String, en modo de compatibilidad.
El modo de compatibilidad sirve para ayudar a los desarrolladores a crear ejecutables independientes a partir de código JScript heredado. Cuando desarrolle nuevos ejecutables o bibliotecas, utilice el modo predeterminado. Así, no sólo ayudará a proteger las aplicaciones, sino que también ayudará a garantizar un mayor rendimiento y una mejor interacción con otros ensamblados. Para obtener más información, vea /fast.
Vea también
Conceptos
Actualizar aplicaciones creadas en versiones anteriores de JScript