Je souhaite utiliser node.js (ou une autre solution SSJS), en exécutant mon propre code + code écrit externe à l'intérieur (non approuvé). Un moyen de séparer et de protéger mon propre code?Sécurisation de SSJS par rapport au code non vérifié
Puis-je limiter les modules et l'effet système du code non sécurisé (limiter l'accès aux fichiers, aux ports non HTTP, etc.)?
Vous pouvez consulter ce projet, il semble très prometteur:
http://github.com/gf3/node-sandbox
Personnellement, je ne pas utiliser de nœud pour faire l'exécution SSJS arbitraire. Vous n'aimerez probablement pas cette solution, mais cela fonctionne bien pour moi depuis environ un an:
Il existe une implémentation Perl de l'API de Spidermonkey (Spidermonkey est le moteur JS de Firefox) that's available. J'ai accroché ça avec l'aide de certains CGI. Vous pouvez y spécifier exactement les fonctions que vous voulez exposer (accordées, c'est en Perl ... blech) et exécuter le code que vous voulez. Il n'y a pas de risque de vulnérabilités puisque l'installation entière est entièrement en sandbox. Il ne simule pas le DOM. La façon dont j'ai implémenté ceci sur mon serveur (pour empêcher les abus) était d'émettre des jetons qui accordaient un accès à usage unique via une API REST sur un serveur différent. C'est une implémentation HMAC simple qui inclut un horodatage pour renforcer la légitimité du jeton. Lorsque le script Perl reçoit une requête, il valide le jeton et traite le script (le script doit simplement faire partie d'une requête POST). Le script Perl écrit alors simplement les résultats. Mon serveur est configuré pour atteindre un délai d'attente d'environ 10 secondes.
Espérons que cela aide!
@Rook En fait, vous avez tort. Ce n'est même pas le chiffrement, c'est l'authentification. C'est la même technique qu'Amazon AWS utilise. Plus techniquement, ce n'est pas une "baguette magique crypto", c'est un moyen légitime de sécuriser n'importe quelle API REST frontale. Peu importe ce qui est utilisé comme un secret HMAC. Sautez sur n'importe quel générateur de texte aléatoire et utilisez les 30 premiers caractères environ, peu importe. Bien que vous ayez fait comprendre que vous ne comprenez pas beaucoup à propos de la sécurité. – mattbasta
@mattbasta crypto est l'abréviation de cryptographie et une fonction de hachage cryptographique telle que sha256 entre dans cette catégorie. Clairement, la sécurité est un sujet très en profondeur et tout le monde a plus à apprendre. Mais en bref, je n'aime pas cette approche à la gestion d'une vulnérabilité d'exécution de code à distance. Il y a une bonne citation "Si eval() est la réponse alors vous posez la mauvaise question". Il n'y a absolument aucune raison pour que quelqu'un exécute un code comme celui-ci. Il est probable que le PO prend un raccourci et il sera brûlé par cette réponse partielle. – rook
@Rook Pour la dernière fois, ce n'est pas une vulnérabilité. Il n'y a pas d '"eval", car le code fonctionne dans un environnement avec littéralement rien à casser. Il n'y a littéralement aucun moyen de modifier les informations sensibles, d'accéder au disque ou de faire des demandes sortantes. C'est l'idée derrière un bac à sable: clairement un sujet que votre professeur de sécurité doit avoir effleuré. Bien sûr, l'exécution de code dans une instruction 'eval' est mauvaise, mais si l'OP veut lancer le JS d'un utilisateur, alors l'exécuter dans un environnement en sandbox est le moyen le plus sûr et le plus efficace d'atteindre cet objectif. Nommer une vulnérabilité exposée par un bac à sable. – mattbasta
Jetez un oeil à Caja. Il traduit le code tiers en un formulaire où le code a uniquement accès aux objets que vous lui accordez explicitement.
caja est cool, aussi, il vous suffit de faire l'effort de cajoler et de comprendre ce que vous faites (et ont besoin de Java, etc.) –
Vérifiez ce de la documentation Node.js
script.runInNewContext ([bac à sable])
similaires à Script.runInNewContext (note du capital 'S'), mais étant maintenant une méthode d'un objet Script précompilé. script.runInNewContext exécute le code de script avec sandbox en tant qu'objet global et renvoie le résultat. Le code en cours d'exécution n'a pas accès à la portée locale. bac à sable est facultatif.
Attention, à partir des docs actuels: Notez que l'exécution de code non fiable est une affaire délicate nécessitant beaucoup de soin. Script.runInNewContext est très utile, ** mais pour exécuter un code non fiable, il faut un processus séparé **. –
Oui, mais cela dépend vraiment du privilège du processus actuel. Cela implique probablement que vous créez un nouveau processus avec des privilèges moindres, ce qui nécessite plus de privilèges (c'est-à-dire le démarrage du démon en tant que root). Donc, oui, sandboxing une exécution globale à un nouveau processus est bon, mais si vous exécutez en tant qu'utilisateur non privilégié pour commencer, vous êtes probablement OK. Cela dépend aussi de la façon dont la mission est critique. Si c'est le blog de votre chat, vous êtes probablement OK quoi que vous fassiez. Si c'est un site transactionnel conforme à la norme PCI, ce serait un peu différent. Pas vraiment dit en question ... –
Wow vous ne voyez pas très js-côté serveur souvent. ; – rook