Nous prévoyons de donner la possibilité d'écrire des extensions communautaires en javascript pour notre webapp publique et de permettre aux utilisateurs de personnaliser leurs instances de l'application. Le problème est de surveiller la qualité des extensions.
Que suggéreriez-vous pour automatiser ce processus?
Ou comment analyser Javascript pour les codes malveillants?
En quelques mots, nous aimerions avoir un service comme un antivirus qui scannerait en temps réel les extensions téléchargées pour être malveillant. Et s'il détecte un code suspect, il générerait une alerte.
Tout indice/conseil est le bienvenu! Je vous remercie.
Une approche consisterait à définir une API sûre pour les extensions à utiliser, en déclarant les objets implémentant cette API dans le périmètre d'exécution de l'extension. Ensuite, exigez que le code d'extension soit écrit dans une version bac à sable de Javascript, afin que le code d'extension puisse appeler uniquement les méthodes API sécurisées que vous avez définies et rien de plus.
Donc, si votre API consistait en un objet stocké dans une variable api
, alors le code:
var x = api.frob();
x.bar();
serait autorisé à utiliser le code d'extension, car api
fait partie de votre API sécurisée et les variantes Javascript sécurisées vous permettent d'appeler l'API exposée au code d'extension.
Cependant, le code:
document.createElement("img");
ne serait pas autorisé, car document
ne fait pas partie de votre API sécurisée.
Lors de la conception de l'API, assurez-vous qu'aucun objet exposé ne possède de propriétés qui pourraient être utilisées de manière malveillante. Pour donner un accès limité à une ressource, utilisez des fermetures pour créer des fonctions qui référencent en privé la ressource.
Il existe un certain nombre de projets qui ont défini une version bac à sable de Javascript que vous pouvez utiliser à cette fin: SES , Caja , ADsafe , FBJS , et autres. SES et Caja permettent aux développeurs d'écrire du code avec le moins de restrictions: cela ressemble beaucoup à l'écriture de Javascript, avec quelques restrictions mineures (par exemple, pas de eval
, pas de with
). ADsafe et FBJS nécessitent que le développeur apprenne une variante de Javascript. SES, ADsafe et FBJS ont les meilleures performances. SES nécessite la prise en charge d'un moteur Javascript très récent et n'est donc pas compatible avec certains navigateurs Web plus anciens. Si le code d'extension sera exécuté côté serveur, alors SES peut être le meilleur choix, car vous pouvez vous assurer que votre moteur Javascript est à jour. Si l'extension doit être exécutée sur le navigateur de l'utilisateur, vous pouvez envisager Caja si l'extension n'est pas critique en termes de performances, ou ADsafe/FBJS si c'est le cas.
Il n'y a pas de bon moyen de scanner Javascript pour les codes malveillants. Tu ne peux pas le faire. Le problème est qu'il existe trop de façons pour un développeur malveillant/escroc de cacher des éléments malveillants dans son code, et vous ne pourrez jamais tout détecter.
L'antivirus n'est pas utile ici. Vous devez comprendre un peu le fonctionnement du logiciel antivirus et ses limites. En gros, voici comment cela fonctionne. Si la société antivirus détecte un virus infectant de nombreuses machines, elle analyse le virus, identifie une signature du virus (par exemple, un extrait de son code) et l'intègre dans son moteur. Par la suite, si votre machine est infectée par une copie de cette copie particulière (la même que celle qu'ils ont analysée), le logiciel antivirus détectera sa présence via cette signature. En conséquence, les logiciels antivirus ne sont utiles principalement que contre les virus qui se sont largement répandus. Le logiciel antivirus existant ne détectera pas de code malveillant dans une extension malveillante pour votre application Web. Le logiciel antivirus a certaines utilisations, mais il est essentiellement inutile pour votre scénario particulier.
Vous devez accepter que ce n'est pas un problème que vous pouvez résoudre en scannant le code. Vous devrez donc envisager une autre approche. Quelles sont vos options? Il y a plusieurs:
Vous pourriez abandonner et embrasser le chaos. Vous pouvez créer un site public pour les extensions, autoriser les utilisateurs à évaluer les extensions et publier/consulter des avis. De cette façon, si un développeur publie une extension de faible qualité qui est boguée ou plante, les utilisateurs qui le remarquent peuvent publier un avis négatif. (Bien sûr, si le développeur est malveillant et publie une extension malveillante, rien ne garantit que quiconque le remarquera jamais - si vous êtes chanceux, peut-être qu'un utilisateur remarquera le code malveillant d'une manière ou d'une autre et vous le signalera, mais c'est tout aussi probable que personne ne le remarquera jamais. C'est le risque que vous prenez.)
Ceci est connu comme ayant un système d'extension ouvert. Voir, par exemple, le marché Android Android ou Google Chrome Extension Gallery ou Userscripts.org (un site d'extension Greasemonkey)).
Vous pouvez mettre en place une sorte de système de révision, où les experts examinent chaque extension avant sa publication (ou peu de temps après sa publication) sur le site public de l'extension. Si vous souhaitez simplement détecter les problèmes de qualité, il peut être suffisant que les experts installent l'extension et la testent, et peut-être exécutent un outil de recherche de bogues de qualité du code pour rechercher les problèmes courants. Si vous souhaitez également détecter des extensions malveillantes, le réviseur devra être un développeur capable de lire le code et de lire l'extension ligne par ligne; c'est extrêmement fastidieux et long, mais il n'y a pas vraiment de meilleure option.
Ceci est connu comme ayant un système d'extension organisé. Voir, par exemple, le Apple iOS App Store ou le site d'extension Firefox (addons.mozilla.org) pour quelques exemples, bien que je pense qu'ils se concentrent uniquement sur la qualité du code et non sur la détection de la malveillance.
Quelle que soit l'approche que vous adoptez, les extensions servies à partir d'un site d'extension public unique, qui héberge la version faisant autorité de l'extension, présentent un avantage considérable. Vous souhaiterez peut-être prendre diverses mesures pour encourager les utilisateurs à installer des extensions à partir de ce site et les décourager d'installer des extensions à partir d'autres sites (par exemple, désactivez par défaut l'installation d'extensions à partir d'autres sources et demandez à l'utilisateur de cliquer pour autoriser tout autre domaine qu'il souhaite installer depuis, comme Firefox le fait). Quel est l'avantage? L'avantage est que cela garantit que tous vos utilisateurs obtiennent la même copie de l'extension. Il empêche les attaques, par exemple, lorsqu'un site Web malveillant utilise un script pour vérifier si la version du navigateur de l'utilisateur et d'où vient l'utilisateur, et sur cette base, décider de diffuser un code malveillant ou un code légitime - ce type d'attaques fait il est plus difficile de détecter la malveillance, donc les arrêter est une bonne chose. Il garantit également que les utilisateurs bénéficient des avis et des évaluations.
Vous devez également examiner attentivement les API exposées aux extensions et celles qui ne le sont pas. Vous pouvez envisager d'exposer uniquement un sous-ensemble de l'API aux extensions, de sorte que les extensions sont intrinsèquement limitées dans ce qu'elles peuvent faire, comme un moyen de limiter les dommages. Par exemple, le navigateur Chrome permet aux extensions d'interagir avec le DOM de la page Web et le site Web, mais les extensions ne sont pas autorisées à exécuter du code natif (par exemple, installer et exécuter un .exe). vous pouvez fournir une API de base qui évite les API les plus risquées, puis exiger toute extension nécessitant un accès à plus que l'API de base doit d'abord obtenir l'approbation des modérateurs avant de pouvoir être publiée sur le site public.
Une autre défense possible contre les extensions malveillantes consiste à introduire un système d'autorisation. Vous identifiez un ensemble d'autorisations. L'extension doit inclure un manifeste, qui spécifie l'ensemble d'autorisations dont il a besoin. Lorsque l'utilisateur installe l'autorisation, le système doit montrer à l'utilisateur l'ensemble des autorisations que l'extension demande et ce que ces autorisations impliquent (par exemple, quels risques de sécurité/confidentialité ils posent, quel accès ils accordent à l'extension), permettant à l'utilisateur de approuver les autorisations et poursuivre l'installation ou rejeter les autorisations et annuler l'installation. Cela donne aux utilisateurs plus de contrôle et de visibilité sur les extensions, réduit les risques d'extensions de bogues (car les conséquences d'une vulnérabilité de sécurité dans une extension sont désormais limitées aux seules autorisations demandées, et non à toutes les autorisations), et peuvent rendre les extensions malveillantes plus apparentes ( car ils doivent demander certaines autorisations pour faire du mal). Voir, par exemple, Android ou Google Chrome pour un exemple de ce genre de choses).
(N'essayez pas de déployer votre propre système d'assainissement. Étant donné la complexité de JavaScipt, l'assainissement fait maison serait probablement peu sûr. Utilisez une solution existante qui a déjà été bien vérifiée.)
Le compilateur Caja de Google est un outil de création de code HTML, CSS et JavaScript tiers sûr à intégrer dans votre site Web.
Si je me souviens bien, il a été utilisé pour iGoogle, car la simple séparation du code non approuvé en iframe
s comportait toujours des lacunes.
Je ne sais pas si cela peut être automatisé facilement, et je suis d'accord avec @ jfriend00 et @slhck quant à la difficulté générale de filtrer avec succès ces Javascripts. Cela étant dit, il existe au moins un outil que je connais qui tente de détecter les scripts malveillants.
Cet outil est Wepawet , qui est exploité par l'Université de Californie à Santa Barbara. Il est décrit ainsi:
Wepawet est un cadre d'analyse des menaces Web. Wepawet est en mesure de déterminer si la visite d'une page Web entraînerait une tentative de compromettre l'environnement du visiteur.
IBM Appscan dispose d'un module d'analyse de code statique appelé " JavaScript Security Analyzer (JSA) ". Ce n'est certainement PAS gratuit, mais il fournit des commentaires sur les implications de sécurité du code Javascript.
Mis à part le JSA, je ne connais aucun autre outil d'analyse de code statique pour rechercher des problèmes de sécurité, mais j'aimerais en savoir plus. Peut-être que si JLint/JHint a ajouté des fonctions de sécurité?