Dot.Blog

C#, XAML, Xamarin, UWP/Android/iOS

Silverlight et les accès cross domaines

[new:11/6/2010] Silverlight est d’une telle puissance qu’il pourrait servir à créer des codes malicieux redoutables, du fishing plus vrai que nature et autres désagréments. Microsoft a eu tellement peur que cela n’arrive qu’ils ont verrouillés de nombreuses possibilités du produit.

Parmi celles-ci notons l’interdiction de télécharger quoi que ce soit en dehors du domaine de provenance de l’application sauf si le serveur cible rend cet accès possible via un fichier de configuration.

La solution existe mais elle n’est pas toujours applicable, car si le serveur en question n’a pas prévu le fameux fichier de configuration et si vous n’avez aucun droit sur ce serveur, il n’existe tout simplement pas d’alternative simple. Même pour du contenu public, volontairement publié pour être accessible depuis n’importe où. De n’importe où mais pas d’une application Silverlight. Ainsi en a voulu Microsoft.

Il y a même un situation pire encore : votre Application doit accéder à des services hébergés sur un serveur qui n’est pas un serveur Web. Là, pas question de poser un fichier de configuration sur la “racine”, il n’y a pas de “racine” au sens web du terme et le serveur ne répondra de toute façon pas aux requêtes HTTP.

Un espoir pour le futur

J’en ai dernièrement parlé avec l’un des développeurs de l’équipe Silverlight qui s’occupe justement de la sécurité. Je lui ai suggéré qu’au moins la possibilité soit laissée de faire du cross domaine (sur un serveur non configuré) suite à un message de confirmation de l’utilisateur. Silverlight est déjà plein de messages de ce genre (pour passer en mode plein écran par exemple), un écran de confirmation pour autoriser le cross domaine serait vraiment un plus. Il a dit que ce n’était pas une mauvaise idée… Verrons-nous cette option dans SL 5 ? Peut-être… en tout cas j’ai glissé l’idée dans l’oreille de quelqu’un qui a le pouvoir de le faire.

Les plans B

Mais pour l’instant, ne rêvons pas. Sans fichier de configuration sur le serveur pas de solution. En fait si, il y a un plan B : écrire une application serveur qui joue le rôle d’un proxy pour toutes les requêtes cross-domaine. C’est tellement lourd que je ne considère pas cela comme une solution (d’autant que le proxy va devenir un goulot d’étranglement). Mais dans certains cas il n’y a pas d’autres choix.

De même, si votre application Silverlight doit appeler un service qui ne se trouve pas sur un serveur IIS il n’y a pas d’autres voies que de créer une application serveur de fichier de configuration. Silverlight essayera de télécharger la configuration cross-domaine sur le port 943, il “suffit” donc de répondre à cette demande. Une application Silverlight accédant à un service WCF sur une machine non serveur Web pourra donc le faire si vous ajoutez à coté des services un serveur de fichier de configuration de police d’accès. Mike Snow propose une implémentation d’un tel serveur, je vous renvoie ainsi vers son article “Full implementation od Silvelight Policy Server”.

L’explication du danger

imageRegarder le dessin ci-dessus. Prenons les opérations dans l’ordre :

  1. Albert est assis devant son PC. Il se connecte au Serveur A pour télécharger l’application Silverlight MonAppli.Xap.
  2. L’application MonAppli.Xap arrive sur le poste client de Albert et s’exécute. Il s’agit d’une application Web utilisée au travers d’un browser disposant de certains mécanismes comme par exemple les cookies. Le browser de Albert est installé sur la machine de Albert, c’est Albert qui est connecté à son propre PC avec tous ses crédits, dont ses cookies.
  3. L’application Silverlight essaye maintenant de télécharger le fichier X se trouvant sur le serveur B. Imaginons un fichier protégé contenant des informations secrètes que seul Albert et quelques autres privilégiés ont le droit de télécharger.
  4. La demande de téléchargement émanant du PC de Albert et Albert disposant déjà des droits (stockés dans des cookies) lui permettant d’accéder au fichier X, et la demande provenant du Browser de Albert qui est bien connecté à sa machine, le serveur B va penser que c’est Albert qui demande le fichier X. Il va l’envoyer. Et celui-ci sera reçu à l’insu d’Albert par l’application MonAppli.xap qui pourra par exemple le transmettre en douce au serveur A.

Albert vient de se faire dépouiller d’un fichier X ultra secret se trouvant sur le serveur B sans même le savoir !

C’est contre les attaques de ce type que Microsoft (et Adobe pour Flash) a prévu un filtrage strict. Celui-ci réclame que le Serveur B expose dans sa racine un fichier de configuration particulier autorisant explicitement le Serveur A (et ses applications, donc MonAppli.Xap) à accéder au fichier X.

