Discussion :

[tse_jc]

d�butant en d�veloppement web (php/mysql / notepad)

Ensuite, c'est visiblement encore un qui n'a compris que ce qu'il a voulu comprendre.

Ce qui m'inqui�te est que vous n'�tes visiblement pas capable de diff�rencier deux arguments et de vous faire votre propre opinion en toute objectivit�.

[redoran]

oui merci pour le compl�ment
j'attacherai de revoir le module de s�curit� d'une application web

[tse_jc]

Preventing injection requires keeping untrusted data separate from commands and queries.
Source : http://www.owasp.org/index.php/Top_10_2010-Injection
Ce qui peut se traduire par : � Pr�venir les injections requiert de s�parer les donn�es non s�res des commandes et requ�tes. �

Or ce que l'on vient de vous expliquer, se r�sume � dire que cette d�finition n'est pas pertinente et
"un doute sur les param�tres? => pas de requ�te". Donc � partir du moment o� on v�rifie soit m�me, pas besoin de PDO pour le faire quand surtout il n'est pas capable de contr�ler la pertinence des donn�es re�ues vis-�-vis du mod�le.

Y en a qui ont la t�te dure^^

++

[ericd69]

les tutos c'est comme la doc, tu n'est jamais � l'abri d'une erreur...

Je vais essay� d'�tre clair...

en pratique, il y a 2 types de requ�tes pr�par�es:

• celles que tu g�n�res par l'extension du langage appelant (m�thodes ou fonctions d�di�es selon l'interface). elles le sont au niveau du driver SGBD puis envoy� au SGBD
• celles que tu g�n�res au niveau du SGBD directement...

�a implique quoi?

• certaines actions interdites dans les requ�tes pr�par�es au niveau SGBD sont faisables au niveau driver parfois
• le processus de pr�paration n'est pas le m�me (tu as pas forc�ment la m�me phase d'optimisation par exemple)
• la version pr�par�e n'est pas stock�es dans le SGBD si elle est g�n�r�e par le drivers
• des �carts de performances consid�rables peuvent apparaitre entre les 2 fa�ons de faire

la SEULE fa�on d'isoler le sql du langage appelant est l'utilisation des proc�dures stock�es avec une politique de s�curit� particuli�re (un utilisateur sql avec seulement "GRANT EXECUTE" cot� langage appelant) et une gestion des actions interne aux proc�dures (passage d'un token ou d'un identifiant/mdp en param�tre des proc�dures faisant des modifications sur la bd)

en proc�dant ainsi, tu n'as plus que des appels aux proc�dures et impossibilit� d�acc�der directement � la bd ou sa structure... de plus, les requ�tes n'apparaissent plus au niveau du langage appelant... donc tu as bien isol� le SQL...

rien � voir avec les requ�tes pr�par�es tu vois...

ATTENTION!! cela ne veut pas dire que tu ne dois pas v�rifier la coh�rence des param�tres pass�s aux proc�dures

[tse_jc]

Avec ce que tu viens de dire, je crois qu'on va � nouveau le perdre^^. Mais bon maintenant qu'on y est, je vais en rajouter une couche

ATTENTION!! cela ne veut pas dire que tu ne dois pas v�rifier la coh�rence des param�tres pass�s aux proc�dures

Passer exclusivement par des proc stocks, est effectivement et d�finitivement le mieux, et puis le jour o� on n'a plus une ligne de sql c�t� php on ne peut plus s'en passer^^. Mais la contrepartie c'est comme viens de le dire eric, c'est qu'il faut �tre intraitable sur le contr�le qualit� des param�tres pass�s, bref faut �tre en tol�rance z�ro.

D'ailleurs passer par un token dans les proc d'update ou d'insert, merci eric, je suis d�j� fan j'avoue que je n'y avais jamais pens� et pourtant c'est d�j� si �vident maintenant que j'y pense!

++

[tse_jc]

Petit oubli. En g�n�ral les dev PHP sont habitu�s � travailler exclusivement avec des arrays au niveau des param�tres de requ�tes surtout quand le nombre de param�tres � traiter est important (30+ par exemple).

Et comme en proc stock les arrays n'existent pas, en g�n�ral ils renoncent car cela n�cessite des techniques particuli�res et la difficult� leur semble insurmontable.

A ce propos j'ai commenc� � faire un topic sur un autre fofo, que j'esp�re pouvoir continuer sur celui-ci bient�t.

[ericd69]

l� je suis en train de pondre un tuto sur le proc�dural dans mysql

apr�s je verrais � en pondre un sur cette pratique de s�curit� un peu plus s�rieuse que ce qui a �t� pr�sent� au d�but

