Cómo usar manejadores de URL y OpenURL de forma segura en tu aplicación Unity

El equipo de seguridad de Unity se centra en ayudar a los creadores de Unity a crear juegos y aplicaciones más fiables. En esta serie de blogs encontrarás consejos, técnicas y recomendaciones para crear juegos y aplicaciones más seguros con Unity.

Hoy lanzamos una serie de blogs sobre el desarrollo seguro con Unity. Esta serie ofrecerá contenidos que los desarrolladores de Unity podrán aplicar directamente en sus juegos y aplicaciones. Esperamos cubrir una variedad de temas que van desde conocimientos básicos a avanzados, centrados en las mejores prácticas dentro del uso de los productos y servicios de Unity. Si hay algún tema sobre el que le gustaría leer, háganoslo saber. Esperamos sus comentarios. El objetivo principal de este blog es ofrecer una visión general de los gestores de URL.

Los gestores de URL y archivos asocian tipos de archivo con el programa instalado que puede abrir el archivo especificado, pero conllevan riesgos. Por ejemplo, cuando está en su equipo local y hace doble clic para abrir un archivo PDF desde su unidad local, su sistema operativo consulta su lista de gestores de archivos y selecciona el programa asignado para ese tipo de archivo, de modo que su PDF se abre con un programa que puede mostrarlo correctamente. Los gestores de archivos suelen utilizar la extensión del archivo (por ejemplo, .pdf - el sufijo al final del nombre del archivo) para decidir cómo manejarlo.

Un mecanismo similar, el manejador de URL, decide cómo abrir las URL basándose en el prefijo de la ruta. Un ejemplo sería el omnipresente protocolo https://, que abre tu navegador por defecto. Otro ejemplo de un esquema de URL común sería file://c:/windows/system32/drivers/gmreadme.txt; al introducir esta URL en el cuadro de diálogo Ejecutar, Windows abrirá este archivo de licencia en el Bloc de notas.

Los gestores de URL son una función útil del sistema operativo que ahorra tiempo a los usuarios al iniciar aplicaciones. Sin embargo, este cómodo mecanismo puede resultar inseguro en ocasiones.

El Editor de Unity y el Tiempo de Ejecución de Unity soportan el uso programático de manejadores de URL, ambos a través de su uso del .NET Framework, pero también a través de una API específica de scripting de Unity, llamada Application.OpenURL. Los desarrolladores de juegos suelen utilizar OpenUrl para que, cuando un jugador haga clic en un enlace del juego, se inicie el navegador web del sistema local. Sin embargo, si el desarrollador del juego no sanea adecuadamente lo que se pasa a Application.OpenURL, su jugador podría estar en peligro.

Esta API de secuencias de comandos no es intrínsecamente insegura, pero en cualquier caso en el que se utilicen entradas no fiables como parte de la URL que se pasa, hay que tener cuidado.

Los datos no fiables son aquellos que no proceden de una fuente fiable. Entonces, ¿qué es una fuente fiable? En el contexto de este artículo, sólo los puntos finales con HTTPS estricto activado deben considerarse de confianza.

Hay muchos ejemplos de entradas no fiables. Si estás diseñando un sistema antitrampas, el sistema de archivos local del jugador debe considerarse no fiable. Si estás desarrollando un juego Multiplayer, todos los jugadores deben ser considerados de no confianza.

Existen otras formas de proteger los datos y las entradas, como el cifrado de clave pública y privada, pero no son objeto de este artículo. (Deja un comentario si te interesa saber más sobre esto).

Aunque estos manipuladores ofrecen una gran comodidad a los usuarios, conllevan riesgos inherentes. Este es un ejemplo de uso inseguro de Application.OpenURL:

usando UnityEngine;
usando System.Collections;

public clase VulnerableBrowserClass: MonoBehaviour {
// Introduce la URL del enlace que un jugador ha pulsado en los foros de nuestro juego
void OpenBrowser(string url_from_chat) {
Application.OpenURL(url_from_chat); // ←- Badness here; value isn't sanitized
}
}

Figura 1. Ejemplo de uso no seguro de Application.OpenURL

En este ejemplo, el sistema de comentarios del juego permite a los usuarios compartir enlaces; cuando un usuario hace clic en un enlace, se llama a la función VulnerableBrowserClass.OpenBrowser.

Figura 2. Ejemplo de situación con un enlace potencialmente peligroso

Se puede ver lo fácil que es enviar a un usuario desprevenido un enlace a una aplicación potencialmente peligrosa (Figura 2). Si esa URL se pasa directamente a Application.OpenURL, como se muestra en la Figura 1, la máquina de la víctima ejecutará inmediatamente la aplicación en ese enlace, permitiendo potencialmente a un atacante tomar el control del sistema de la víctima.

