SIMPLE CLASSE POUR RÉCUPÉRER LES RÉSULTATS D'UNE REQUETE SQL
pegase31
Messages postés
6138
Date d'inscription
dimanche 21 décembre 2003
Statut
Modérateur
Dernière intervention
4 septembre 2013
-
5 avril 2011 à 17:29
emanueledimauro Messages postés 30 Date d'inscription samedi 11 octobre 2008 Statut Membre Dernière intervention 13 avril 2011 - 13 avril 2011 à 14:28
emanueledimauro Messages postés 30 Date d'inscription samedi 11 octobre 2008 Statut Membre Dernière intervention 13 avril 2011 - 13 avril 2011 à 14:28
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/53035-simple-classe-pour-recuperer-les-resultats-d-une-requete-sql
https://codes-sources.commentcamarche.net/source/53035-simple-classe-pour-recuperer-les-resultats-d-une-requete-sql
13 avril 2011 à 14:28
il y a une chose sur laquelle je suis vraiment d'accord... le fait de dissocier la partie client de la partie serveur et de laisser au serveur gérer les données et au client les manipuler via du simple IHM.
En Flash il y a une technique pas trop utilisée qui fait plus ou moins ça, mais à l'inverse : le flash remoting.
Il part du principe que coté serveur chacun choisi si mettre du php, du .NET, du java....
Il utilise donc un format d'échange (AMF) qui permet au client flash de piloter des classes distantes et de récupérer les datas renvoyés par les méthodes de classe.
Donc en gros je pense qu'il soit déjà bien performant, pas besoin d'aller plus loin....
J'ai utilisé ce système et c'est très bien. Pour certains développements il est fort nécessaire d'utiliser une logique IHM séparé de l'"intelligence" du serveur.
Mais je reste de l'opinion, qu'il soit pas complètement absurde de faire du sql sur du flash, mais ça dépend strictement du contexte.
Je prends tes exemples...
1) un logiciel de facturation en flash : chaque client a (évidement) une base de données différente, donc le problème ne se pose pas. Chacun peut attaquer que soit même. On donne juste le droit au SELECT, UPDATE, INSERT, DELETE...
2) Un logiciel collaboratif : ça serait au minimum pas prudent d'utiliser un système comme ça. Ou sinon on utilise ça pour toute la partie SELECT, et pour le reste (UPDATE, DELETE... ) on utilise la logique standard.
3) un jeu dans lequel les gens peuvent y inscrire leur score, un formulaire d'inscription à une newsletter, un formulaire de vote : pareil que le point N° 2
Donc voilà je suis d'accord sur le principe que ma méthode est bien délicate, et pas trop structurée. Je dois avouer que tes arguments sont quand même bien solides...
merci
Emanuele
11 avril 2011 à 19:28
* Flash exécution côté client présentation (principe MVC)* PHP exécution côté serveur modèle / contrôleur
Pour faire simple, t'as pas trop le choix ... aucun framework ne permettrait d'embarquer la logique métier et le mapping côté client.
De plus, tu fais aujourd'hui du flash ... OK
Demain tu veux faire un petit soft en .NET en client lourd ... tu refais toutes les requêtes ?
La partie IHM (=côte client) est la partie la plus évolutive et la plus sujette aux évolutions techniques ... embarquer la logique métier ne servirais qu'à l'alourdir voire même t'obliger à la faire évoluer ou la ré-écrire en changeant de techno.
Maintenant côté code, rien ne t'empêche de faire la même chose que t'as fait style mysql.remplir(...); en version plus propre :
Ton service PHP retourne un array de valeurs, il est exposé style : http://domaine/services/MyService/GetItems.xml
(par exemple : le .xml indique qu'on attend du XML)
Ton SDK côté flash aurait un truc du style :
conn = SDK.Connect("http://domaine/");
Coté classes AS tu aurait une class de mapping :
class MyService {
... conn;
public MyService(conn) ...
ArrayList GetItems() {
return conn.Request("MyService", "GetItems");
}
}
Tu peux faire :
service = new MyService(conn);
ArrayList items = service.GetItems();
Ou bien tu te fais un helper pour reproduire ta fonction :
Helper.Assign(service.GetItems(), this);
C'est très schématique, mais cela te montre que plus tu as de niveaux d'abstractions et plus tu as moins à travailler.
Concernant l'attaque sur ton domaine : www.as-ql.org, tu dois t'assurer que l'attaque ne vient pas de l'intérieur.
Je te donne quelques exemples : tu fais un logiciel de facturation en flash, tu ne peux pas le proposer en SaaS (ou imagines sinon que les concurrents vont aller s'espionner entre eux).
Tu fais un logiciel collaboratif là encore tu peux pas, du moment où les utilisateurs n'ont pas tous les mêmes droits ou des droits restreints ta librairie n'est pas utilisable ...
Tu fais un jeu dans lequel les gens peuvent y inscrire leur score, tu fais un formulaire de d'inscription à une newsletter, un formulaire de vote ...etc...
Tu peux faire un très joli truc, fais les couches que j'ai décrit dans mon précédent message et puis rajoutes unes couche RAD comme tu l'as déjà fait pour ton framework ...
Bon courage pour la suite de tes dévs :)
11 avril 2011 à 17:55
Le problème de fond que tu évoques et que tu as très bien ciblé est que au niveau de l'utilisateur, lui il a "plus de droits qu'il ne devrait" avoir.
Maintenant si je vois tes solutions il n'y a rien qui permettrait (sauf si je me trompe bien sur) d'écrire en dur les requêtes sur les *.as et au même temps d'améliorer ce gros problème de sécurité.
Et si tu dois écrire les requêtes ailleurs, par exemple dans des classes php, et en utilisant une passerelle AMF, on perd completement le principe même de ce que je voulais faire.
Je suis en train d'écrire des classe as3 qui sont vraiment simples et au même temps super puissantes. Par exemple tu fais
mysql.remplir("select nom, prenom from table where id=1",this);
et as va chercher sur this les composants nom et prenom. Il vérifie s'il s'agit d'un TextField ou d'un textarea et il remplace les valeurs.
Je pense qu'il soit pas possible (en fin je l'avoue) de sécuriser ce genre de système pour un usage l'utilisateur. Mais si le swf est derrière un htaccess, ou bien l'utilisateur mysql peut faire juste des selects, ou bien on a un superutilisateur que lui seul connait le mot de passe d'accés, alors dans ces contextes, ce système est très utile.
Ok il est un peu rigide, mais souvent on s'y perd en pensant à la sécurité, et on perd completement de vue nos objectifs.
Concernant mon défis, le site www.as-ql.org et encore là et personne a pu l'attaquer. J'ai envoyé un lien à pas mal de monde dans mon entourage, et pour l'instant ça tient.
Mais si on réfléchi un peu : sur un site Internet fait en flash très rarement on fait des utilisateurs
11 avril 2011 à 12:36
J'ai bossé sur quelque chose de très similaire (publié sur flashkod : http://www.flashkod.com/codes/CLASSE-LIAISON-REQUETTAGE-AVEC-SERVEUR-MYSQL-DISTANT-XSQL_38305.aspx) mais avec la notion de sécurité en moins compliqué, mais avec les mêmes failles qu'a relevé Peg.
Je pense comprendre un peu vos deux problématiques, et peut-être qu'un peu de retour sur mon expérience va t'éclairer.
A première vue Peg à l'air de chercher la petite bête mais en réalité il a tout à fait raison, c'est juste qu'il ne l'exprime pas assez clairement :
Je voulais faire du SQL dans du flash, comme j'aurais très bien pu le faire en ajax / javascript. Le problème peut ne pas se poser à première vue car l'utilisateur exécutant le code est identifié, donc un guest ne peut pas nuire.
Le problème se pose à deux niveaux :
- l'utilisateur connecté peut lui avoir plus de droits qu'il ne devrait ... mais étant faignant de ce côté je m'en fout du moment où ça m'aide (j'estime qu'être faignant en informatique est une qualité au passage :)
- autre problème c'est la logique métier et la ré-utilisabilité et c'est là que le bat blesse :)
Etant faignant je ne voulais pas avoir à écrire le SQL à chaque fois, répéter des règles métier complexes, ou bien en changeant la structure repasser par des kilomètres de code.
Du coup quand tu deal avec des bases de données, la bonne pratique veut que tu en fasses des objets. Le choix de l'environnement où tu fais ton objet est important, on pourrait être tenté de le faire en flash (avec tous les problèmes que ça pose au niveau sécurité) ou bien le faire côté PHP, permettant ainsi de partager les ressources côté ajax, flash, ou bien un MVC classique avec des vues en HTML.
Donc pour répondre à ta source, tu as raison sur le fond, mais tu t'y prends de la mauvaise manière.
Ce que t'aurais dû chercher à faire :
Une partie API :
- c'est d'intégrer un ORM, avec un DBAL
- faire des helpers pour la sérialisation : XML, JSON, CSV ...
- un équivalent de ton data.php pour le routage des appels en mode REST, et utilisant les helpers pour exprimer les retours
- un mode session ou quelquechose d'équivalent permettant de sécuriser l'appel de certains services
Une partie SDK :
- des classes de base pour les autres languages
* Flash
* Javascript
- éventuellement si tu est motivé, à partir d'une classe PHP tu peux générer l'enveloppe AS ou JS te permettant de ne pas perdre du temps sur une seconde re-définition (cf PHP+Reflection).
Dans le principe ça serait un peu similaire à ça : http://www.phpcs.com/codes/AJAX-TOOLKIT-PARTAGE-CLASSES-ENTRE-PHP-JS_47075.aspx
------
Lorque t'enchaines sur la création d'un nouveau projet avec ton framework, tu fais côté PHP tes classes qui gèrent la base de données, et puis tu inclues dans ton flash les enablers AS qui leur correspondent.
Le tout sera : optimisé, sécurisé, simple, ré-utilisable, évolutif
Bon courage, si tu ponds un projet comme ça n'hésites pas à me prévenir :))
akh
8 avril 2011 à 09:41
D'ailleurs le cryptage là il sert pas à faire transiter les données, mais juste les commandes.
Et comme on l'a bien dit, on pourrait s'en passer à condition de garder la notion de clef (jeton) envoyé par le php.
Quand j'ai dit de crypter avec une notion supplémentaire (par exemple port client du navigateur) c'était juste pour éviter que si quelqu'un tombe sur cette clef il puisse attaquer le serveur.
Exemple : la clef est "abc". Le php remarque que le port client est 3456. Il va pa envoyer "abc", mais "a165jhdk45" qui est rien d'autre que la clef "abc" crypté avec 3456. En revanche quand il fait du décryptage, il va avant tout chercher le port client pour crypter la clef "abc" et avec ce qu'il obtient il va décrypter la requête.
Si quelqu'un se met à sniffer le réseau où le client flash est installé il va trouver la clef, mais il pourra pas s'en servir. Et même s'il sait que la clef est crypté avec le port client, il peut pas s'en servir parce qu'il connait pas la façon avec laquelle le serveur a crypté la clef.
Donc il reste juste le problème de la gestion des utilisateurs. Là pour l'instant on peut avoir un seul super administrateur. Et si on définit un utilisateur standard, dès qu'il peut écrire la moindre chose, du coup il peut tout casser.
C'est ça le vrai problème... une idée ?
7 avril 2011 à 20:56
Peu importe les méthodes de transfert, puisque le flash est ouvert aux 4 vents une fois décompilé, on lui fait faire ce qu'on veut.
Tu n'as toujours pas compris que flash c'est pas sécurisé du tout, et que c'est là toute la faiblesse de ton principe ?
Peg'
7 avril 2011 à 20:45
tout je pouvais imaginer sauf que vous allez mettre en doute la chose plus simple... le cryptage.
Bon, alors ça serait quoi la solution sans cryptage ? Envoyer les requêtes en clair ?
Imaginons qu'on fait ça... donc le php dit "oui2 à l'user et mdp.
Il doit quand même valider et retourner quelque chose au flash non ?
Par exemple un flag ??? Evidemment c'est une mauvaise réponse car si je dit juste OUI ou NON avec une variable, alors là oui que le flash est dangereux car il suffirait de injecter une variable pour faire toutes les requêtes en clair.
Donc comment on fait sans crypter ? Deux possibilité :
- soit on crée une session (solution lourde) et coté php on valide que tout ce qui arrive de l'utilisateur validé.
- soit on utilise la notion de jeton, vous aimez la sécurité donc normalement vous connaissez... on envoie au flash un jeton (enfin la clef !!!!) et le flash envoie la requete en clair avec le jeton. Le php exécute la requête car le jeton est le bon !!
Mais alors je me dit : c'est pas plus simple d'utiliser le jeton pour crypter la requête ? Le cryptage est super léger, l’algorithme est très bien optimisé. Mieux que gérer ça avec des sessions.... et en plus on envoie en POST des requêtes pas compréhensibles plutôt que envoyer les requêtes en clair.
Voilà, voilà... pour gagner de l'argent il faut déjà se poser des questions et dès fois écouter les réponses...
En tous les cas merci.
7 avril 2011 à 20:06
7 avril 2011 à 19:18
Peg'
7 avril 2011 à 19:10
La seule chose qui te sauve est l'acces PHP user/pass classic...
En gros ne te sert à rien d'encrypter sous Flash. Ca ne fait que compliquer et n'apporte aucune protection. C'est ce que veux te dire Peg.
7 avril 2011 à 17:11
Et c'est justement le faire de faire un PHP "que pour ça" qui est sécuritaire.
Peg'
7 avril 2011 à 17:06
mysql.maj("select id, label from table order from label", moncombobox);
et voir que ton combobox se rempli tout de suite ! ! !
Une ligne de code contre :
- Un fichier php qui doit être fait que pour ça
- donc un fichier xml qui doit se créer (avec la bonne mise en forme)
- Du as3 pour récupérer ton xml et mettre à jour ton combobox
Je trouve que 5 secondes contre au moins 5 minutes ça fait une belle différence.
Par contre là il faut développer l'API... tu m'aides ?
;-)
7 avril 2011 à 16:59
Surtout en voyant le boulot demandé pour sur-sécuriser tout ça.
Peg'
7 avril 2011 à 16:40
Si tu me fais un site en joomla, et je suis la seule personne à utiliser ce site, et donc administrateur, je peux aussi vider ma propre base... en fait je serais juste un crétin.
Et si j'ai un B&B, et je gère mes chambres avec un site en php, pareil j'ai toujours une admin et je peux à tout moment tout casser...
J'insiste, tout dépend du contexte...
Le seul vrai problème de mon système est le suivant :
Je peux créer plusieurs utilisateurs, pas de soucis, et les rélier à des utilisateurs mysql différents, chacun avec des droits différents.
Mais les droits mysql ne seront pas "intelligents". Par exemple je peux donner le droit en écriture juste sur une table donnée et le reste en seule lecture. Mais je peux pas dire que sur cette table je peux écrire seulement si le champs "droit" est à 1, ou bien si le champs "utilisateur" contient "monnom".
C'est ça le vrai problème qu'il faut résoudre pour adapter le système à tout.
Sinon il peut aller très bien dans un contexte où il y a un seul utilisateur, qui est donc administrateur.
7 avril 2011 à 15:56
Mais même si tu laisses un seul update, on peut te vider ta base ...
Peg'
7 avril 2011 à 15:40
Mais (en passant) select, insert et update c'est bien en lecture/écriture, ou sinon j'ai vraiment perdu la raison !
La source je l'ai mise en ligne pour avoir un échange et partager mon idée et parce que je crois dans certaines contextes ça peut être très utile.
Si je suis pas le bienvenu alors je m'en vais directe, mais sans oublier de te remercier pour le temps que tu m'as dédié.
7 avril 2011 à 15:22
ça limite fortement l’intérêt déjà bien bas du principe ...
Mais je te parle surtout d'un principe qui pourra être utilisé facilement et par tous. Ou alors tu développes pour toi uniquement et à ce stade, je ne vois plus la raison de la présence de cette source ici.
Peg'
7 avril 2011 à 15:18
En plus on peut toujours créer un utilisateur mysql qui n'a pas le droit au drop, alter, shutdown, process, create, file etc...
En gros on laisse juste select, insert et update, même delete n'est pas nécessaire coté client, on gère avec un champs d'archivage.
Je cherche je cherche...
;-)
7 avril 2011 à 15:04
Si ton projet est en plus un truc pro, personne n'accepteras ton système tellement il est facile à planter une fois enregistré.
Mais continue de chercher ...
Peg'
7 avril 2011 à 14:59
L'intérêt (je le disait) est de développer sur du flash avec la puissance du sql, sans avoir à passer par du xml pour la moindre chose.
Mais ça serait par exemple pour un projet de logiciel en ligne, et pas pour un site Internet. Dans un contexte de logiciel en ligne j'imagine pas mon client attaquer soi même...
Autre application : page d'admin même pour un site Internet.
Un logiciel de mise à jour quoi ...
Par rapport à l'html le temps développement ça pourrait se réduire considérablement. Mais là il faut développer de l'API bien puissante....
7 avril 2011 à 14:36
Par contre avec le user/login, je te détruit tout, te plante ton serveur et tu n'y auras même plus accès.
En gros, c'est tout ou rien.
Mais quel est l’intérêt au final ? Il faudra bien que tu donnes l'accès à quelqu'un d'autre que toi un jour ou l'autre.
Peg'
7 avril 2011 à 14:28
- je passe login et pass à cryptusage.php qui me donne la clef
- avec cette clef je crypte mes requêtes et je les envoie cryptées à data.php
- data.php décrypte le tout et il exécute la requête.
- Flash récupère les variables du data.php
data2.php n'est pas concerné. Je l'utilise juste pour montrer les données avec la méthode classique.
Donc, tu me confirme, et c'est ça le plus intéressant pour moi, que sans login et mot de passe tu pourras JAMAIS attaquer ma base en recompilant le flash ?
7 avril 2011 à 14:21
Et ça me prend exactement 2 min à changer la requête, et lancer la compilation.
la preuve :
- tu demandes à data.php de récupérer les variables sans passer de requête php
- tu passes le login/user à cryptusage.php qui te renvoie la clef et une autre variable, puis tu passes le tout à data2.php si tu as la clef.
Je n'ai pas éte en profondeur, mais il suffit de changer "sql_query='DROP TABLE famille'" pour détruire toutes tes données de table.
Peg'
7 avril 2011 à 14:09
Mais entre "informer" et "expliquer" il y a une belle différence, et moi j'arrive toujours pas à comprendre comment quelqu'un pourrait attaquer le site en question :
http://as-ql.org
Justement si tu me dis que même un gamin peut attaquer ça facilement, je reste sans mot.
Mis à part le temps qui te manque, toi tu saurais le faire cet attaque ?
Si oui, il te faudrait combien de temps?
Tu peux estimer ça plus au moins ?
Je te demande pas de le faire.... si t'as pas le temps t'as pas le temps.
7 avril 2011 à 13:57
Peg'
7 avril 2011 à 13:56
Tu crées une banque où seuls les clients peuvent accéder au quichet, mais où les billets sont à dispo par-terre au lieu d'être dans un coffre.
Tu pourras demander la clef à qui tu veux, faire en sorte qu'elle ne transite pas par flash, récupérer l'ip de la personne, la session (et encore), tant que le sql passera par flash, il te plantera ta base .. je le dis et le maintiens !
Ton système fonctionnerais éventuellement uniquement en local, pour toi.
Et à ce niveau, AIR propose une gestion trés efficace de SQL Lite.
Peg'
7 avril 2011 à 13:52
Donc ça revient au même qu'utiliser un seul mot de passe.
7 avril 2011 à 13:49
C'est le fait de crypter la clef avec le port client.
Comme ça si quelqu'un trouve la clef elle elle pas réutilisable...
Par contre si on trouve user et pass c'est mort.
7 avril 2011 à 13:44
- celle du user lambda
- celle du php qui accède à la base
Toi, il en suffit d'un pour accéder directement à la base : celle du user... et en plus on fait la requête en dur directement en local sous dev de flash.
Peg'
7 avril 2011 à 13:37
C'est clair que là c'est sécurisé.
Peg'
7 avril 2011 à 13:35
la seule chose pourrais être un espion dans l'ordi de la personne qui utilise ça...
mais évidement un attaque avec espion peut se faire vers n'importe quoi (ssh par exemple).
Si je me connecte avec root à mon serveur ssh c'est la même chose: un espion pourrait bêtement détecter mes frappes...
7 avril 2011 à 13:33
Peg'
7 avril 2011 à 13:30
Dans la classe j'ai donc rajouté un constructeur avec login et mdp...
le constructeur se connecte au serveur via du php qui vérifie si c'est bon et qui renvoie la clef au flash...
Je suis en train de compléter la classe et rajouter des méthodes.
Par exemple un méthode "saisie" qui fonctionne comme ça :
mysql.saisie("select nom, prenom from matable where id=5");
en gros il cherche tous les composants éditables (TextField, combobox... ) qui ont comme nom d'instance nom, prenom et il les mets à jour. Ensuite il dispatche un événement utilisé pour avancer...
T'imagines ?? Tu fais
mysql.saisie("select nom as 'monchamps', prenom as 'autrechamps' from matable where id=5");
... et tes textes "monchamps", "autrechamps" sont mis à jour.
Pour un combobox on peut imaginer une méthodes combo :
mysql.combo("select Id as 'id',ville as 'label' from matable", combovilles);
et il va mettre à jour combovilles avec id (valeur) et label (nom de la ville)
Je trouve ça très puissant pour un logiciel en flash.
7 avril 2011 à 13:20
Tout ce qui transite via flash est récupérable !
Peg'
7 avril 2011 à 13:16
1/ L'utilisateur s'enregistre de facon classique
2/ PHP donne une clef a a Flash
3/ Flash envoie des requete dures criptées avec la clef
4/ Si PHP ne recoit pas la clef, il ne traite rien !
Si j'ai bien tout compris !!!
7 avril 2011 à 12:23
j'ai acheté un domaine, le nom est sympa : as-ql.org
http://as-ql.org/
Donc, si quelqu'un arrive à m'attaquer je serais heureux d'abandonner cette idée.
S'il est vrai, comme Peg le dit, que le tout n'est pas sécurisé (en plus il dit carrément "sécurité zéro") ça devrait sauter vite non ?
Peg n'a pas le temps (5 minutes évidement n'est pas suffisant).
Ou peut être (comme je suis convaincu) personne peut me faire sauter ça...
Je précise que dans le SWF il y a bien un endroit où la requête est en dur...
6 avril 2011 à 14:43
Je suis de tout coeur avec toi ...
En attendant, je t'ai informé que ce n'était pas sécurisé. Libre à toi de m'écouter ou pas
Peg'
6 avril 2011 à 14:36
Je pense que en informatique il y a une belle différence entre AND et OR.
=======================================================
(Je mets UN SEUL htaccess à la racine de mon système (logiciel en ligne). D'ailleurs tout le monde a fait ça avec phpMyAdmin sans se poser des questions, pourtant là les requêtes passent bien en clair...)
OR
(Je mets un fichier php qui filtre les requêtes et qui laisse passer juste les SELECT)
OR
(Je mets sur la config mysql un utilisateur qui peut faire juste des SELECT (encore mieux ;-) et je ne filtre rien au niveau du php) et personne peut flinguer ma base, en revanche c'est super agréable de faire des requetes directement sur le flash
OR
(Je crée un système avec mot de passe sur flash qui reçoit du serveur la clef et là je peux mettre le tout en ligne sans avoir peur d'être attaqué par un gamin)
==========================================================================
Il y a beaucoup de possibilités, toutes bien sécurisées... pour un simple site Internet peut être ça vaut pas la peine, mais pour un vrai logiciel en ligne tout en flash avec droits d'accès, ça accélère beaucoup le développement et ça peut être intéressant, surtout quand on a plusieurs requêtes imbriquées qui déclenches des actions graphiques.
Voilà, il faut faire attention aux parti pris....
6 avril 2011 à 13:29
Pour résumer :
- tu dois t'inscrire pour utiliser ton flash
- tu dois mettre des htaccess partout
- tu dois créer un php qui filtre toutes tes requêtes avec système de code crypté pour éviter qu'on lui injecte n'importe quoi (ce qui ne marchera pas)
- tu dois mettre ça sur un https pour éviter les intrusions.
Et au final ça reste toujours moins sécurisé qu'un simple php contenant déjà les requêtes ...
Excuse-moi mais là c'est moi qui décroche.
Peg'
6 avril 2011 à 13:19
Pour sniffer mon serveur en plus il doit y avoir un service installé quelque part qui scrute la pile TCP/Ip, mais alors ça veut dire que mon serveur n'est pas sécurisé, ou bien quelqu'un physiquement caché à l'intérieur du data center ovh (par exemple) qui a d'ailleurs piraté le système et qui a réussi à contourner Citrix et recevoir une adresse ip d'un Dhcp fou, et être accepté au niveau du réseau et des acl des routeurs Cisco....
ça me parait un peu compliqué pour un gamin qui va sur msn non ?
6 avril 2011 à 13:04
Je n'ai malheureusement pas le temps de m'amuser avec ton code, mais je te propose de l'appliquer à un site et de chronométrer le nombre de jours de vie de ta BDD.
Au moins tu auras une application réelle de ce que tu penses impossible.
Peg'
6 avril 2011 à 11:35
je pense juste qu'il faut savoir comprendre si une chose est faisable ou pas et à quel prix.
Il faut pas dire que "comme personne l'a fait personne peut le faire".
Je viens de mettre en forme la solution dont je te parlais hier... la clef de cryptage coté full serveur.
Je vais la mettre en ligne et tu me montreras, si ça te dit, qu'il est possible de l'attaquer... et moi je baisserai les bras.
C'est un truc très simple, une connexion user et passe, et si c'est bon ça rentre et ça fait des requêtes...
Voilà voilà
à très bientôt
5 avril 2011 à 22:38
C'est comme écrire directement un fichier sans l'accord du client ou d'autres petits trucs impossible à faire pour flash : ce n'est pas impossible sans raisons.
Ensuite, tu viens de te mettre des tonnes de restrictions pour un truc qui peut être fait de façons tout à fait sécuritaire (dans les normes respectables) avec une méthode classique.
J'admet que ton idée de base est bonne, mais uniquement dans un monde où les gens seraient honnêtes et où les petits cons en herbe n'auraient pas de plaisir à te péter ta base juste pour se vanter sur msn après ...
Peg'
5 avril 2011 à 22:26
Bon d'accord... aujourd'hui on découvre que tout ce qui est "usurpation d'identité" n'a jamais pu se faire sur les sites en total php.
N'importe quel site peut se faire espionner user et mdp, et même chose pour le root en SSH, ça suffit un espion de frappe pour ça.
Mais bon...
5 avril 2011 à 22:13
C'est vrai que la nuance est tout de suite vachement importante.
Au final, une fois le swf récupéré, on fait ce qu'on veut avec. Connecté ou pas !
Peg'
5 avril 2011 à 22:06
Si on est dans le cas 3) le swf est incapable de faire les requête si la personne ne se connecte pas.
Il faut rentrer un user et mdp et seulement si le serveur les reconnait alors le code de cryptage est envoyé au flash.
Dans ma classe MySqlConn la variable :
private var chiave:String = "abcdyfx9ilk"; (en italien chiave veut dire clé)
est écrite en dur. La solution que je propose est donc que cette variable soit null au début (ou bien "").
Elle doit être récupérée via une connection au serveur web avec le bon user et mdp.
Si le hacker ne connait pas le mot de passe qui permet d'avoir cette clé, la variable "chiave" reste null et donc de toute façon de l'autre coté le php ne décrypte pas correctement.
Donc voilà je m'étais probablement juste mal expliqué non ?
5 avril 2011 à 21:53
une autre question ?
Peg'
5 avril 2011 à 21:51
j'ai rien compris en fait.
Partons de zéro. Toto est un hacker qui veut faire tomber mon serveur et ma base de données.
Il voit que mon site en flash fait des requêtes et déjà il doit comprendre qu'il envoie des variables POST toujours vers le même fichier php.
Donc Toto se dit "ça doit être carrément des requêtes SQl cryptées".
Il voit aussi que le site demande avant tout de rentrer un user et mot de passe.
Comme il est très fort alors il pense: probablement la clé de cryptage pour créer les variables POST est liée à l'utilisateur et c'est le serveur qui l'envoi s'il reconnait l'utilisateur.
Alors là Peg, tu m'expliques un peu comment il va s'organiser pour attaquer le serveur ?
Il y a quelque chose que je ne vois pas clair dans ta pensée, et tu as probablement raison, mais j'y arrive pas désolé :-(
5 avril 2011 à 21:33
Tant que le php ne fait que récupérer une requête construite dans le flash, tu as une porte grande ouverte.
On peut même avec ton principe prendre la main sur le serveur, mais après c'est à toi de voir ce que tu veux faire ou pas...
Peg'
5 avril 2011 à 21:25
là on a un problème de communication.
Il y a 3 possibilités :
1) Le swf est à l'intérieur d'un répertoire protégé, et seulement le client peut y accéder : pas de soucis. Tu confirmes ? Un hacker devrait forcement connaitre le mot de passe, mais ça c'est pareil pour un serveur FTP, SSH ou autre...
2) Le swf est exposé à tout attaque... on limite alors la classe à l’exécution des requêtes SELECT, en fait c'est au niveau du php qu'on va exécuter que des requêtes SELECT et tout le reste est filtré.
3) Troisième solution : la clef de cryptage n'est pas stocké sur le swf, mais elle est récupéré du serveur seulement à partir d'un accès protégé par mot de passe. En gros si tu récupères le swf tu peux rien y faire si tu as pas le mot de passe qui va te permettre de recevoir du serveur la clef, qui n'est rien d'autre que ton mot de passe crypté. Seulement avec cette clef on peut produire la variable et l'envoyer en POST vers le data.php
Si évidement la deuxième solution n'est pas parfaite alors dans la troisième je ne vois pas de faille. La seule faille est l'envoie de la clef sur le web (mais va détecter ça...), de toute façon un serveur https va faire l'affaire.
Voilà j'espère d'avoir été suffisamment clair.
5 avril 2011 à 21:14
seul moyen, comme dit au dessus, c'est de n'autoriser un user SQL qu'a utiliser SELECT
ce qui limite fortement l'utilité du truc..
decompiler un swf ca se fait en 2 click au passage.
5 avril 2011 à 20:48
De plus, n'importe qui peut injecter des variables à un flash par flashVar (sur Firefox, Firebug fait ça très facilement) et du coup, niveau protection, c'est toujours zero.
Le principe de base est simple : toutes les requêtes sql doivent se faire en interne sur le serveur et êtres protégées par des moyens efficaces (pdo/préparation par exemple) or, dans ton cas, cryptage ou pas, tant que c'est par flash que tout ça transite, ça sort du cadre interne au serveur .. et donc rien de sécurisé au final.
C'est pas pour rien qu'on à fait des scripts serveurs !
Peg'
5 avril 2011 à 20:11
le htaccess permet au serveur de contrôler si l'accès au répertoire est fait par un client qui a été validé. Le port Client d'un swf qui se trouve sur une page web est hérité du port de la page du navigateur, donc si la page passe le controlle user et pass le swf aussi. Chose différente dans le cas d'un flash qui contrôle l'audio ou la cam par exemple parce que là d'autres port sont ouverts (toujours ports client) et donc il y a une alerte de sécurité. Ou bien si le flash ne se trouve pas coté navigateur, mais isolé. Dans ce cas il va ouvrir son port à lui.
D'ailleurs tu dis que le swf est evidement chargé sur nos fichiers temporaires comme les images... alors selon toi quand on accède à un répertoire protégé via htaccess on voit plus les images ???
Là où je suis d'accord avec toi est le fait qu'on a plusieurs façons d'attaquer le flash si jamais le tout ne se trouve pas derrière une protection htaccess.
On récupère le flash et (t'as raison) on change n'importe quelle requête par un drop quelque chose...
Ma solution ? deux possibilité.
1) on fait un data.php intelligent qui filtre toutes les requêtes sauf les SELECT... ça c'est facile on est d'accord ? quelque règle sur les string avec l'utilisation des expression régulières...
2) J'ai mis un shéma (capture écran) avec une possibilité : la clef de cryptage est envoyé par le serveur et elle est liée à un mot de passe qui doit se trouver stocké sur serveur. Donc le encode et decode du cryptage sont coté serveur et la liaison se fait via le socket stocké quelque part....
5 avril 2011 à 19:23
Ensuite, je vois ça dans ton code : mysql.query_exec("select nom, prenom from matable");
Si ce n'est pas une requête en clair, je ne sais pas ce que c'est ...
Il suffit de changer le texte et ,crypté ou pas, je te flingue ta base sans soucis.
Comment comptes-tu palier à ce gros problème, alors ?
Peg'
5 avril 2011 à 18:33
je comprends pas ta phrase "Le htaccess ne protège rien, puisque le swf doit pouvoir accéder librement au php pour faire les transferts de données."
Si le swf et le data.php se trouvent à l'intérieur d'un répertoire protégé
il n'y a pas moyen d'accéder au swf et de le décrypter.
Au contraire le swf et le php communiquent sans problèmes du moment
où on a mis user et pass et on est rentré via le navigateur à la racine du répertoire.
Tu dis aussi que :
"Et pour te répondre : décrypter la fonction query est inutile, puisque tu passes ta variable en clair lors de l'appel ..."
Lors de l'appel je passe pas la clef de cryptage.
Je passe juste la requête crypté et une variable aléatoire pour éviter le cache.
Sinon concernant la gestion coté php, je ne dis pas de faire le requêtes à partir du php, mais de mettre un contrôle sur la requête décrypté qui l'analyse pour savoir s'il s'agit juste d'un SELECT ou bien d'un UPDATE, INSERT ou autre....
5 avril 2011 à 18:18
Même déjà à l'intérieur même d'un php brut il est difficile de faire une véritable protection, alors si tu extériorise la requête, c'est hyper simple de tout planter et de faire n'importe quoi.
Donc gérer du SQL directement dans flash, ce n'est pas possible, car pas sécurisé. Et c'est pour cela que ça n'a jamais été implémenté en ActionScript.
Et pour te répondre : décrypter la fonction query est inutile, puisque tu passes ta variable en clair lors de l'appel ...
Si tu veux gérer tes requêtes dans le php, ça revient au même que de faire tes demandes de variable via php .. et donc de faire la requête dans le php... et donc réinventer la roue.
Mais cette réflexion est intéressante pour prouver que flash est et doit rester une interface utilisateur. Rien de plus.
Peg'
5 avril 2011 à 17:55
Personnellement j'ai conçu ce genre de script à l'intérieur d'un répertoire protégé par htaccess, en gros pour faire de l'admin ou bien dans des projets de logiciel en ligne, où il y a que le client qui peut accéder au swf.
Sinon j'ai jamais décompilé un swf. Là il suffit pas de trouver la chaine de cryptage, mais il faut décompiler carrément la fonction query à l'intérieur de la classe. Il est vraiment si facile ?
Il y a de toute façon une solution simple pour résoudre les problèmes de sécurité que tu évoques, et c'est de gérer l'autorisation au requêtes au niveau du php (fichier data.php).
On interdit toute sorte de update, insert, drop ect... d'ailleurs cette classe est pensé pour faire juste du SELECT...
Quelqu'un à une idée pour mieux protéger le tout ?
5 avril 2011 à 17:29
N'importe qui étant capable de décompiler le flash sera capable de détruire ta base avec un simple "DROP SCHEMA" depuis n'importe quelle adresse en injectant du POST dans l'url (c'est tout à fait faisable).
Donc intéressant techniquement, mais solution à fuir comme la peste.
Peg'