Envoi en POST et sécurité...c'est fiable?

Salut TLM,

ce matin j'me suis posé une question...on envoit des variables en POST pour éviter qu'elles n'apparaissent dans l'URL et éviter qu'on puisse les modifier. Mais on peut très bien décompiler mon animation et récupérer le nom des différentes variables que je passe en POST, non?

Votre avis là-dessus?

@+! Samy

réponse : oui ,on peut !

Peg'

De retour de vacances?

M'en doutais que c'était possible! lol

la question était plutôt dans ma dernière phrase: "Votre avis là-dessus"

Comment on peut contourner le fait qu'on puisse décompiler et accéder aux variables envoyées en POST à partir de Flash?


J'avais pensé à qqch comme: j'envois une variable à un script ASP, et celui-ci redirige vers une page en envoyant les bonnes variables en POST...là ça doit pas être accessible...mais pas un peu tordue comme solution? Mais bon, faudrait un maximum de sécurité quand même: c'est pour transmettre des infos de paiement (objet, quantité, prix)

@+! Samy

salut samy
content de pouvoir te repondre sur autre chose que du café :)
il existe sur le marché plusieur soft permentant d'encodé les swf. Ils fonctionnent tjs aussi bien après, mais j'ai tester avec plusieur décompileur swf, ce que j'avais encodés été illisibles.
J'ai retrouver sur mon DD un certain FlashInCrypt qui devais être le fameux encryteur swf mais y'en a plein d'autres...
++

Flash sans Limites
_Benjy

lol

Ok, mais je reste sceptique et hésite à transmettre ces données à partir de Flash (bien que le nombre de personnes qui puissent espérer falsifier des commandes soit limité, ça m'embêterait un p'tit peu que ça se produise! lol

Bref, vais p't'être me diriger vers un formulaire HTML classique avec des variables HIDDEN (c'est fiable au moins ça?)

Sinon, on peut p't'être se pencher sur la question de la relation Flash-Paypal (c'est pour ça toutes mes questions!), car pour l'instant j'ai trouvé aucune doc en français (valable) et l'anglais, ça me gonfle (3 jours que j'en lis). Seuls sites intéressants: paypaldev.org et le paypal developpers center (où on peut tester ses formulaires, boutons, caddies...)

@+! Samy

heuu hidden en html c juste pour ne pas voir le champ dans le formulaire, on l'intercepte aussi bien que les autres... et ca n'a riena  avoir avec la transmission post ou get.

question pour ton paypal, t'envois directement depuis flash a paypal, ou t'as un php entre les 2 ?
car si t'as un php entre les 2, j'ai une petite class d'encryption de data en Fash (refaissable facilement en php) qui pourrait te permettre de bien faire chier ce qui veullent te hacké ton appli...

ps : les encrypteur swf c plutot efficaces...

Flash sans Limites
_Benjy

Parce qu'en HTML non plus c'est pas sécurisé?

Qu'est-ce que tu penses de ma solution? envoyer une variable à une page ASP (ex: produit=1) le script serveur va alors rediriger vers paypal (avec produit=crème solaire prix=20 devise=EUR...) sauf que je sais pas encore comment on fait ça! lol

Pour ta classe d'encryptage, ça crypte quoi? le code source ou les données saisies dans un formulaire Flash? Car pour moi j'aurais 5-6 boutons à faire qui redirigeraient chacun vers une page Paypal différente, donc tous les paramètres seraient fixes et déjà inclus dans la source et transmis ensuite en POST...d'où mon interrogation si je dois pas mettre ces paramètres dans un script serveur.

J'ai encore jamais crypté des trucs (suis p-ê trop parano d'un coup alors)...ça me gonfle ce truc...ça me coupe dans ma lancée...vais finir par acheter un serveur HTTPS et faire toutes les transactions sur mon site! lol

@+! Samy

J'ai déjà une base de données, j'avais prévu de rajouter une table produits et une table transactions (pour faire les vérifications par la suite), maintenant c'est vrai que pour 5-6 produits je pourrais le faire en dur. Les données devraient pas trop changer et puis c'est pas dur à changer 5-6 valeurs.

Y'a le prix surtout, mais la quantité, la devise aussi! et puis suis sûr que y'aura toujours un p'tit malin qui trouverait autre chose, bref reste plus qu'à mettre en pratique, et ensuite passage à l'étape suivante: RECUPERER les variables de la transaction et faire le script de traitement ... sacré bordel en perspective! lol

@+! Samy

PS: ah oui, ta classe de cryptage ne m'aurait pas servi pour l'occasion