Vous allez me dire que si X est si secret que ça, on se demande bien pourquoi la sécurité est si pauvre et ne repose que sur un cookie. On est d’accord. Mais quand je pose cette question à des gens mieux informés que moi en termes de sécurité on me répond “mais ce n’est pas la question”. Si ça l’est. C’est à mon sens au serveur d’être bien protégé et non à Silverlight de faire la police, mais bon c’est comme ça… Quoi ? Ah oui.. et si X n’est pas un fichier secret mais un truc banal que tout le monde peut télécharger ? J’ai posé la question bien entendu et on m’a parlé d’attaques bizarres autant qu’étranges dont j’ai oublié le nom après avoir vérifié qu’il s’agissait de trucs vraiment rares et très difficiles à réaliser. Bref, je suis navré de ne pas répondre de façon claire à tout cela, je n’ai jamais réussi à avoir de réponse claire moi non plus en dehors de jargon sécuritaire qui sent plutôt la paranoïa qu’autre chose. Les types qui font de la sécurité informatique doivent dormir avec un flingue sous l’oreiller je pense et doivent demander à leur femme de montrer sa carte d’identité avant d’ouvrir quand elle sonne à la porte… Le monde est une jungle, certes. Je suis trop resté soixante-huitard certainement :-) “Peace & Love” me plaisait quand même bien plus comme slogan que “vos papiers svp” !

Cross domain policy

Si vous avez accès au serveur, alors vous pourrez configurer le fameux fichier qui doit est être placé sur la racine du serveur. Pas celle de votre application mais bien la racine du serveur.

Silverlight accepte deux fichiers :

  • CrossDomain.xml
  • ClientAccessPolicy.xml

Le second est testé en premier. Une raison à cela : ClientAccessPolicy.xml est “le” fichier de configuration de police d’accès cross-domaine de Silveright. Il est naturellement téléchargé en premier. Mais Flash utilise une technique proche et les serveurs qui sont configurés pour Flash peuvent être utilisés par Silverlight sans modification… De fait si Silverlight ne voit pas son propre fichier de configuration il tente en seconde chance de télécharger CrossDomain.xml qui est le fichier de police cross-domaine pour Flash. Tout simplement.

Le format du fichier Flash est accessible sur le site Adobe : Cross-domain policy file specification. Bien entendu si vous avez accès au serveur et que vous avez le droit de placer un fichier xml dans sa racine, utilisez de préférence le format de fichier Silverlight plutôt que le format Adobe… D’abord parce que MS pourrait décider un jour de ne plus supporter cette astuce, et ensuite parce que le fichier Silverlight autorise une configuration plus fine.

ClientAccessPolicy.xml

La version la plus simple (qui autorise tout le monde à tout faire) est la suivante :

   1: <?xml version="1.0" encoding="utf-8"?> 
   2: <access-policy> 
   3:   <cross-domain-access> 
   4:     <policy> 
   5:       <allow-from http-request-headers="*"> 
   6:         <domain uri="*"/> 
   7:       </allow-from> 
   8:       <grant-to> 
   9:         <resource path="/" include-subpaths="true"/> 
  10:       </grant-to> 
  11:     </policy> 
  12:   </cross-domain-access> 
  13: </access-policy>

Peut-être que, comme moi, vous pensez que trop de sécurité tue la sécurité. Je suis convaincu que pour ne pas s’enquiquiner pleins de développeurs vont placer un fichier comme celui-ci sur leurs serveurs… Moralité c’est comme s’il n’y avait aucune sécurité. Tout ça pour ça…

Même si je sais que vous le ferez peut-être pas (à moins de gérer des données ultra sensibles), je vous conseille quand même d’éviter cette version “passoire” et de configurer plus finement les droits accordés par le fichier de police cross-domaine.

Pour plus de détail sur le format de ce fichier lisez la documentation MS “Mise à disposition d’un service au-delà des limites de domaine”.

 

 

Conclusion

On bougonne, on plaisante, mais en réalité un serveur connecté au Web est comme une brebis abandonnée seule la nuit en pleine forêt… Les loups rodent.

Avoir le fantasme d’un monde cool et fraternel est une chose, avoir le sens des réalités en est une autre.

Lorsque vous concevez des applications Silverlight qui doivent accéder à des données se trouvant sur une autre domaine c’est en tout cas une réalité bien rugueuse (un message d’erreur) qui vous rappellera que le monde n’est pas un grand Disney Land dans le cas où le serveur n’a pas explicitement autorisé cet accès par un fichier de police d’accès cross-domaine.

Autant le savoir et concevoir ses applications en fonction de cette réalité (et configurer ses serveurs correctement).

Stay Tuned !

blog comments powered by Disqus