et l� encore je vais r�p�t� un truc c'est que l'�chappement simple via \ n'est pas toujours une bonne id�e car on peut le contourner... il est pr�f�rable de faire des substitutions dans les caract�re litigieux... c'est pas les m�thodes qui manquent...

et l� impossible m�me si le texte fournit � la requ�te est une requ�te sql aussi de faire des injections...

l'autre avantage du proc�dural avec un utilisateur qui ne peut qu'ex�cuter des proc�dures:

• aucun acc�s possible hors les proc�dures, aucun show, select,etc... aussi bien dans les versions propos�es par le driver que sur le SGBD
• pas de possibilit� de passer une requ�te en param�tre de la proc�dure pour cet utilisateur...
• c'est les droits du "definer" de la proc�dure qu'on peut utiliser pour tout ce qui est ex�cut� dans la proc�dures

aucun cms couramment utilis� pour la cr�ation web (� ma connaissance) n'est programm� comme �a...
et on s'�tonne toujours du nombre de hacks r�guli�rement trouv�s pour chacun d'eux... cherchez l'erreur

[tse_jc]

Quand ta cha�ne est trait�e et consid�r�e comme "propre" dans ta proc�dure et qu'elle accepte les quotes (simple ou double ou les deux) il faut bien les echapper dans tous les cas. De toute mani�re si elle n'est pas �chap�e l'appel de la proc�dure ne passera pas, et une fois les donn�es valid�es par la proc�dure, personne ne peut intervenir entre le moment o� elle est valid�e et que le traitement commence car on est dans la proc�dure. Entre nous, que l'�chappement puisse �tre contourn�, dans un contexte proc stock, je m'en fou un peu, ca ne peut rien changer de toute mani�re.

++

[ericd69]

sauf quand tu fais des dump version sql comme propos� dans phpmyadmin, l� �a peut �tre dangereux selon ce que tu utilises pour ex�cuter le code g�n�r� ...

tu sais que tu peux faire une extraction de chaine plus efficace avec un appel � une requ�te pr�par�e et la fonction elt() dans une boucle toute simple pour lire un tableau sous forme de chaine...

apr�s faut aussi rappel� que un tableau �a revient � une table temporaire avec le moteur memory aussi si tu dois traiter toutes ces valeurs en une ou plusieurs fois

[ascito]

en r�ponse au #64

requ�tes pr�par�es vs proc�dures stock�es ,


donc il faut bien diff�rencier les deux,

(Par contre, le moteur SGBD va se servir de C de plus en plus, et donc traiter indiff�remment l'un et l'autre...: lecture annexe );

pour l'instant il para�t intelligent de diff�rencier clairement ces deux mani�res de faire, et donc dans tous vos Topics, dire soit proc�dures stock�es ( en sql par exemple), soit requ�tes pr�par�es ( en php par exemple ) ;

ce n'est pas tr�s clair dans les r�ponses en g�n�ral, pour ma part, et surement pour les novices aussi..

[ericd69]

c'est pas encore �a pour te le prouver...

tu peux faire des requ�tes pr�par�es dans une proc�dure stock�es...

pour le c dans les proc�dures stock�es �a fait des ann�es qu'ils le pr�voient

mais si tu veux faire du c pour �tendre les fonctions de mysql tu as les UDF

[tse_jc]

@Ascito : Oui eric � raison de le notifier, les requ�tes pr�par�es n'ont rien � voir avec les proc�dures stock�es, il ne faut pas m�langer.

tu sais que tu peux faire une extraction de chaine plus efficace avec un appel � une requ�te pr�par�e et la fonction elt() dans une boucle toute simple pour lire un tableau sous forme de chaine...

@Eric: Je serais curieux de faire des benchs comparatifs sur nos deux m�thodes. Avec ELT() la tentation de retomber dans les pi�ges qui font l'objet de ce post sont grandes.
Ce cas de figure mis � part, car ce n'est pas cela qui m'interesse maintenant, pour faire le point, faisons un petit comparatif:

1a) Ma m�thode est d�terministe : je ne lis que les param�tres attendus. Si d'autres sont pass�s, ils sont ignor�s.
1b) On peut le faire aussi avec ELT() j'en conviens.
2a) Je v�rifie le type en m�me temps, si le type ne corresponds pas, je lui affecte une valeur hors domaine dans le type attendu, je la contr�le imm�diatement en sortie de v�rification, et dans ce cas de figure, je g�n�re une erreur et sort de la proc�dure d�s la premi�re erreur rencontr�e dans la v�rif. L'ordre des param�tres est choisi de mani�re � minimiser les traitements � ce niveau.
2b) On ne peut pas faire d'assignation dans la boucle, sauf � peupler une table temporaire en insert/select dont les colonnes sont d�finies dans l'ordre des param�tres. Il faut passer par un gestionnaire d'erreur pour traiter les erreurs de type � l'insertion, et en cas d'erreur supprimer la table temporaire et sortir de la proc. Le contr�le de type se fait en une seule passe pour tous les param�tres. Etant en MySQL on ne peut pas faire de contr�le de domaine sur la m�me passe (dommage ).
3a) Je fait un contr�le qualit� variable par variable dans le code.
3b) On peut faire ce contr�le en faisant une requ�te globale bour�e de structures conditionnelles au choix, ou en faisant une requ�te par colonne (contre-productif pour ce dernier choix). Ici tu n'as pas le choix, on est en MySQL je le rappele (pas de contrainte CHECK sur la table).

Je pense que l'essentiel y est. Quelques remarques personnelles si tu me le permets.
- Bien que le nombre d'instructions de contr�le soient identiques dans ces deux cas de figure, le nombre de requ�tes est limit�e � sont strict minimum avec ta solution.
- Le fait qu'il s'agisse d'un insert sur une seule ligne, la validation de masse que permets ta m�thode est � pond�rer fortement je pense.
- Ma m�thode permets l'encapsulation totale du process et ne sollicite pas de pose de verou quelconque durant le process de v�rification.
- Concernant la tienne, �tant oblig� de travailler dans un contexte transactionn� d�s l'�tape de v�rification, � moins de g�n�rer un nom de table temporaire al�atoirement, je ne vois pas comment tu peux �viter le risque de contention autrement dans un contexte fortement concurrentiel.
Bien que l'on travaille uniquement sur une seule ligne, je pense que ton taux d'occupation RAM de ta m�thode risque de ne pas avoir une courbe lin�aire avec une augmentation des acc�s concurrentiels non plus.

EDIT: J'oubliais! A cause de l'obligation de passer en mode transactionnel d�s la v�rification des param�tres dans ta m�thode, tu as l'avantage d'avoir une trace des tentatives d'insert dans le log binaire. Mais cela peut �tre un inconv�nient selon le CDC, et va augmenter la volum�trie du log.


Je pense qu'on a l� une bonne base de discussion

[ericd69]

je te rappelle alors le fonctionnement d'une table temporaire...

elle n'est � consid�rer qu'au niveau de la session... donc comme tu ne pourras rien lancer d'autre parle fonctionnement des appels langage serveur/mysql avant la fin de la proc�dure sur cette m�me session... pas de probl�me de concurrence intra-session ou de collision de nom de table...@

en plus, si tu utilise memory tu acc�l�re la table , certes au d�triment du risque de perte si il y a panne du sgbd mais d'un autre c�t� tu t'en fout car le traitement ne serait pas valid� avant le fin de transaction non plus, si tu plantais plus loin dans la proc�dure...


de toute fa�on une table temporaire serait drop�e en cas de panne

la solution est juste un parcours plus simple d'une liste de valeur s�par�e par des virgules
et en effet, �a n'emp�che en rien de faire les traitement souhait� � la vol�e

perso je suis pas trop pour passer les param�tres d'une proc�dure comme �a (� la mode php, qui est surtout utilis�e par beaucoup comme une facilit� et pas comme tu le vois dans les api pour du param�trage complexe de passage de variable � une fonction ou parce que tu as r�ellement besoin d'un tableau simplement), j'utilise un tableau pour passer une liste de valeur d'un typage identique (genre tableau de points par exemple, etc...), ce qui remet �a dans une utilisation plus simple et facile � contr�ler � tous les niveaux...

pour m�moire je te rappel que les transactions ne touchant que les tables innodb, les tables temporaires ne sont pas impact�es par �a... sauf indirectement par des requ�tes les liant � une action sur une table innodb bien sur



le seul d�faut des proc�dures sur mysql c'est qu'elle sont compil�es � la 1�re demande lors de la session et non � la cr�ation au niveau serveur... ce qui leur enl�ve un poil d'efficacit�...

donc apr�s en effet, les 2 techniques trouvent une �quivalence pour certaines situations et des avantages � l'une ou l'autre pour des utilisations plus particuli�res...

apr�s pour les logs c'est vrai que �a se discute surtout si tu as une activit� importante...

[tse_jc]

Bonsoir,

Merci pour ton retour.