En la imagen anterior, el atacante podría formatear el enlace de arriba para que aparezca como https://SuperLeetCheats.com/VulnTheGame en la ventana de chat, pero hacer que el enlace real vaya a su malware en: file://leethaxorz.net/super_malware.exe. El problema aquí no es que los usuarios puedan enviarse enlaces entre sí; el problema radica en tomar los enlaces enviados por un usuario (potencialmente el atacante) y pasarlos directamente a Application.OpenURL sin ningún tipo de validación o sanitización, como se ve en el ejemplo de código anterior (Figura 1). Sin esta desinfección, al hacer clic en el enlace anterior, el editor de Unity enviaría el archivo directamente al sistema operativo del jugador objetivo, lo que probablemente provocaría la ejecución del malware del atacante.

La forma más segura de utilizar Application.OpenURL es no utilizarlo nunca con datos que no sean de confianza. Utilícelo sólo para abrir URL que procedan de sus desarrolladores o servidores, y a través de un transporte de confianza (es decir, HTTPS).

Si utiliza configuraciones remotas (por ejemplo, aloja una lista de URL de contenido para nuevas actualizaciones), asegúrese de que estos datos se recuperan únicamente a través de HTTPS, con un cumplimiento estricto. Recupere siempre el contenido remoto de esta manera.

Nota: HTTPS no solucionará ninguna vulnerabilidad en tu aplicación debida a entradas no confiables/no sanitizadas como las descritas en el ataque anterior. Sin embargo, garantizará que los datos que envíes a tu reproductor no hayan sido manipulados durante el transporte.

Si ha decidido que es absolutamente necesario utilizar OpenUrl con datos de fuentes no fiables, entonces debe hacer todo lo posible para desinfectar la entrada que recibe de la fuente no fiable. Existen varias formas de hacerlo, como la concordancia de patrones regex, la creación de URL mediante bibliotecas .Net o el uso de bibliotecas de desinfección externas. Sin embargo, ninguna de estas mitigaciones funcionará el 100% de las veces, e independientemente de la solución que elija, se asume cierto riesgo potencial si Application.OpenUrl (y funciones similares) se utiliza con datos no fiables.

Además, como se muestra en la figura 2, los usuarios no pueden saber qué URL hay detrás de ese enlace. Como mínimo, indique a los usuarios la URL completa que van a visitar. Pero no debería considerar esto una solución sólida, ya que los usuarios son conocidos por hacer clic en cualquier aviso que se les ponga delante a ciegas.

El uso de OpenURL y gestores de archivos es muy común para los desarrolladores, sobre todo con aplicaciones multimedia y funciones similares a las redes sociales, como el chat, las reseñas y los comentarios dentro del juego, donde los usuarios suelen querer compartir contenidos que residen fuera del juego en Internet. Además, hay escenarios de productividad comunes, como la edición de un archivo de configuración, donde es posible que desee pasar un enlace al sistema operativo, la apertura de la aplicación de edición de código preferido del usuario como una conveniencia para el usuario. Application.OpenURL es una API independiente de la plataforma para soportar manejadores de archivos, ahorrando a los desarrolladores de Unity el tener que escribir sus propios manejadores para cada plataforma.

No. Como se ha descrito anteriormente, se trata de una funcionalidad común en la mayoría de los sistemas operativos y está soportada por muchos lenguajes y frameworks. Tenga cuidado con el uso de la API de Windows Windows.System.LauchURIAsync (para aplicaciones de la Plataforma Universal de Windows [UWP]), o la temida System.Diagnostics.Process.Start; ambas bibliotecas nativas de .Net proporcionan la misma funcionalidad que Application.OpenURL. LaunchURIAsync permite lanzar aplicaciones desde dentro del sandbox seguro de aplicaciones de Windows, y Process.Start puede utilizarse para lanzar cualquier ejecutable en el sistema local. Además, algunas llamadas nativas del SO proporcionan la misma funcionalidad, como open(_:options:completionHandler:) de Apple. Todos estos tipos de API pueden ser fácilmente objeto de abuso si se introducen en ellas datos no fiables y no desinfectados.

Estaremos publicando artículos aquí periódicamente sobre temas críticos para practicar y mantener las mejores prácticas de seguridad al desarrollar con Unity. Entre los próximos temas figuran el transporte seguro de datos de juegos y la democratización del ciclo de vida del desarrollo de software seguro (SSDLC). También estamos trabajando para abrir algunas de nuestras herramientas internas de orientación y seguridad.

¿Hay algún tema de seguridad sobre el que le gustaría saber más en un futuro artículo? Póngase en contacto con nosotros

Más información sobre Unity Security, incluidos los avisos de seguridad.