Comment utiliser les gestionnaires d'URL et OpenURL en toute sécurité dans votre application Unity

L'équipe Unity Security a pour mission d'aider les créateurs d'Unity à concevoir des jeux et des applications plus fiables. Suivez cette série de blogs pour obtenir des conseils, des techniques et des recommandations pour créer des jeux et des applis plus sécurisés avec Unity.

Nous lançons aujourd'hui une série de blogs sur le développement sécurisé avec Unity. Cette série fournira du contenu que les développeurs Unity pourront appliquer directement dans leurs jeux et applications. Nous espérons couvrir une variété de sujets allant des connaissances de base aux connaissances avancées, axées sur les meilleures pratiques dans l'utilisation des produits et services Unity. Si vous souhaitez lire un article sur un sujet particulier, n'hésitez pas à nous le faire savoir. Nous attendons avec impatience vos commentaires. L'objectif principal de ce blog est de donner une vue d'ensemble des gestionnaires d'URL.

Les URL et les gestionnaires de fichiers associent les types de fichiers au programme installé qui peut ouvrir le fichier spécifié, mais ils comportent des risques. Par exemple, lorsque vous êtes sur votre machine locale et que vous double-cliquez pour ouvrir un fichier PDF à partir de votre lecteur local, votre système d'exploitation se réfère à sa liste de gestionnaires de fichiers et sélectionne le programme assigné à ce type de fichier, de sorte que votre PDF est ouvert par un programme capable de l'afficher correctement. Les gestionnaires de fichiers utilisent généralement l'extension du fichier (par exemple, .pdf - le suffixe à la fin du nom du fichier) pour décider comment traiter le fichier.

Un mécanisme similaire, le gestionnaire d'URL, décide comment ouvrir les URL en fonction du préfixe du chemin. Le protocole https://, omniprésent, qui ouvre votre navigateur par défaut, en est un exemple. Un autre exemple d'URL commun serait file://c:/windows/system32/drivers/gmreadme.txt ; en saisissant cette URL dans la boîte de dialogue Exécuter, Windows ouvrira ce fichier de licence dans le Bloc-notes.

Les gestionnaires d'URL sont une fonctionnalité utile de votre système d'exploitation qui permet aux utilisateurs de gagner du temps lors du lancement d'applications. Toutefois, ce mécanisme pratique peut parfois s'avérer dangereux.

L'éditeur Unity et le moteur d'exécution Unity prennent en charge l'utilisation programmatique des gestionnaires d'URL, à la fois par leur utilisation du .NET Framework, mais aussi par une API de script Unity spécifique, à savoir Application.OpenURL. Les développeurs de jeux utilisent souvent Localization pour que, lorsqu'un joueur clique sur un lien dans le jeu, le navigateur web du système local soit lancé. Cependant, si le développeur du jeu n'assainit pas correctement ce qui est transmis à Application.OpenURL, son joueur peut être en danger.

Cette API de script n'est pas intrinsèquement dangereuse, mais dans tous les cas où une entrée non fiable est utilisée dans le cadre de l'URL transmise, vous devez faire preuve de prudence.

Les entrées/données non fiables sont des données qui ne proviennent pas d'une source fiable. Qu'est-ce qu'une source fiable ? Dans le contexte de cet article, seuls les points de terminaison pour lesquels le protocole HTTPS strict est activé doivent être considérés comme fiables.

Il existe de nombreux exemples de données non fiables. Si vous concevez un système anti-triche, le système de fichiers local du joueur doit être considéré comme non fiable. Si vous développez un jeu multijoueur, tous les joueurs doivent être considérés comme non fiables.

Il existe d'autres moyens de protéger les données/entrées en tirant parti d'éléments tels que le chiffrement par clé publique-privée, mais ceux-ci dépassent le cadre de cet article. (Laissez un commentaire si vous souhaitez en savoir plus).

Bien que ces gestionnaires soient très pratiques pour les utilisateurs, ils comportent des risques inhérents. Voici un exemple d'utilisation non sécurisée de Application.OpenURL :

en utilisant UnityEngine ;
using System.Collections ;

public class VulnerableBrowserClass : MonoBehaviour {
// Transmettre l'URL du lien sur lequel le joueur a cliqué à partir de nos forums de jeu.
void OpenBrowser(string url_from_chat) {
Application.OpenURL(url_from_chat) ; // ←- Mauvaise chose ici ; la valeur n'est pas assainie
}
}

Figure 1. Exemple d'utilisation dangereuse de Application.OpenURL

Dans cet exemple, le système de commentaires du jeu permet aux utilisateurs de partager des liens ; lorsqu'un utilisateur clique sur un lien, la fonction VulnerableBrowserClass.OpenBrowser est appelée.

Figure 2. Exemple de scénario avec un lien potentiellement dangereux

Vous pouvez constater à quel point il est facile d'envoyer à un utilisateur peu méfiant un lien vers une application potentiellement dangereuse (figure 2). Si cette URL est transmise directement à Application.OpenURL, comme le montre la figure 1, la machine de la victime exécutera immédiatement l'application à partir de ce lien, ce qui permettra potentiellement à un attaquant de prendre le contrôle du système de la victime.