D�sol� de te contredire, mais en MySQL une table de type MEMORY n'a pas de visibilit� limit�e � la session utilisateur contrairement aux variables utilisateurs qui elles sont d�truites avec la session utilisateur.

En r�sum�, une table de type MEMORY une fois cr��e, est visible par tous les utilisteurs connect�s sur la BD, et persiste jusqu'� ce qu'un DROP TABLE soit fait dessus, que le serveur crashes, ou jusqu'� ce qu'un mysql -stop ou -restart soit fait.

Tout comme une table innoDB elle est soumise aux acc�s concurentiels au m�me titre que n'importe quel autre table. Elles sont plut�t optimis�es pour du read intensive (usage recommand� ex:cache en lecture) et peu pour du read/write tout court, car elles ne disposent pas de syst�me de verrou au niveau ligne ni ne sont multi thread�s pour limiter la contention au niveau acc�s concurrentiel.

Or dans notre cas de figure qui est de l'insert essentiellement on est dans un contexte o� (si utilis�e)
1) on fait du read/write � 50% et syst�matique.
2) on va mettre les acc�s concurentiels en file d'attente de part sa nature.

[tse_jc]

pour m�moire je te rappel que les transactions ne touchant que les tables innodb, les tables temporaires ne sont pas impact�es par �a... sauf indirectement par des requ�tes les liant � une action sur une table innodb bien sur

Ici ce n'est pas tout � fait vrai. Permets moi de rectifier tes dires.
Il ne faut pas confondre les transactions et la gestion des verrous dans un contexte concurrentiel.
En vulgarisant un peu mais pas trop, une transaction permets de valider un ensemble d'op�rations lecture/ecriture comme une seule action sur la base. La cons�quence pour les verrous est que la transaction va les maintenir en fonction du niveau d'isolation choisie pendant toute la dur�e de la transaction.
Par contre dans un contexte hors transaction (tables myISAM, MEMORY,...) si des op�rations sont men�es sur des tables ne les supportant pas et que des tables innodb sont impliqu�es, les op�rations seront loggu�es mais ne pourront pas �tre consid�r�es comme consistantes pour les op�rations hors tables innodb (et autre moteurs supportant les transactions). Au del� de cela, cela n'emp�che pas les acc�s concurrentiels de survenir, mais � la diff�rence d'une transaction, les verrous seront pos�s le temps des traitements puis seront lib�r�s au m�me titre que sur une table innoDB hors transactionnel.

Il est vrai par rapport � cela que moi m�me j'ai d�rap� un peu niveau language dans mon post pr�c�dent et je m'en excuse aupr�s des puristes, mais le probl�me de la gestion des verous et de contention dans un contexte concurrentiel se pose avec ta solution.

++

[redoran]

@ ericd69

les tutos c'est comme la doc, tu n'est jamais � l'abri d'une erreur...

donc faut manipul� avec prudence ; alors je me demande qui les valides !!!! surtout ceux qui se trouve sur le site developpez.com qui est une r�f�rence dans la mati�re (pour les d�butant , les �tudiants , les amateurs , les experts et ......).
la barre est pouss�e un peut plus haut.
en r�sum� un avis de conduite a tenir ou a suivre pour pallier au ph�nom�ne des injections sql et surtout pas des tutos

[ascito]

allez, pour moi injection, c'est un code qui va faire des choses qui sont "CONTRE NATURE"

mais pour cela, il faut d�j� qu'une de tes requ�tes permette d�ex�cuter le code compromis...

alors vous allez me dire :
$string = 'exec( del * ) '; // donc un code corrompus

echo $string ; pour ma part, je vois pas dans quel cas de figure cela va ex�cuter le code, dsl

A partir du moment, ou tu caste trankil les donn�es, en entr�e et en sortie, dans un typage simple de donn�es int, string , bool par exemple, je vois pas � quel moment ton code pourra devenir "CONTRE NATURE" ???

[ericd69]

@tse_jc
erreur de ta part, mon cher tse_jc:

Une table temporaire sera imm�diatement effac�e d�s que la connexion se termine. Cela signifie que vous pouvez utiliser le m�me nom de table temporaire depuis deux connexions diff�rentes sans risque de conflit entre les connexions. Vous pouvez aussi utiliser une table temporaire qui a le m�me nom qu'une table existante (la table existante est alors cach�e tant que dure la table temporaire).

j'ai bien dit: "une table temporaire avec le moteur memory"
extrait de la doc

apr�s, je suis pas ultra pointu en transactionnel SGBD subtile, mais je te rassure j'ai suffisamment bouff� de programmation processus, threads et autres s�maphores en c/c++ (linux et windows) pour bien saisir les concepts bas niveaux derri�re

