Si j'ai des champs qui ne seront jamais affichés que jamais à l'utilisateur qui les entre dans l'entre eux, y a-t-il une raison pour les assainir contre les scripts croisés?
EDIT: le consensus est donc clair que cela devrait être désinfecté. Ce que j'essaie de comprendre, c'est pourquoi? Si le seul utilisateur qui puisse jamais voir le script, ils insérer sur le site sont l'utilisateur lui-même, la seule chose qu'il peut faire est d'exécuter le script lui-même, qu'il pouvait déjà faire sans que mon site soit impliqué. Quel est le vecteur de la menace ici?
5 Réponses :
oui , toujours assainir la saisie de l'utilisateur:
Le point clé étant
Juste parce que vous n'ayez pas un champ à quelqu'un, cela ne signifie pas qu'un chapeau noir potentiel ne sait pas qu'ils sont là. Si vous avez un vecteur d'attaque potentiel dans votre système, branchez le trou. Il va être vraiment difficile d'expliquer à votre employeur pourquoi vous n'avez pas eu si jamais exploité.
Si le script ou le service, que le formulaire soumet que les valeurs sont disponibles via Internet, puis n'importe qui, n'importe où, peut écrire un script qui lui soumettra des valeurs. Donc: Le modèle le plus élémentaire de la sécurité Web est assez simple:
Ne faites pas confiance à vos utilisateurs
Il vaut également la peine de lier à ma réponse dans une autre post ( Savvie de sécurité Web. '"> Étapes pour devenir Savvy Web-Security ): Étapes pour devenir Security Web Savvy .
Je ne peux pas croire avoir répondu sans faire référence à la question du titre:
Y a-t-il une raison pour assainir la saisie de l'utilisateur pour les empêcher de croiser le script de site?
Vous êtes pas empêcher le script l'utilisateur , vous protégeez votre site (ou, plus important encore, vous êtes client site) de la victime de scripts de cross-site. Si vous ne fermez pas les trous de sécurité connus, car vous ne pouviez pas être dérangé, il deviendra très difficile d'obtenir une entreprise de répétition. Ou bonne publicité de bouche à oreille et recommandation des clients précédents.
Pensez-y moins que de protéger votre client, pensez-y - si cela aide - comme
théoriquement: non. Si vous êtes sûr que seuls ils verront jamais cette page, alors laissez-les script tout ce qu'ils veulent.
Le problème est qu'il y a beaucoup de façons dont ils peuvent rendre les autres personnes de voir cette page, des moyens de ne pas contrôler. Ils pourraient même ouvrir la page sur un ordinateur de collègue et leur avoir regardé. C'est indéniablement un vecteur d'attaque supplémentaire.
Exemple: une pâte-tabine sans stockage persistant; Vous postez, vous obtenez le résultat, c'est tout. Un script peut être inséré que peu de temps ajoute un bouton "DONATED" pour créer un lien vers votre compte PayPal. Mettez-le sur l'ordinateur suffisamment de personnes, espérons que quelqu'un donne un don, ...
Je conviens que ce n'est pas le plus choquant et réaliste des exemples. Cependant, une fois que vous devez défendre une décision liée à la sécurité avec «cela est possible, mais cela ne semble pas trop mauvais», vous savez que vous avez traversé une certaine ligne.
Sinon, je ne suis pas d'accord avec les réponses telles que "Ne jamais faire confiance à l'utilisateur de l'utilisateur". Cette déclaration n'a pas de sens sans contexte. Le point est de définir la saisie de l'utilisateur, qui était la question complète. Trust comment, sémantiquement? Syntaxiquement? À quel niveau; Taille juste? Bon html?
Sous-ensemble de caractères unicode? La réponse dépend de la situation. Un serveur Web nue "ne fait pas confiance à l'utilisateur de l'utilisateur" mais de nombreux sites sont piratés aujourd'hui, car les limites de "entrée utilisateur" dépendent de votre perspective.
En bas de la ligne: évitez de laisser toute influence de votre produit sur votre produit à moins qu'il ne soit clair à un consommateur somnolent et non technique quoi et qui.
Cela règle presque tous les JS et HTML de la gobing.
P.s.: À mon avis, l'OP mérite le crédit de poser cette question en premier lieu. "Ne faites pas confiance à vos utilisateurs" n'est pas la règle d'or du développement de logiciels. C'est une mauvaise règle de base car il est trop destructeur; Il nuit aux subtilités dans la définition de la frontière d'interaction acceptable entre votre produit et le monde extérieur. Cela ressemble à la fin d'un brainstorming, alors qu'il devrait commencer une.
Sur son noyau, le développement de logiciels consiste à créer une interface claire vers et depuis votre application. Tout dans cette interface est la mise en œuvre, tout en dehors de celle-ci est la sécurité. Faire un programme Faites ce que vous voulez que cela soit si préoccupant facile oublie de ne rien faire d'autre.
Image de l'application Vous essayez de construire comme une photo magnifique ou une photo. Avec des logiciels, vous essayez d'approximer cette image. Vous utilisez une spécification comme esquisse, donc déjà ici, plus votre Specy Spec, plus votre croquis floue. Le contour de votre application idéale est un rasoir mince, cependant! Vous essayez de recréer cette image avec du code. Soigneusement vous remplissez le contour de votre croquis. Au noyau, c'est facile. Utilisez des pinceaux larges: croquis de flou ou non, cette partie doit clairement avoir une coloration. Sur les bords, il devient plus subtil. C'est à ce moment que vous réalisez que votre croquis n'est pas parfait. Si vous allez trop loin, votre programme commence à faire des choses que vous ne le souhaitez pas, et certaines de celles-ci pourraient être très mauvaises.
Lorsque vous voyez une ligne floue, vous pouvez faire deux choses: regardez plus près de votre image idéale et essayez de raffiner votre croquis ou d'arrêter de colorer. Si vous faites ce dernier, chances que vous n'irez pas trop loin. Mais vous ne ferez également qu'une approximation approximative de votre programme idéal, au mieux. Et vous pouvez toujours traverser accidentellement la ligne de toute façon! Simplement parce que vous n'êtes pas sûr de l'endroit où il se trouve.
Vous avez ma bénédiction en regardant plus près de cette ligne floue et essayez de le redéfinir. Plus vous arrivez au bord, plus vous êtes certain où il est, et moins vous êtes susceptible de le traverser.
Quoi qu'il en soit, à mon avis, cette question n'était pas une de sécurité, mais une des conceptions: quelles sont les limites de votre application et comment votre implémentation les reflète-t-elle?
Si "Ne faites jamais confiance à l'utilisateur de l'utilisateur" est la réponse, votre croquis est floue.
(Et si vous n'êtes pas d'accord: que si OP fonctionne pour "testxsshere.com"? boom! check-mate.)
(quelqu'un devrait enregistrer testxsshere.com)
Je ne crois pas que cette question ait été entièrement répondue. Il veut voir une attaque d'ACCUALL XSS si l'utilisateur ne peut s'attaquer que lui-même. Ceci est effectivement effectué par une combinaison de CSRF et de XSS.
Avec CSRF, vous pouvez faire une demande avec votre charge utile. Donc, si un utilisateur peut s'attaquer à l'aide de XSS, vous pouvez le faire attaquer lui-même (faites-la faire une demande avec votre XSS).
Un devis de L'application Web Manuel de Hacker's :
Mythe commun:
"Nous ne sommes pas inquiets pour ce bogue XSS à faible risque. Un utilisateur pourrait l'exploiter uniquement pour s'attaquer. "
Peut-être des vulnérabilités apparemment à faible risque peuvent, dans les mêmes circonstances, ouvrir la voie à une attaque dévastatrice. Prendre une approche de la sécurité en matière de défense en matière de sécurité implique la suppression de chaque vulnérabilité connue, mais insignifiante peut sembler. Les auteurs ont même utilisé des XSS pour placer des dialogues de navigateur de fichiers ou des contrôles ActiveX dans la réponse de la page, permettant de sortir d'un système en mode kiosque lié à une application Web cible. Supposons toujours qu'un attaquant sera plus imaginatif que vous pour concevoir des moyens d'exploiter des bugs mineurs!