Forums Développement Multimédia

Aller au contenu

Injections Mysql

CODE

22 réponses à ce sujet

#1 draad

  • Members
  • PipPipPipPipPipPipPipPip
  • 654 messages

Posté 16 November 2011 - 22:23 PM

Bonjour tout le monde !


Pour la sécurité de mon application, je souhaiterais empecher l'utilisateur d'entrer certains caractères dans les champs qui communiquent avec le php et les bases de données, tous les caratères spéciaux en fait : $,#,",',etc...

J'ai d'abord pensé a utiliser un event de type "Key Up" pour vérifier a chaque nouvelle entrée si le nouveau caractère fais partie de la liste des exclus, mais ca me semble sortir les grands moyens pour pas grand chose, alors avant de tout écrire, je me demandais s'il existait une fonction prédéfinie pour bloquer certaines touches du clavier.

J'ai de même un peu lu sur les "injection mysql", et je me demandais si cekla n'etais possible que par le biais de mon jeu ou si des utilisateurs mal intentionnés pouvaient communiquer avec mes script grâce a leur propres script, ou s'il pouvaient "intercepter" les communications en mes php et ma base de donnée.

#2 Logic

  • Honoris
  • PipPipPipPipPipPipPipPip
  • 2733 messages

Posté 16 November 2011 - 23:40 PM

Voir le messagedraad, le 16 November 2011 - 22:23 PM, dit :

je me demandais s'il existait une fonction prédéfinie pour bloquer certaines touches du clavier.

Oui. Cherche la propriété "restrict" sur les TextField.




Voir le messagedraad, le 16 November 2011 - 22:23 PM, dit :

J'ai de même un peu lu sur les "injection mysql", et je me demandais si cekla n'etais possible que par le biais de mon jeu ou si des utilisateurs mal intentionnés pouvaient communiquer avec mes script grâce a leur propres script, ou s'il pouvaient "intercepter" les communications en mes php et ma base de donnée.


Oui ils peuvent. Avec des outils comme FireBug ou Charles on peut examiner toutes les requêtes qui passent.

http://www.charlesproxy.com/

On peut donc refaire assez facilement un nouveau flash qui mime les requêtes de ton jeu, en y joignant des valeurs de paramètres vicieusement choisis (super score, log+pass bidon...). Si ton jeu n'est pas un minimum sécu, je peux par exemple te claquer ta base de données: je fais une moulinette qui t'inscrit 10000000 joueurs fictifs. Ou bien je me donne un score à 999999999 et je mets ceux des autres joueurs à 0. Ou pire, je trouve une injection SQL qui delete tout...

Pour la sécu en Flash, on va dire que c'est un peu du bricolage mêlé à de la magie vaudou. En tout cas je connais peu de gens qui donnent leur recette. Parce qu'une astuce de sécu dévoilée est une astuce de sécu inefficace.

#3 draad

  • Members
  • PipPipPipPipPipPipPipPip
  • 654 messages

Posté 17 November 2011 - 00:18 AM

Merci pour le "restrict", j'vais aller voir ça :)


Citation

Pour la sécu en Flash, on va dire que c'est un peu du bricolage mêlé à de la magie vaudou. En tout cas je connais peu de gens qui donnent leur recette. Parce qu'une astuce de sécu dévoilée est une astuce de sécu inefficace.


D'accord je vois ^^ Bon j'vais essayer d'imaginer un système de protection mais j'avoue ne pas trop savoir comment m'y prendre ...

#4 deuxsucres

    Ceinture Marron

  • Members
  • PipPipPipPipPipPip
  • 115 messages

Posté 17 November 2011 - 08:56 AM

Vu qu'il est possible d'imiter les requêtes du flash vers le serveur, ça ne sert à rien de protéger coté Flash. La protection contre le SQL injection ne peut être efficace que si elle est positionnée coté serveur. Bien entendu, il est préférable de s'assurer que les données sont bien formées également dans le Flash afin d'éviter des requêtes inutiles.

Pour se protéger du SQL injection, il faut s'assurer que, pour toute requête SQL, chaque donnée soit au bon format, qu'elle soit cotée correctement et que les caractères de contrôle SQL soient bien échappés (notamment les apostrophes).

Ensuite, pour ce que te dis Logic à savoir se mettre un super score et créer pleins d'utilisateurs... c'est à toi de trouver un moyen coté serveur de t'assurer que la requête provient bien de ton Flash avant de valider une opération.

Dans les grandes lignes, l'idée est d'ajouter un code dans les données transmises par Flash au serveur. Le serveur vérifie la présence et la validité de ce code. Le code est bon, l'opération est validée. Le code n'est pas bon, l'opération est rejetée.

#5 ligouane

    Ceinture Noire

  • Members
  • PipPipPipPipPipPipPip
  • 485 messages

Posté 17 November 2011 - 09:39 AM

Tu peux aussi configurer ton serveur pour ne pas accepter de requêtes depuis un autre nom de domaine que le tien.

