Inversion de code – Fonctions HTTP Lambda


Normalement, lorsque nous créons un point de terminaison HTTP REST, nous ajoutons du code à notre point de terminaison de serveur et supposons que le client fournit les arguments à notre code. Et si nous pouvions inverser cette responsabilité, de sorte que le client fournisse le code que le serveur exécute?

Entre autres choses, cela implique que nous pouvons avoir un point de terminaison faisant “tout”. Nous n’aurions pas besoin de créer des dizaines de points de terminaison pour exposer notre API, et nous pourrions nous en sortir avec la création d’un seul point de terminaison, que les clients invoquent, indépendamment de ce qu’ils veulent faire. Si le client souhaite créer un enregistrement dans notre base de données, lire des enregistrements dans notre base de données ou compter des enregistrements dans notre base de données n’est pas pertinent – il utiliserait toujours le même point de terminaison pour toutes ces tâches. De plus, le client pourrait devenir beaucoup plus créatif en ce qui concerne la façon dont il interagit avec notre API et faire des choses que nous ne pouvions même pas imaginer lorsque nous avons créé notre API. Ce dernier résume bien sûr le problème, qui est que les clients pourraient injecter du code malveillant dans notre serveur.

Sécuriser vos fonctions lambda

Cependant, si nous avions une méthode pour nous assurer que le client n’était jamais en mesure d’injecter du code malveillant dans notre point de terminaison, nous pourrions lui permettre en toute sécurité d’injecter du code et d’exécuter son code sur notre serveur, même sans savoir ce que fait son code, ni même s’en soucier sur qui le client est d’ailleurs. Ce dernier est en fait possible dans Hyperlambda grâce à une fonctionnalité que je viens de publier hier appelée “liste blanche”. La liste blanche de mots-clés et de fonctions dans Hyperlambda me permet de créer un contexte d’exécution dans lequel seuls les éléments que je considère comme sûrs peuvent être exécutés. Cela me permet d’éviter que des clients fassent des choses comme par exemple.

  • Lire les mots de passe de mes fichiers de configuration
  • Suppression des tables de base de données
  • Création de fichiers malveillants
  • Etc …

Ceci n’est possible que dans Hyperlambda en raison du fait que Hyperlambda est un “machine d’exécution virtuelle”, un peu comme ByteCode ou le CLR, seulement beaucoup plus structuré. Cela me permet à nouveau de créer une liste de mots-clés et de fonctions que j’autorise à être exécutés dans un contexte d’exécution, et que toutes les autres invocations de fonctions et de mots-clés lèvent une exception, sans même être exécutées. Laissez-moi vous montrer du code.

Le code ci-dessus est en fait Hyperlambda destiné à devenir un point de terminaison HTTP REST. Pour l’invoquer, vous pouvez transmettre une charge utile telle que la suivante.

Si vous mettez le premier code ci-dessus dans un fichier appelé par ex. “evaluer.patch.hl” dans votre dossier modules, pour ensuite appeler le point de terminaison et transmettre le deuxième extrait de code ci-dessus, ce qui se passera est le suivant.

  1. Votre code sera transmis au point de terminaison HTTP REST
  2. Votre code sera analysé structurellement, ce qui entraînera un “lambda” structure
  3. Le lambda sera ajouté à ce qui précède [.lambda] nœud
  4. Un nouveau [whitelist] la portée sera créée
  5. Votre code sera exécuté dans cette portée de liste blanche sécurisée

Ce processus interdit à l’utilisateur d’invoquer quoi que ce soit qui n’est pas explicitement déclaré à l’intérieur de ce qui précède [vocabulary] node, ce qui signifie que si l’utilisateur tente d’appeler par exemple [config.get], pour lire les paramètres de configuration, une exception sera levée. Seules les fonctions et mots-clés suivants sont autorisés dans le code du client.

  • ajouter
  • déballer
  • revenir
  • vocabulaire
  • slots.vocabulaire
  • signal: magic.google.translate

Si le client tente d’invoquer quelque chose qui ne se trouve pas dans la liste ci-dessus, mon serveur lèvera une exception. Et bien sûr, depuis que j’ai ajouté le vocabulaire à la liste blanche ci-dessus, le client peut interroger mon point de terminaison, pour lui demander quelles fonctions et quels mots-clés il est autorisé à utiliser dans son code. Regardez-moi démontrer le concept dans la vidéo suivante.

Cette façon de penser à responsabilité inversée à propos de vos points de terminaison HTTP se traduit par de nombreux scénarios intéressants. Par exemple, le réseau de crypto-monnaie Ethereum est exclusivement construit sur des idées similaires, sauf que faire référence à cela est “contrats intelligents”. Cependant, dans Ethereum, un client peut facilement injecter du code malveillant, ce que la recherche Microsoft a prouvé il y a longtemps. Une fois qu’un client a injecté du code malveillant, 50 millions de dollars ont été perdus. Plus tard, ils ont corrigé et bifurqué le réseau en conséquence, essayant de résoudre le problème – Mais avec les points de terminaison Hyperlambda, un tel scénario ne pouvait même pas exister en théorie, en supposant que vous ayez confiance en son [whitelist] et ne mettez pas sur liste blanche les mots-clés et fonctions dangereux.

Fondamentalement, cela devient la mise en œuvre même de ce que nous avons appelé “Web sémantique”, là où les serveurs Web et les clients peuvent “communiquer entre vous”, parlant une langue commune, étant le sous-ensemble d’un vocabulaire, explicitement autorisé par le serveur. Résultant en un langage commun, compris par les deux parties, leur permettant de communiquer sémantiquement avec l’un l’autre. Par conséquent, il devient une plate-forme commune de compréhension, entre deux parties distinctement différentes, qui n’ont normalement aucune idée de ce que l’autre partie tente même de communiquer. Ou pour utiliser une analogie.

Cela nous permet de communiquer avec des extraterrestres

Close Menu