Consideraciones de seguridad para JScript
Actualización: noviembre 2007
Escribir código seguro es un desafío en cualquier lenguaje. JScript incluye unas áreas en las que los desarrolladores podrían utilizar inadvertidamente el lenguaje de manera insegura porque el lenguaje no les obliga a que utilicen las prácticas 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 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 utiliza es el método eval, que permite la ejecución dinámica del código fuente de JScript. Puesto que las aplicaciones de JScript que utilizan el método eval puede ejecutar cualquier tipo de código que les pase el programa, las llamadas al método eval suponen un riesgo de 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.
Para aumentar la seguridad de las aplicaciones que requieren toda la flexibilidad proporcionada por el método eval, el código pasado a eval se ejecuta dentro de un contexto restringido de manera predeterminada. El contexto de seguridad restringido ayuda a prohibir el acceso a los recursos del sistema, como el sistema de archivos, la red o la interfaz de usuario. Si el código intenta obtener acceso a estos recursos, se genera una excepción de seguridad. Sin embargo, el código que ejecuta el método eval aún modificar variables locales y globales. Para obtener más información, vea eval (Método).
Es posible que el código escrito en versiones anteriores de JScript requiera que el método eval ejecute código en el mismo contexto de seguridad que el código de llamada. Para habilitar este comportamiento, puede pasar al método eval la cadena "unsafe" como segundo parámetro opcional. Sólo debe ejecutar cadenas de código procedentes de orígenes de confianza, ya que en el modo "unsafe", la cadena de código se ejecuta con los mismos permisos que el código de llamada.
Atributos de seguridad
Los atributos de seguridad de .NET Framework pueden utilizarse para reemplazar explícitamente los valores de seguridad predeterminados 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 personalizado del atributo AllowPartiallyTrustedCallers (APTCA) ya que, en general, los llamadores que no son de confianza no pueden llamar a código de 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 alojado de JScript
El motor que aloja JScript permite a cualquier código al que se llame modificar partes del motor, como las variables globales, las variables locales y las 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 tanto, 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 de 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 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.
Subprocesos
El motor en tiempo de ejecución de JScript no es seguro para subprocesos. Por tanto, el código multiproceso de JScript puede tener un comportamiento impredecible. Si desarrolla un ensamblado en JScript, tenga en cuenta que es posible que se utilice en un contexto multiproceso. Debe utilizar clases del espacio de nombres System.Threading, como la clase Mutex, para garantizar que el código de JScript del ensamblado se ejecute con la sincronización adecuada.
Puesto que resulta difícil escribir código de sincronización apropiada 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.
.gif "Nota") 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
Puesto 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 descubrirlas al desarrollar el código. Puede utilizar el indicador /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 funciones del lenguaje que no están disponibles de manera predeterminada, pero que son necesarias para la compatibilidad con las cadenas escritas para la versión 5.6 y anteriores de JScript. Por ejemplo, las propiedades expando se pueden agregar dinámicamente a los objetos intrínsecos, como el objeto String, en el modo de compatibilidad.
El modo de compatibilidad sirve para ayudar a los desarrolladores a crear ejecutables independientes a partir de código heredado de JScript. 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