[Sécurité]RIA de confiance

Version imprimable

18/01/2011, 17h03
Nisnor

[Sécurité]RIA de confiance

Bonjour à vous,

J'ai passé ma journée à chercher comment faire...Mais je n'ai rien trouvé (en recherche française et pas plus en recherche anglaise) d'autre que "C'est pas possible".

Je cherche à développer une application Silverlight 4 communiquant avec un serveur via une communication chiffrée. WCF ne permettant pas l'utilisation d'autre binding que l'HTTP avec Silverlight, cette méthode n'était pas correcte.

J'ai donc pensé à utiliser directement l'API SSPI de Microsoft qui nécessite donc quelques PInvoke (aucun élément dans le framework Silverlight ne permettant d'accéder à ce que je voulais) pour chiffrer mes communications en utilisant TLS.

Très rapidement, je suis tombé sur le problème de sécurité des applications Silverlight : Code transparent, critique, etc... Et bien entendu, tout le code nécessaire à la réalisation d'un PInvoke est marqué en sécurité critique.

Ma question (simple) est : Est-il possible de faire, moyennant la signature ou je ne sais quoi, une application de confiance totale en Silverlight?

Etant donné que ceci est possible avec les applets Java (Une popup apparait au chargement de l'applet, demandant à l'utilisateur s'il fait confiance à l'application), j'ai énormément de mal à accepter que Microsoft aie fait une technologie aussi bridée sur ce point là...

Si quelqu'un a une solution miracle à ce problème...Ce serait absolument fabuleux :calim2:

Merci d'avance
18/01/2011, 17h38
Thomas Lebrun

Pkoi pas du SSL, tout simplement ?
18/01/2011, 21h04
Nathanael Marchand

Citation:

Envoyé par Nisnor

Bonjour à vous,

J'ai passé ma journée à chercher comment faire...Mais je n'ai rien trouvé (en recherche française et pas plus en recherche anglaise) d'autre que "C'est pas possible".

Je cherche à développer une application Silverlight 4 communiquant avec un serveur via une communication chiffrée. WCF ne permettant pas l'utilisation d'autre binding que l'HTTP avec Silverlight, cette méthode n'était pas correcte.

J'ai donc pensé à utiliser directement l'API SSPI de Microsoft qui nécessite donc quelques PInvoke (aucun élément dans le framework Silverlight ne permettant d'accéder à ce que je voulais) pour chiffrer mes communications en utilisant TLS.

Très rapidement, je suis tombé sur le problème de sécurité des applications Silverlight : Code transparent, critique, etc... Et bien entendu, tout le code nécessaire à la réalisation d'un PInvoke est marqué en sécurité critique.

Ma question (simple) est : Est-il possible de faire, moyennant la signature ou je ne sais quoi, une application de confiance totale en Silverlight?

Etant donné que ceci est possible avec les applets Java (Une popup apparait au chargement de l'applet, demandant à l'utilisateur s'il fait confiance à l'application), j'ai énormément de mal à accepter que Microsoft aie fait une technologie aussi bridée sur ce point là...

Si quelqu'un a une solution miracle à ce problème...Ce serait absolument fabuleux :calim2:

Merci d'avance

Bigre! La communication en tcp indiquée ici: http://msdn.microsoft.com/fr-fr/library/ee806416.aspx n'existerait donc pas?;)

De plus je vois pas pourquoi une solution SSL ne suffirait pas non plus?

Pour répondre à la question: si P/Invoke est possible! En Silverlight 5 :D (si mes souvenirs sont bons)
24/01/2011, 12h26
Nisnor

Bonjour,

Désolé d'avoir laissé couler le topic XD...Et merci pour vos réponses.

On m'a envoyé un lien traitant du PollingDuplexBinding WCF (que je ne connaissais pas du tout)...Je vais chercher là dessus.

Sur le TcpBinding, peut-être était-ce des articles vieillot...Mais j'avais retenu que seul le HttpBinding était disponible. Je suis p'tet dingue XD...Mais si j'ai retenu ça, c'est qu'à un moment ou à un autre, j'ai voulu me servir d'un TcpBinding sur du Silverlight et que ça marchait pas. Je devais communiquer avec l'adresse ayant distribué l'appli Silverlight...Du coup, si j'ai bien compris, une reconfiguration des domaines accessibles dans le "fichier-magique" (je sais plus comment il s'appelle) n'était pas nécessaire...Si?

Bref...L'aspect communication est résolu (je garde la doc sur le bind Tcp Silverlight, ça peut toujours servir :D).

Je me confronte à un nouveau problème, toujours lié à la sécurité : L'invocation de méthode privée ou protégée par reflection...

J'ai vu que j'aurais de plus grandes chances de pouvoir faire un code de sécurité critique de confiance qu'un code de sécurité critique...Si vous avez des liens indiquant comment faire, j'suis toujours preneur ^^
24/01/2011, 14h58
Nathanael Marchand

Citation:

Envoyé par Nisnor

Je me confronte à un nouveau problème, toujours lié à la sécurité : L'invocation de méthode privée ou protégée par reflection...

Des webservices qui exposent des méthodes privés? 8O
24/01/2011, 16h06
Nisnor

Non non, plus aucun rapport avec la communication réseau; là c'est purement côté client.

J'ai bataillé quelques temps pour faire fonctionner un gestionnaire d'évènements que j'avais déjà fait pour WPF et qui marche très bien. Evidemment, vu que silverlight est (abusivement?) blindé de sécurité sans réel moyen de les contourner (moyennant une action de l'utilisateur, comme pour les applets Java), j'ai dû adapter le code avec des trucs qui me plaisent pas (passage de certaines méthode en public notamment).

Ce gestionnaire dynamique fonctionne...Mais dès qu'il s'agit d'aller exécuter la méthode demandée, j'ai de nouveau droit à une exception qui me dit que j'ai pas accès à ma méthode. Pourtant, le code tentant d'appeler la méthode par reflection se trouve dans la même instance que la méthode à appeler. Les méthodes ciblées en private, protected ou internal ne sont pas accessible...Il n'y a que les public qui marchent (et ça me fait encore grincer des dents; ces méthodes n'ont pas à être publiques :s ...Elles le sont uniquement à cause des restrictions de sécurité!)

J'ai vu un billet dans lequel l'auteur aurait réussit à appeler une méthode privée en passant par un délégué. J'ai testé : Ca ne marche pas mieux, toujours pour les mêmes raisons => Créer le délégué pointant vers une méthode publique, ça marche, mais dès que ça sort du public, exception!

Y'a de quoi devenir fou... :evilred:
24/01/2011, 17h42
Nathanael Marchand

Citation:

Envoyé par Nisnor

Non non, plus aucun rapport avec la communication réseau; là c'est purement côté client.

J'ai bataillé quelques temps pour faire fonctionner un gestionnaire d'évènements que j'avais déjà fait pour WPF et qui marche très bien. Evidemment, vu que silverlight est (abusivement?) blindé de sécurité sans réel moyen de les contourner (moyennant une action de l'utilisateur, comme pour les applets Java), j'ai dû adapter le code avec des trucs qui me plaisent pas (passage de certaines méthode en public notamment).

