Aunque las aplicaciones de AIR se crean usando tecnologías web, es importante que los desarrolladores observen que no están trabajando dentro del entorno limitado de seguridad del navegador. Esto significa que es posible crear aplicaciones de AIR que pueden causar daño al sistema local, ya sea accidental o malintencionadamente. AIR intenta minimizar este riesgo, pero aún hay maneras donde se pueden introducir vulnerabilidades. Este tema abarca importantes situaciones potenciales no seguras.
Riesgos de importar archivos en un entorno limitado de seguridad de la aplicación
Los archivos que existen en el directorio de la aplicación se asignan al entorno limitado de la aplicación y tienen privilegios completos del motor de ejecución. Se recomienda que las aplicaciones que escriben en el sistema de archivos local escriban en
app-storage:/
. Este directorio existe de forma separada de los archivos de la aplicación en el equipo del usuario, por ende los archivos no están asignados al entorno limitado de la aplicación y presentan un riesgo reducido de seguridad. Se recomienda que los desarrolladores consideren los siguientes puntos:
-
Incluir un archivo en un archivo de AIR (en la aplicación instalada) solo si es necesario.
-
Incluir un archivo de script en un archivo de AIR (en la aplicación instalada) solo si el comportamiento se comprende cabalmente y es de confianza.
-
No escribir ni modificar el contenido en el directorio de la aplicación. El motor de ejecución impide que las aplicaciones escriban o modifiquen los archivos y directorios usando el esquema de URL
app:/
emitiendo una a excepción SecurityError.
-
No utilizar datos de un origen de red como parámetros para los métodos de la API de AIR que pueden llevar a la ejecución de código. Esto incluye el uso del método
Loader.loadBytes()
y la función
eval()
JavaScript.
Riesgos de usar un origen externo para determinar rutas
Una aplicación de AIR puede correr riesgos cuando se usan datos o contenido externo. Por esta razón, tenga cuidado cuando utiliza datos de la red o del sistema de archivos. La responsabilidad de confianza depende del desarrollador y las conexiones de red que realizan, pero la carga de datos externos es intrínsicamente peligrosa y no se debería usar para operaciones confidenciales. No se recomienda que los desarrolladores:
Riesgos de usar, almacenar o transmitir credenciales no seguras
El almacenamiento de credenciales de usuario en el sistema de archivos local del usuario intrínsicamente introduce el riesgo de que estas credenciales sean vulnerables. Se recomienda que los desarrolladores consideren los siguientes puntos:
-
Si se deben almacenar las credenciales de forma local, se deben cifrar las credenciales cuando se escribe en el sistema de archivos local. El motor de ejecución proporciona un almacenamiento cifrado exclusivo para cada aplicación instalada, a través de la clase EncryptedLocalStore. Para obtener información, consulte
Almacenamiento local cifrado
.
-
No transmita credenciales de usuario no cifradas a un origen de red a no ser que dicho origen sea de confianza y que la transmisión utilice el protocolo HTTPS: o TLS.
-
Nunca se debe especificar una contraseña predeterminada en la creación de una credencial, los usuarios deben crear las propias. Los usuarios que dejan una contraseña predeterminada exponen sus credenciales a un atacante que ya conoce la contraseña predeterminada.
Riesgos de un ataque de desactualización
Durante la instalación de la aplicación, el motor de ejecución verifica que la versión de la aplicación no está actualmente instalada. Si una aplicación ya está instalada, el motor de ejecución compara la cadena de la versión con la versión que se está instalando. Si esta cadena es diferente, el usuario puede elegir actualizar la instalación. El motor de ejecución no garantiza que la versión recién instalada sea más nueva que la versión más antigua, solo que es diferente. Un atacante puede distribuir una versión anterior al usuario para evitar una debilidad de seguridad. Por esta razón, se recomienda que el desarrollador verifique las versiones cuando se ejecuta la aplicación. Es una buena idea que las aplicaciones verifiquen en la red las actualizaciones requeridas. De ese modo, aun si un atacante engaña al usuario para que ejecute una versión antigua, dicha versión antigua reconocerá que se debe actualizar. Asimismo, el uso de un esquema claro de versiones para la aplicación hace más difícil engañar a los usuarios para que instalen una versión desactualizada.
|
|
|