L'outil de sécurité Web copie les mouvements des applications

De nos jours, il est facile pour les développeurs de créer des applications à part entière qui s'exécutent dans le navigateur. Protéger ces applications des pirates est une autre affaire.

Jouer la prudence : Les chercheurs de Microsoft ont utilisé Ripley pour sécuriser plusieurs applications Web, dont des jeux.

Dans cet esprit, les scientifiques de Microsoft Research ont dévoilé une nouvelle façon de sécuriser des applications Web complexes en clonant efficacement le navigateur de l'utilisateur et en l'exécutant à distance.

La plupart des dernières applications Web divisent leur code exécutable entre le serveur et le client. Le problème consiste à détecter si le code exécuté sur le PC domestique de l'utilisateur a été compromis d'une manière ou d'une autre. La nouvelle solution Microsoft, connue sous le nom de Ripley, a été annoncée mardi à l'Association for Computing Machinery's Conférence sur la sécurité informatique et des communications à Chicago.

Ripley va plus loin que les efforts précédents pour sécuriser l'intégrité des applications Web. Il pousse la protection de l'intégrité à son extrême logique, dit Adam Barth , chercheur à l'Université de Californie à Berkeley, spécialisé dans la sécurité des applications Web. Il n'était pas impliqué dans le projet. Au lieu de simplement vérifier qu'une demande provient du site Web approprié, Ripley vérifie que les actions de l'utilisateur sont réellement autorisées par l'interface utilisateur de l'application.

Ripley empêche un utilisateur malveillant ou un pirate informatique distant de modifier le comportement du code exécuté dans un navigateur Web en créant une copie exacte de l'environnement de calcul et en exécutant cette copie sur le serveur. Ripley envoie ensuite toutes les actions de l'utilisateur, y compris les clics de souris, les frappes au clavier et toute autre entrée, dans un flux d'événements compressé du client au serveur. Ce flux est exécuté via l'application cliente clonée sur le serveur, et le comportement de ce sosie virtuel est comparé à celui de l'application exécutée sur le navigateur de l'utilisateur à la maison. S'il y a des divergences, Ripley déconnecte le client.

Vous ne pouvez pas faire confiance à tout ce qui se passe chez le client, dit Ben Livshits , le chercheur principal de Microsoft Research sur le projet Ripley. C'est essentiellement le diable dans le navigateur du point de vue du développeur.

Ripley est invisible pour l'utilisateur final et n'affecte pas le fonctionnement normal d'une application Web. Ce ne sont que les gars malveillants qui doivent s'inquiéter de ce qui se passe une fois qu'ils soumettent un résultat, dit Livshits.

L'un des défis que Livshits et son collaborateur chez Microsoft, Emre Kiciman , rencontré lors de la création de Ripley était de savoir comment créer une copie de l'ensemble de l'environnement client - l'application Web et le moteur logiciel qui l'exécute - qui était suffisamment petite pour être pratique pour un serveur Web à grand volume traitant les demandes de centaines ou de milliers d'utilisateurs à une fois.

Sur le serveur, a déclaré Livshits, si vous deviez exécuter la réplique dans un navigateur, vous auriez une empreinte mémoire de 50 à 60 mégaoctets par instance de navigateur. La solution que lui et Kiciman ont conçue consistait à exécuter à la place un navigateur sans tête, un émulateur qui simule uniquement les fonctions d'un navigateur Web essentielles à Ripley. Cela a réduit l'empreinte mémoire du navigateur et de l'application clonés à entre un et un mégaoctet et demi par application.

En réduisant le clone côté serveur de l'application basée sur le navigateur de l'utilisateur, Livshits et Kiciman, en collaboration avec des collègues de l'Université Cornell de New York et de l'Institut indien de technologie de Delhi, ont encore réduit les frais généraux de performances de Ripley. Sur cinq applications expérimentales, qui comprenaient un panier, plusieurs jeux et un moteur de blog, l'augmentation moyenne de la latence due aux efforts accrus du processeur du serveur était d'environ une milliseconde.

Dans certains cas, Ripley a même amélioré les performances des applications Web, car le clone côté serveur de l'application cliente est réécrit en .NET, un langage de programmation 10 à 100 fois plus rapide que JavaScript exécuté côté client. Parfois, cela permet à Ripley de prédire quelle sera la prochaine demande d'application côté client avant même qu'elle n'ait été faite par le client, et de transmettre de manière préventive les données au client.

C'est une situation magique, si vous y réfléchissez, dit Livshits. Cela conduit à des appels de procédure à distance à latence nulle.

À l'heure actuelle, les développeurs intéressés par l'utilisation de Ripley pour sécuriser leurs applications Web devraient réimplémenter les idées du document présenté sur Ripley sur leur propre cadre d'application Web préféré. Cependant, à terme, Livshits et Kiciman pensent que Ripley pourrait aider à démocratiser une partie essentielle de la sécurité des applications Web, en la mettant à la portée des développeurs non experts.

Jusqu'à présent, je pense que les gens ont attaqué ces problèmes manuellement, dit Kiciman. Vous obtenez des experts qui se lancent et ils adaptent leurs applications pour relever ces défis, mais ce n'est pas très évolutif et pas très agile lorsque vous devez apporter des modifications. Ce que nous essayons de faire, c'est d'amener la plate-forme de développement Web à un point où tout le monde peut tirer parti des types de technologie que ces experts utilisent.

Barth de l'UC Berkeley note que Ripley fait partie d'une tendance plus large dans les solutions qui protègent l'intégrité du code côté client en garantissant qu'aucun comportement non autorisé ne peut se produire. Je vois Ripley plus comme une expérience de pensée : que se passerait-il si le serveur validait tout ? il dit. Le travail suggère que la sécurité bénéficierait si nous validions plus que ce que nous validons aujourd'hui.

cacher