Hello, Une solution reste possible pour toi, j'essaye de mieux expliquer.
La solution est celle du loader qui charge le swf en bytearray. Tu me dit que tu as déjà fait le test avec un embed. Effectivement le 'hacker' peu trouver l'information car le SWF embed est dans ton SWF. donc si je récupère le SWF , je décompile et je prend la partie data de ton embed et reconstruit un SWF avec. Par compte ma méthode pose un gros probleme au hacker. En effet, tu recoi (par amfphp ou php simple) le bytearray du swf stocker coté serveur (mais non récupérable car caché). Effectivement le hacker pourra toujours taper sur l'url pour récupéré le flux mais ca complique un peu plus ca démarche. De toute facon, désolé d'avoir une nouvelle négative, mais il n'y a aucune solution complettement bloquante avec flash. L'astuce reste de mettre plusieur palier (url du php crypter, qui ensuite charge un flash en bytearray, qui lui pourrai etre crypter avec une clef hexa d'un png charger a la volé...... ainsi de suite) En terme de sécurité, seule la méthode du découragement marche. Bon courage. Et si tu veux, envoi le résultat pour un test de sécurité :) ca me plait les défis :) Skat Le 30 septembre 2010 19:01, Gwenn Guihal <[email protected]> a écrit : > Hello, > > Donc déjà merci à Benjamin pour sa réponse. > On n'utilise pas AMF, mais simplement du xml pour les échanges > client/serveur. > Donc déjà pas mal de tes solutions ne sont malheureusement pas exploitables > ici. > J'avais déjà inclu dans un swf un autre swf contenant la clé lors de la > compilation (similaire à ta dernière solution), mais l'audit de sécurité du > client avait réussi à choper la clé publique : > > [Embed (source = "../cryptkey.swf", mimeType = "application/octet-stream")] > private var MyClass:Class; > > Donc pour zwetan (et les autre) je m'explique mieux. > > Ce que je veux en effet, c'est qu'entre A(Client) et B(Server), C ne puisse > pas comprendre ce que A envoie à B et ne puisse pas non plus, le renvoyer > (validité). > Pour ça j'imaginais que B envoie à A un token avec un délai d'expiration et > A doit bien entendu le renvoyer. Cependant, pendant ce laps de temps, C peut > très bien envoyé ce qu'il veut. > > Donc à ce moment là, je pensais tout simplement crypter les échanges de A à > B mais aussi de B à A. > Comme ça, si C arrive à intercepter le token, il sera crypté et donc ne > pourra pas rien en faire. En plus, une fois que A a renvoyé son score (par > exemple) avec le token, ce même token expire donc si C renvoie le même > message, ce dernier sera rejeté. > > Alors dites moi si j'ai faux pour le moment ? > > Par contre, concernant le cryptage c'est là que le bas blesse. Un SWF peut > facilement se décompiler et donc la clé publique sera visible. Je n'ai pas > envie d'obfusquer mon code, trop lourd à faire et j'ai eu de mauvaises > surprises (des erreurs au runtime). > > Donc voilà, je me demande qu'elles sont vos solutions pour ce type de > problème ? > > Merci, > > Gwenn > > > > > Le 30 septembre 2010 18:08, zwetan <[email protected]> a écrit : > > alors avant de répondre je vais demander ce que tu cherches a >> sécuriser ? >> >> - juste les échange de données ? >> >> cad si A envoie un message à B, tu ne veux pas que C puisse >> comprendre le message ? >> >> - le swf lui-meme ? >> cad tu ne veux pas que qlqn puisse voir le code qu'il y a dans le >> SWF ? >> >> - la validité du message envoyé au serveur ? >> cad si A envoie un message a B, tu ne veux pas que C puisse >> répliquer le message et/ou se fasse passer pour B ? >> >> - l'authencité ? >> cad si A dit à B qu'il est "A", tu veux pouvoir verifier que c'est >> bien le cas ? >> >> etc. >> >> idéalement, plutot que de rester dans le vague et de s'amuser au >> telephone arabe, >> il a a dit que l'autre a dit que un autre lui avait dit que c'est ca >> qu'il faut sécuriser, >> ce serait plus simple que tu décrive ce que tu cherches a sécuriser >> concretement >> >> l'envoie d'un score de jeu vers le serveur ? >> la sauvegarde d'un password pour recup des données ? >> la code source du client SWF ? >> etc. >> >> dans ce que tu as mis au dessus: >> >> si tu utilises du PKI, bah la clef publique est justement là pour etre >> publique >> donc obfusquer le SWF ca ne sert a rien, >> cela indique aussi que tu veux proteger le contenu du message du >> client vers le serveur, >> donc en soit si qlqn decompile le SWF idem on s en fout aussi. >> >> bref, ce que tu cherches a protéger n'est pas tres clair >> >> zwetan >> >> -- >> Vous recevez ce message, car vous êtes abonné au groupe Google >> Groupes FCNG. >> Pour envoyer un message à ce groupe, adressez un e-mail à >> [email protected]. >> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse >> [email protected] <fcng%[email protected]>. >> Pour plus d'options, consultez la page de ce groupe : >> http://groups.google.com/group/fcng?hl=fr >> >> > -- > Vous recevez ce message, car vous êtes abonné au groupe Google > Groupes FCNG. > Pour envoyer un message à ce groupe, adressez un e-mail à > [email protected]. > Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse > [email protected] <fcng%[email protected]>. > Pour plus d'options, consultez la page de ce groupe : > http://groups.google.com/group/fcng?hl=fr > -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes FCNG. Pour envoyer un message à ce groupe, adressez un e-mail à [email protected]. Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse [email protected]. Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/fcng?hl=fr