Ce gestionnaire dynamique fonctionne...Mais dès qu'il s'agit d'aller exécuter la méthode demandée, j'ai de nouveau droit à une exception qui me dit que j'ai pas accès à ma méthode. Pourtant, le code tentant d'appeler la méthode par reflection se trouve dans la même instance que la méthode à appeler. Les méthodes ciblées en private, protected ou internal ne sont pas accessible...Il n'y a que les public qui marchent (et ça me fait encore grincer des dents; ces méthodes n'ont pas à être publiques :s ...Elles le sont uniquement à cause des restrictions de sécurité!)

J'ai vu un billet dans lequel l'auteur aurait réussit à appeler une méthode privée en passant par un délégué. J'ai testé : Ca ne marche pas mieux, toujours pour les mêmes raisons => Créer le délégué pointant vers une méthode publique, ça marche, mais dès que ça sort du public, exception!

Y'a de quoi devenir fou... :evilred:

J'ai quand même du mal à saisir ta logique de conception la :?
24/01/2011, 18h16
Nisnor

C'est une archi MVVM modifiée. Le truc qui me plait pas dans MVVM, c'est la gestion des évènements. Du coup, j'ai fais un système à ma sauce pour contourner le modèle de gestion des évènements en MVVM (J'ai p'tet pas assez cherché aussi...J'me suis arrêté aux propriétés "Command" qu'on vient binder sur une propriété du ViewModel qui contient l'action à effectuer)

Ce qui me gène dans l'histoire, c'est de devoir mettre en public toutes les méthodes qui vont réagir aux évènements de la vue...

Citation:

Envoyé par Nisnor

Ce qui me gène dans l'histoire, c'est de devoir mettre en public toutes les méthodes qui vont réagir aux évènements de la vue...

Ton ICommand est public oui mais les méthodes qu'il invoque elles sont privées.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 public class MonViewModel { public ICommand MaCommande {get{return _maCommande;}} private DelegateCommand _maCommande; public MonViewModel() { _maCommande = new DelegateCommand(MaFonction); } private void MaFonction() { } }
Cet exemple utiliser DelegateCommand du framework PRISM (marche aussi avec RelayCommand d'autres frameworks)

Comme je dis souvent:
Faut savoir prendre du recul, si avec des outils qui sont censés repondre à tes besoins t'es obligé de faire une manip incroyable pour que ca marche, c'est que t'as ptet louper une subtilité quelque part :D