Dans l'image ci-dessus, l'attaquant pourrait formater le lien ci-dessus pour qu'il apparaisse comme https://SuperLeetCheats.com/VulnTheGame dans la fenêtre de discussion, mais que le lien réel renvoie à son logiciel malveillant à l'adresse suivante : file://leethaxorz.net/super_malware.exe. Le problème n'est pas que les utilisateurs peuvent s'envoyer des liens ; le problème réside dans le fait de prendre les liens envoyés par un utilisateur (potentiellement l'attaquant) et de les transmettre directement à Application.OpenURL sans aucune validation ou assainissement, comme le montre l'exemple de code ci-dessus (Figure 1). Sans cette vérification, en cliquant sur le lien ci-dessus, l'éditeur d'Unity transmettrait le fichier directement au système d'exploitation du joueur cible, ce qui entraînerait probablement l'exécution du logiciel malveillant de l'attaquant.

La manière la plus sûre d'utiliser Application.OpenURL est de ne jamais l'utiliser avec des données non fiables. Ne l'utilisez que pour ouvrir des URL provenant de vos développeurs ou de vos serveurs, et par le biais d'un moyen de transport fiable (c'est-à-dire HTTPS).

Si vous utilisez des configurations à distance (par exemple, si vous hébergez une liste d'URL de contenu pour les nouvelles mises à jour), veillez à ce que ces données ne soient récupérées que via HTTPS, avec une application stricte. Il faut toujours récupérer le contenu distant de cette manière.

Remarque : HTTPS ne résoudra pas les vulnérabilités de votre application dues à une entrée non fiable/non nettoyée, comme décrit dans l'attaque ci-dessus. Il garantit toutefois que les données que vous envoyez à votre lecteur n'ont pas été altérées pendant le transport.

Si vous avez décidé que vous devez absolument utiliser OpenUrl avec des données provenant de sources non fiables, vous devez faire de votre mieux pour assainir les données que vous recevez de la source non fiable. Il existe plusieurs façons d'y parvenir, par exemple en utilisant la correspondance de motifs (regex), en construisant des URL à l'aide de bibliothèques .Net ou en exploitant des bibliothèques d'assainissement externes. Cependant, aucune de ces mesures ne fonctionnera dans 100 % des cas, et quelle que soit la solution choisie, un certain risque potentiel est assumé si Application.OpenUrl (et des fonctions similaires) est utilisé avec des données non fiables.

En outre, comme le montre la figure 2 ci-dessus, les utilisateurs n'ont aucun moyen de connaître l'URL qui se cache derrière ce lien. Au minimum, donnez aux utilisateurs une invite avec l'URL complète qu'ils sont sur le point de visiter. Mais il ne faut pas considérer cela comme une solution solide, car les utilisateurs sont connus pour cliquer aveuglément sur n'importe quelle invite qui leur est présentée.

L'utilisation d'OpenURL et de gestionnaires de fichiers est très courante pour les développeurs, en particulier pour les applications multimédias et les fonctions de type médias sociaux, telles que le chat, les critiques et les commentaires dans le jeu, où les utilisateurs souhaitent généralement partager du contenu qui réside en dehors du jeu sur l'internet. En outre, il existe des scénarios de productivité courants, tels que l'édition d'un fichier de configuration, dans lesquels vous pouvez vouloir passer un lien au système d'exploitation, ouvrant l'application d'édition de code préférée de l'utilisateur, par commodité pour ce dernier. Application.OpenURL est une API indépendante de la plateforme qui prend en charge les gestionnaires de fichiers, ce qui évite aux développeurs d'Unity d'avoir à écrire leurs propres gestionnaires pour chaque plateforme.

Non. Comme décrit ci-dessus, il s'agit d'une fonctionnalité commune à la plupart des systèmes d'exploitation et qui est prise en charge par de nombreux langages et frameworks. Attention à l'utilisation de l'API Windows Windows.System.LauchURIAsync (pour les apps Universal Windows Platform [UWP]), ou de la redoutable System.Diagnostics.Process.Start; ces deux bibliothèques .Net natives fournissent la même fonctionnalité que Application.OpenURL. LaunchURIAsync permet de lancer des applications à partir du bac à sable sécurisé de Windows, et Process.Start peut être utilisé pour lancer n'importe quel exécutable sur le système local. En outre, certains appels natifs du système d'exploitation offrent la même fonctionnalité, comme open(_:options:completionHandler :) d'Apple . Tous ces types d'API peuvent être facilement détournés si des données d'entrée non fiables et non nettoyées sont transmises à ces API.

Nous publierons ici régulièrement des articles sur des sujets essentiels à la pratique et au maintien des meilleures pratiques de sécurité lors du développement avec Unity. Les prochains thèmes abordés seront le transport sécurisé des données de jeu et la démocratisation du cycle de développement sécurisé des logiciels (SSDLC). Nous travaillons également à l'ouverture de certains de nos outils internes d'orientation et de sécurité.

Y a-t-il un sujet relatif à la sécurité sur lequel vous aimeriez en savoir plus dans un prochain article ? Envoyez-nous un message !

En savoir plus sur Unity Security, y compris les avis de sécurité.