Je veux permettre à l'utilisateur contribué à JavaScript dans les zones de mon site Web.
merci
8 Réponses :
Je pense que la bonne réponse est 1.
Dès que vous autorisez JavaScript, vous ouvrez vous-même et vos utilisateurs à toutes sortes de problèmes. Il n'y a pas de moyen idéal pour nettoyer JavaScript et que les personnes comme l'armée Troll vont le prendre comme une mission personnelle de vous gâter.
Au lieu de vérifier que des choses diaboliques telles que le script inclut, j'irais pour que la liste blanche des rares commandes à la réégalité des rares commandes vous attendez à être utilisée. Ensuite, impliquez un humain à autoriser et ajoutez de nouvelles commandes acceptables à la Whitelist.
Pensez à toutes les choses
Jetez un coup d'œil à Google Caja :
CAJA permet aux sites Web d'intégrer en toute sécurité les applications Web DHTML à partir de tiers et permet une interaction riche entre la page d'intégration et les applications incorporées. Il utilise un modèle de sécurité d'objet-capacité permettant une large gamme de stratégies de sécurité flexibles, de sorte que la page contenant puisse contrôler efficacement les applications intégrées des données d'utilisateur et permettre aux gadgets de prévenir les interférences entre les éléments UI de Gadgets.
Il pourrait être plus sûr de concevoir / mettre en œuvre votre propre langage de script restreint, qui peut être très similaire à JavaScript, mais sous le contrôle de votre propre interprète.
Connaissez-vous des projets open source qui pourraient déjà faire cela?
1. Est-ce complètement fou?
Ne le pense pas, mais près. Voyons.
2. Y a-t-il des scripts de désinfectant JavaScript ou de bons modèles de regex pour numériser pour les alertes, les iframes, le script à distance et d'autres javascript malveillants?
Ouais, au moins il y a Google Caja et Adsafe Pour assainir le code, ce qui lui permet d'être
Sandboxed . Je ne sais pas jusqu'à quel degré de confiance qu'ils fournissent, cependant. 3. Si ce processus est autorisé manuellement (par un contrôle humain de la vérification du JavaScript)?
Il peut être possible que Sandbox échoue, ce serait donc une solution sensible, en fonction du risque et du compromis d'être attaqué par un code malveillant (ou défectueux).
4. Serait-il plus judicieux de permettre aux utilisateurs d'utiliser uniquement un cadre (comme JQuery) plutôt que de leur donner accès à JavaScript réel? De cette façon, il pourrait être plus facile de surveiller.
JQuery est tout simplement javascript, donc si vous essayez de vous protéger des attaques, cela ne vous aidera pas du tout.
S'il est crucial d'empêcher ce type d'attaque, vous pouvez implémenter une langue personnalisée, analyser dans le backend et produire le JavaScript contrôlé et sûr; Ou vous pouvez envisager une autre stratégie, comme fournir une API et y accéder à partir d'une composante tierce partie de votre application.
l'hébergez sur un autre domaine. La même politique de sécurité d'origine dans les navigateurs empêchera ensuite les JS soumis par l'utilisateur d'attaquer votre site.
Il ne suffit pas de l'héberger sur un sous-domaine différent, car les sous-domaines peuvent définir des cookies sur un domaine de niveau supérieur, ce qui pourrait être utilisé pour les attaques de fixation de session.
Que voulez-vous permettre à vos utilisateurs de faire?
Créer leurs propres widgets, réorganiser ou masquer les éléments de la page à leur goût, etc.
Si tel est ce que les utilisateurs vont faire avec le JavaScript, vous pourriez également simplement leur fournir la fonctionnalité de votre propre code, les préférences de l'utilisateur, qu'ils basculent dans le compte de leur compte. Vous pouvez leur fournir un endroit pour ajouter un widget que vous validez, puis fournissez les widgets sonores au reste de la communauté.