mais je crois qu'on a gravement d�riv� du sujet de base


@ascito
l� encore on revient � ce que moi ou tse_jc on a d�j� dit
�a d�pend ce que tu vises...

tu peux passer une chaine de caract�re qui ne fera � priori rien en php mais qui une fois interpr�t�:

• en sql va permettre de s'attaquer � la bd...
• en html va inclure du code malveillant

tiens une faille que pas tant de gens connaissent:
beaucoup de fonction cod�es en c en dessous interpr�tent un caract�re dont le code ascii vaut 0 comme une fin de chaine mais pas php

si je remplace un de tes formulaires pour tenter de charger un fichier sur ton serveur parce que ton script le permet...

Code php :

S�lectionner tout - Visualiser dans une fen�tre � part

echo"machin.php\0truc.jpg";

�a affiche bien:

machin.php.truc.jpg

mais en fait pas mal de commandes li�es aux fichiers vont voir:

machin.php

j'ai retest� cette vuln�rabilit� avec la version 5.3.9 de php, elle ne passe plus mais il faut se m�fier avec des versions ant�rieures...
d'o� ne jamais croire l'extension d'un fichier et toujours d�truire un fichier dont le nom contient un \0 (l� tu peux �tre sur que c'est pas ce que �a dit �tre)
toujours mettre les fichiers upload�s dans un r�pertoire ou l'ex�cution est impossible, jamais � 777 comme on le voit dans certains scripts
ne jamais faire d'actions sur les fichiers via un script qui prends le nom du fichier (ou dossier) en $_POST ou $_GET sans moult pr�cautions et v�rification

autre truc pas toujours connu le r�glage du php pour la g�n�ration automatique des variables venant de donn�es externes($_POST, $_GET, ...)
� la g�n�ration de ces tableaux super globaux tu as selon le r�glage �ventuellement la g�n�ration automatiques de tout un tas de variables:
$_GET['user'] ou $_POST['user'] vont automatiquement g�n�rer une variable $user...
c'est sens� facilit� la vie des programmeurs mais en fait c'est juste un trou de s�curit�
car admettons que tu n'initialises pas syst�matiquement la valeur de $user de ton code je te fais pas un dessin de ce qui se passe � l'utilisation...
donc ne jamais utiliser de variable sans les initialiser syst�matiquement

voil� des exemples d'injection de valeur cot� php

tu as m�me une faille majeur de s�curit� qui permet de lire le code php sur des sites qui ex�cutent php en mode cgi au lieu d'ex�cuter le code... lire �a en anglais

on pourrait citer plein d'autres choses mais �a ira bien d�j�

bref c'est pas parce que tu ne vois pas forc�ment

ah oui, toujours mettre un index.html m�me vide dans tous les r�pertoires ou faire un .htacces � la racine du site qui emp�che de lister ce qu'il y a dans les r�pertoires...

si on sait faire utiliser l'url rewriting et utiliser de fausses extensions (html au lieu de php par exemple) ou aucune pour emp�cher le mec de facilement savoir quel langage tu utilises...

[tse_jc]

j'ai bien dit: "une table temporaire avec le moteur memory"

Tu sais quoi? je n'avais pas vu que tu parlais d'une table temporaire (je ne savais pas non plus que l'on pouvait en faire en MySQL) et non d'une table simple de type MEMORY. Pourtant tu l'as bien �crit et plus d'une fois.... On a donc raison tous les deux, sauf que l'on ne parlait pas de la m�me chose. Vraiment d�sol�. Bref, �a fera de la lecture pour certains.^^

Maintenant le probl�me de verous � la v�rification lev� avec ta solution, je vais reconsid�rer la chose.
Ceci mis � part, d�velopper en SGBDR �pais avec MySQL reste encore un bien grand mot, et n'est pas toujours possible � 100%.

[grunk]

autre truc pas toujours connu le r�glage du php pour la g�n�ration automatique des variables venant de donn�es externes($_POST, $_GET, ...)
� la g�n�ration de ces tableaux super globaux tu as selon le r�glage �ventuellement la g�n�ration automatiques de tout un tas de variables:
$_GET['user'] ou $_POST['user'] vont automatiquement g�n�rer une variable $user...
c'est sens� facilit� la vie des programmeurs mais en fait c'est juste un trou de s�curit�

Register_global est obsol�te depuis php 5.3.0 et supprim� depuis php 5.4.
Le r�glage par d�faut est sur off depuis la 4.2.0 , soit un peu plus de 10 ans maintenant , on est je pense tranquil de ce cot� l