Sécurité et hébergement un contrôle Windows Form dans Internet Explorer

10. mars 2008

Internet Explorer permet d'encapsuler dans une page web un contrôle Windows Forms (comme par exemple le contrôle web de Nova).

C'est une technologie très sympa mais qui rencontre un gros problème de sécurité. En effet, le contrôle est hébergé dans la sandbox d'Internet Explorer et donc reçoit des droits restreints (en l'occurence ceux de la zone Internet/Intranet).

Pour permettre que le contrôle accède à plus de droits, la seule solution consisterait via caspol à lui affecter des permissions supplémentaires. Par exemple, nous pourrions affecter un joli FullTrust à notre contrôle en nous basant sur son strong name.

Je dis "nous pourrions" car malgré tous nos efforts cela pourrait ne pas suffir.En effet, lors de la création de la sandbox (un AppDomain) qui hébergera votre contrôle, Internet Explorer ne connait pas encore les preuves (evidences) qui affecteront les permissions à votre contrôle (puisque ce dernier n'est pas encore chargé). De ce fait, la sandbox reçoit les permissions issues de la zone et de l'url.

Une fois le contrôle construit il recevra ses droits et donc potentiellement le FullTrust. Toutefois, si du code effectue un PermissionSet.Demand (par exemple SecurityPermission.Demand()), l'appel échouera.

Il échouera car lorsque de la remontée de la pile d'appel, le service de sécurité finira par arriver au niveau de l'AppDomain qui ne dispose que de droits restreints.

Une solution existe cependant: il suffit que chaque appel à du code qui effectue des PermissionSet.Demand() effectue un PermissionSet.Assert() afin que le parcours de la pile d'appel (Stack Walk) ne remonte jamais jusqu'à l'AppDomain mais reste cantonné à notre contrôle.

.Net, Sécurité