#6 Logic

  • Honoris
  • PipPipPipPipPipPipPipPip
  • 2733 messages

Posté 17 November 2011 - 14:05 PM

Voir le messageloremipsum, le 17 November 2011 - 09:39 AM, dit :

Tu peux aussi configurer ton serveur pour ne pas accepter de requêtes depuis un autre nom de domaine que le tien.

Je ne suis pas expert en protocole HTML, mais cela doit être aisément falsifiable. Pour Charles en tout cas sans problème.

#7 draad

  • Members
  • PipPipPipPipPipPipPipPip
  • 654 messages

Posté 17 November 2011 - 18:57 PM

Donc même au niveau des noms des variables passées en php, j'ai interet a brouiller les pistes et mettre des nom difficilement compréhensibles pour ralentir la comprehension du code ?

Citation

Dans les grandes lignes, l'idée est d'ajouter un code dans les données transmises par Flash au serveur. Le serveur vérifie la présence et la validité de ce code. Le code est bon, l'opération est validée. Le code n'est pas bon, l'opération est rejetée.

Donc si par exemple je genere un code dans mon flash, qui fait un multiple de deux (je me doute bien qu'il faut trouver plus complexe), et que mon php regarde se code et ne s'excute que si le code est un multiple de deux, cela va fonctionner? Car si j'ai bien compris, du coté flash l'utilisateur ne peut rien faire, par contre c'est dès que flash envoie des donnée en php que l'utilisateur peut les retracer ?

#8 draad

  • Members
  • PipPipPipPipPipPipPipPip
  • 654 messages

Posté 17 November 2011 - 18:59 PM

Mais du coup, pour savoir si le code est valide en php, je vais devoir le tester, et a priori si je le teste, l'utilisateur peut deviner mon codage non?

#9 Logic

  • Honoris
  • PipPipPipPipPipPipPipPip
  • 2733 messages

Posté 17 November 2011 - 21:06 PM

Installe toi FireBug, et familiarise toi avec le moniteur HTTP:

FireBug

Image IPB

A partir de là, imagine les stratégies de hack possibles et comment les bloquer.

Le cryptage est une solution. Sachant que de toute façon aucune solution n'est 100% infaillible.

Modifié par Logic, 17 November 2011 - 21:08 PM.


#10 deuxsucres

    Ceinture Marron

  • Members
  • PipPipPipPipPipPip
  • 115 messages

Posté 17 November 2011 - 22:14 PM

Si le script PHP est bien codé et que le serveur est bien protégé, personne ne pourra voir le code PHP. Il n'en va pas de même du Flash qui peut être décompilé.
Il faut donc rendre illisible le code actionscript.

En tout cas, si tu as besoin te tester ta méthode de cryptage, on est là :P

#11 draad

  • Members
  • PipPipPipPipPipPipPipPip
  • 654 messages

Posté 18 November 2011 - 00:07 AM

@ Logic Merci je vais tester ça.

Citation

En tout cas, si tu as besoin te tester ta méthode de cryptage, on est là

Ha ça serait cool ça, je pense lancer la beta test a la fin de la semaine, donc je veux bien que l'on malmène mon appli pour améliorer la sécu, et le reste du jeu bien sûr !


Citation

Il faut donc rendre illisible le code actionscript.

Pour cela aussi la méthode est "secrete" ? où est-ce qu'il y'a un moyen connu et efficace de le faire?

Modifié par draad, 18 November 2011 - 00:08 AM.


#12 deuxsucres

    Ceinture Marron

  • Members
  • PipPipPipPipPipPip
  • 115 messages

Posté 18 November 2011 - 09:27 AM

Il faut utiliser des méthodes d'offuscation de code. Faire une recherche sur les termes obfuscation et actionscript ou encrypt et actionscript. Voici une article général : Obfuscation sur developpez

Il faut estimer le risque de tomber sur quelqu'un qui prendra la peine de cracker l'application et déterminer en fonction le temps maximum à passer sur le développement du système de cryptage.

Une fois le code offusqué, il est rendu illisible et il est donc difficile d'en faire la maintenance.

#13 Logic

  • Honoris
  • PipPipPipPipPipPipPipPip
  • 2733 messages

Posté 18 November 2011 - 10:25 AM

Dans l'ordre des choses, mieux vaut d'abord procéder au cryptage des données et le débugguer proprement.

Ensuite procéder à l'obfuscation. Je dirai même que c'est la touche finale.

#14 deuxsucres

    Ceinture Marron

  • Members
  • PipPipPipPipPipPip
  • 115 messages

Posté 18 November 2011 - 12:02 PM

Tout à fait, déjà s'assurer que la communication Flash <-> Serveur ne peut pas être simulée.

Si ce point là est en place, 80% du boulot est fait. Tu pourras mieux estimer le niveau de sécurité nécessaire dans le code actionScript ensuite.

#15 kamtron

    Ceinture Marron

  • Members
  • PipPipPipPipPipPip
  • 156 messages

Posté 18 November 2011 - 20:07 PM

pour les caractères spéciaux que flash est susceptible d'envoyer a php, une bonne requête préparée avec la librairie PDO n'est pas de trop non plus

#16 draad

  • Members
  • PipPipPipPipPipPipPipPip
  • 654 messages

Posté 19 November 2011 - 00:43 AM

Bon en tout premier lieu, j'ai lu que les premieres protections commencaient avec les mysql_real_escape_string, j'ai donc voulu les placer mais cela ne fonctionne pas :(

Pourriez vous m'indiquer la procedure pour ajouter cette premiere protection? Voici un exemple de code :




 $pdo_options[PDO::ATTR_ERRMODE] = PDO::ERRMODE_EXCEPTION;
 $bdd = new PDO('mysql:host="mon host" ;dbname=" ma base" , 'pseudo', 'password');
 

 $reponse = $bdd ->prepare('
SELECT Pseudo, Password, Mail FROM Login WHERE Pseudo =? OR Mail =?');
        $reponse->execute(array(mysql_real_escape_string($PseudoTest),
                                mysql_real_escape_string($MailTest)));


#17 draad

  • Members
  • PipPipPipPipPipPipPipPip
  • 654 messages

Posté 19 November 2011 - 05:00 AM

Wow c'est super FireBug ! Moi qui galèrais a essayer de debugger mon jeu une fois mis en ligne, on a tout pour arranger les choses ici ! Mias les petits malins ont aussi tout pour les déranger :P

#18 pol2095

  • Members
  • PipPipPipPipPipPipPipPip
  • 1918 messages

Posté 19 November 2011 - 09:50 AM

ça ressemble beaucoup aux outils de développement d'ie, c'est le même pb avec html/js.

#19 draad

  • Members
  • PipPipPipPipPipPipPipPip
  • 654 messages

Posté 19 November 2011 - 15:02 PM

Ha il existe l'equivalent sous IE aussi ? Si tu as le lien je suis preneur.

#20 Lyanoward

    Ceinture Verte

  • Members
  • PipPipPipPip
  • 52 messages

Posté 24 November 2011 - 10:06 AM

Voir le messagedraad, le 19 November 2011 - 15:02 PM, dit :

Ha il existe l'equivalent sous IE aussi ? Si tu as le lien je suis preneur.
C'est natif à IE9, tu y a accès via la touche F12 ou via le menu outils>outils de développement

#21 draad

  • Members
  • PipPipPipPipPipPipPipPip
  • 654 messages

Posté 24 November 2011 - 21:08 PM

D'accord merci.

J'aurais besoin d'une petite précision pour commencer a réfléchir efficacement a ma protection, les pirates ne peuvent lire que les données echangée d'un script a l'autre, ils ne peuvent pas lire le script directement? Donc si je code mes données transférées dans le flash, puis que je les décode dans le php, ils ne pourront rien faire avant d'avoir trouvé le décodeur.

#22 deuxsucres

    Ceinture Marron

  • Members
  • PipPipPipPipPipPip
  • 115 messages

Posté 25 November 2011 - 09:07 AM

Citation

les pirates ne peuvent lire que les données echangée d'un script a l'autre, ils ne peuvent pas lire le script directement

Effectivement, les données échangées entre le serveur et Flash sont lisibles. Maintenant, comme dit plus haut, si le serveur PHP est bien configuré/sécurisé, le script ne peut pas être lisible. Il n'en va pas de même du script dans le l'animation Flash, car le SWF peut-être décompilé.

Citation

Donc si je code mes données transférées dans le flash, puis que je les décode dans le php, ils ne pourront rien faire avant d'avoir trouvé le décodeur

Oui. Et vous pouvez (devez) également coder les réponses du serveur aux requêtes de Flash. (Je pousse un peu loin) Coder toutes les informations qui transitent entre le serveur et Flash permettent d'éviter la détection de mots-clés facilitant le décodage. Exemple :

Flash récupère auprès du serveurs des informations sur l'utilisateur en cours, la session, le score précédent... Ces données sont en clair (format XML pour l'exemple) :
<answer userid="14" sessionid="24" lastscore="68" />

On peut imaginer que pour transmettre le nouveau score, le Flash doit fournir l'id utilisateur et le numéro de session dans sa requête. Donc si Flash fait une requête au serveur, même codée du genre requete.php?command="A45DS896DDFS89", on peut estimer que cette chaine de caractères contient les informations 14 et 24.

#23 pol2095

  • Members
  • PipPipPipPipPipPipPipPip
  • 1918 messages

Posté 25 November 2011 - 09:38 AM

Le plus simple est d'utilisé un serveur https pour sécuriser les données échangées entre le serveur et Flash.
Le problème est côté client parce que le code est lisible, côté serveur normalement c'est sécurisé.



1 utilisateur(s) li(sen)t ce sujet

0 membre(s), 1 invité(s), 0 utilisateur(s) anonyme(s)