8768 sujets

Développement web côté serveur, CMS

Bonjour bonjour, comment allez-vous ?
J'en viens faire appel à votre aide car je butte sur un problème d'apostrophe.

Donc voilà je vais vous expliquer en quelques mots...
J'ai un petit formulaire comprenant juste 2 champs: "name" & "comments".
Lors de l’envoi il appel un script .PHP qui injecte ces informations dans une base de donnée SQL.

Tout va bien sauf que si l'on insère un apostrophe il n'injecte absolument rien dans la base de donnée.
Et si je rentre un dièse dans un des deux champs il supprime tout le texte qui se situe après le dièse.

Voici ma page avec le formulaire comprenant le script qui appel la fonction .PHP
<script>

	function commentSubmit(){
		
		var name = form1.name.value;
		var comments = form1.comments.value;
		var xmlhttp = new XMLHttpRequest();

		
xmlhttp.onreadystatechange = function(){ 
if(xmlhttp.readyState==4&&xmlhttp.status==200){
document.getElementById('comment_logs').innerHTML = xmlhttp.responseText; 
}
}
xmlhttp.open('GET', 'includes/insert.php?name='+name+'&comments='+comments, true); 
xmlhttp.send();
}
		
</script>

<form name="form1">
<input type="text" name="name" placeholder="Name..."/></br></br>
<textarea name="comments" placeholder="Leave Comments Here..." style="width:635px; height:100px;"></textarea></br></br>
<a href="#" onClick="return commentSubmit()" class="button">Post</a></br>
</form>


Et voici mon script .PHP:

<?php



			$name = $_REQUEST['name'];
			$comments = $_REQUEST['comments'];
			
			require("../db/db.php");

			mysqli_query($con, "INSERT INTO comments(name, comments) VALUES('$name','$comments')");

			$result = mysqli_query($con, "SELECT * FROM comments ORDER BY id ASC");
			while($row=mysqli_fetch_array($result)){
			echo "<div class='comments_content'>";
			echo "<h4><a href='includes/delete.php?id=" . $row['id'] . "'> X</a></h4>";
			echo "<h1>" . $row['name'] . "</h1>";
			echo "<h2>" . $row['date_publish'] . "</h2></br></br>";
			echo "<h3>" . $row['comments'] . "</h3>";
			echo "</div>";
			}
			mysqli_close($con);


?>


Comment puis-je faire ?
Je vous en serait très reconnaissant si vous pouvez me mettre sur le bon chemin. Merci
Modifié par gamenumi (02 Sep 2015 - 10:45)
salut,
je pense que le meilleur chemin que tu puisses prendre est celui qui mène vers l'objet PDO.
En ce qui concerne ton code, c'est normal que ça plante vu que tu intègres pêle-mêle les données entrées par l'utilisateur. Tu n'es entrain de prendre aucune précaution. Au passage, si tu mets ton site en ligne avec ce code, je peux t'assurer que tu feras le bonheur des hackeurs en herbe...
Avec PDO, tu as la méthode quote qui permet de protéger les strings. ON peut faire encore mieux en utilisant les requêtes préparées.

Si tu tiens à rester avec mysqli, il doit y avoir une fonction équivalente à quote.


La méthode quote ajoute des apostrophes au début et à la fin de la chaîne, puis échappe le contenu pour éviter tout risque d'injection. Ca comprend convertir les ' en \' mais pas que.

Convertir toi-même les ' en \' ne te protégera pas à 100%, c'est pour ça que c'est plus que déconseillé et qu'on te propose des méthodes spécialisées. IL existe d'autres petites combines que de jouer avec les apostrophes pour réussir une injection.
Zelalsan a écrit :
salut,
je pense que le meilleur chemin que tu puisses prendre est celui qui mène vers l'objet PDO.
En ce qui concerne ton code, c'est normal que ça plante vu que tu intègres pêle-mêle les données entrées par l'utilisateur. Tu n'es entrain de prendre aucune précaution. Au passage, si tu mets ton site en ligne avec ce code, je peux t'assurer que tu feras le bonheur des hackeurs en herbe...


QuentinC a écrit :
Avec PDO, tu as la méthode quote qui permet de protéger les strings. ON peut faire encore mieux en utilisant les requêtes préparées.

Si tu tiens à rester avec mysqli, il doit y avoir une fonction équivalente à quote.


La méthode quote ajoute des apostrophes au début et à la fin de la chaîne, puis échappe le contenu pour éviter tout risque d'injection. Ca comprend convertir les ' en \' mais pas que.

Convertir toi-même les ' en \' ne te protégera pas à 100%, c'est pour ça que c'est plus que déconseillé et qu'on te propose des méthodes spécialisées. IL existe d'autres petites combines que de jouer avec les apostrophes pour réussir une injection.


N'écoute pas ces 2 chèvres.

Que tu utilises msqli ou pdo pour gérer ton accès à ta base de données ne change rien à la manière de protéger tes requêtes contre les injection SQL.

Avec mysqli tu utilises la méthode escape_string (https://secure.php.net/manual/fr/mysqli.real-escape-string.php) ou la méthode prepare pour faire des requêtes préparées (https://secure.php.net/manual/fr/mysqli.prepare.php).

Avec PDO c'est pareil mais tu utilises PDO::quote ou PDO::prepare pour obtenir un résultat similaire.

La seule différence est que le pilote msqli va communiquer avec les fonctions natives de mysql qui peuvent être parfois plus efficaces, tandis que PDO va utiliser une couche d'abastraction qui parfois se gauffre.

Si tu n'utilises que MySQL comme moteur de base de données, reste avec Mysqli, il est plus efficace que PDO.
a écrit :
N'écoute pas ces 2 chèvres.


Merci... ça fait toujours plaisir.


a écrit :
La seule différence est que le pilote msqli va communiquer avec les fonctions natives de mysql qui peuvent être parfois plus efficaces, tandis que PDO va utiliser une couche d'abastraction qui parfois se gauffre.


Je serais curieux de savoir à quel moment et comment il se gaufre. Ca fait 10 ans que j'utilise PDO sur tous mes sites personnels et je n'ai jamais eu aucun problème.

a écrit :
Si tu n'utilises que MySQL comme moteur de base de données, reste avec Mysqli, il est plus efficace que PDO.


Ca ça reste à prouver, c'est quoi tes sources ?

ET puis de toute manière la différence, s'il y en a une, est probablement très insignifiante. Le temps incompressible nécessaire pour communiquer avec le serveur SQL et exécuter effectivement les requêtes est infiniment plus grand que quelques tours de passes-passes de la VM php. A moins d'avoir des millions de visiteurs par jour, ça n'a probablement aucun impact perceptible.


Tu noteras quand même que PDO est officiellement la méthode recommandée depuis plus de 10 ans, pas mysqli. Même si mysqli a échappé à la dépréciation puis la suppression définitive (contrairement à mysql_*), ce n'est à mon avis qu'une question de temps avant qu'il ne disparaisse à son tour. Ca ne sert à rien d'avoir deux API fournies de base qui font la même chose.
Bonjour,
Justsix a écrit :
N'écoute pas ces 2 chèvres.


Un peu de politesse ne fait jamais de mal, ton insulte est évidemment intolérable mais surtout non justifié, ce n'est pas comme si les deux premiers Alsanautes avait répondu à côté de la plaque.
QuentinC a écrit :

Je serais curieux de savoir à quel moment et comment il se gaufre


PDO utilises une couche logiciel côté client pour émuler certaines fonctionnalités quand elles ne sont pas présentes sur le SGBD utilisés. Par exemple, si le SGBD ne gère pas les requêtes préparées, PDO va utiliser une émulation logicielle pour les simuler.

Il suffit de voir l'histoire de PHP et de la sécurité pour se rendre compte que c'est une mauvaise idée de compter sur PHP pour gérer ce genre de chose de manière logicielle. A moins que tu ais oublié les super addslashes, magic_quote, mysql_escape_string vs mysql_real_escape_string et compagnie.

QuentinC a écrit :

Ca fait 10 ans que j'utilise PDO sur tous mes sites personnels et je n'ai jamais eu aucun problème.


Joli protocole de test.

Justsix a écrit :

Si tu n'utilises que MySQL comme moteur de base de données, reste avec Mysqli, il est plus efficace que PDO.


QuentinC a écrit :

Ca ça reste à prouver, c'est quoi tes sources ?


La doc de PHP sur la page qui décrit les fonctionnalités des différents pilotes pour MySQL.

QuentinC a écrit :

ET puis de toute manière la différence, s'il y en a une, est probablement très insignifiante. Le temps incompressible nécessaire pour communiquer avec le serveur SQL et exécuter effectivement les requêtes est infiniment plus grand que quelques tours de passes-passes de la VM php. A moins d'avoir des millions de visiteurs par jour, ça n'a probablement aucun impact perceptible.


Tu extrapoles, je n'ai pas parlé de performances en terme de vitesse.

QuentinC a écrit :

Tu noteras quand même que PDO est officiellement la méthode recommandée depuis plus de 10 ans, pas mysqli.


Total bullshit à la mode Web 2.0. Tu inventes n'importe quoi (ou alors tu mens).

La documentation de PHP est explicite sur ce point et c'est la seule déclaration officielle que tu trouveras sur le sujet :

http://php.net/manual/fr/mysqlinfo.api.choosing.php

Je cite :

PHP.net a écrit :

API recommandé :

Il est recommandé d'utiliser soit l'extension mysqli, soit l'extension PDO_MySQL. Il n'est pas recommandé d'utiliser l'ancienne extension mysql pour de nouveaux développements sachant qu'elle est obsolète depuis PHP 5.5.0, et sera supprimée dans un futur proche.


Et c'est tout ! Il n'y aucune autre référence dans la documentation qui favorise explicitement l'une au l'autre des API quand on utilise MySQL.

QuentinC a écrit :

Même si mysqli a échappé à la dépréciation puis la suppression définitive (contrairement à mysql_*), ce n'est à mon avis qu'une question de temps avant qu'il ne disparaisse à son tour. Ca ne sert à rien d'avoir deux API fournies de base qui font la même chose.


Encore du pur bullshit 2.0 du type qui utilise des références imaginaires en les servant avec conviction dans le but de faire passer une idée.

La documentation officielle est encore clair sur ce point et te donne à nouveau tort :

extension msqli :

Statut du développement : Active
Cycle de vie : Active
Recommandé pour de nouveaux projets : Oui

extension PDO :

Statut du développement : Active
Cycle de vie : Active
Recommandé pour de nouveaux projets : Oui

Tout est là, il suffit de lire pour se rendre compte que tu racontes justes des conneries. T'es quoi ? Un genre de fanboy PDO ? T'as des trucs à vendre à tes followers ?

SolidSnake a écrit :

Un peu de politesse ne fait jamais de mal, ton insulte est évidemment intolérable mais surtout non justifié, ce n'est pas comme si les deux premiers Alsanautes avait répondu à côté de la plaque.


Si, justement ils ont répondu plus quà côté de la plaque en expliquant au type qu'il devait changer tout son code pour le remplacer par un truc qui ne fait rien de plus que celui qu'il utilise déjà. Le tout sous des pretextes complètement bidons.

Et chèvre n'est pas une insulte, c'est le truc qui se trouve juste au dessus du mouton dans la hierarchie des crétins 2.0. Tu vois si j'avais voulu être insultant j'aurais dit "mouton" ou pire "pelouse" (le truc juste en dessous).
Modifié par Justsix (11 Sep 2015 - 23:42)
a écrit :
PDO utilises une couche logiciel côté client pour émuler certaines fonctionnalités quand elles ne sont pas présentes sur le SGBD utilisés. Par exemple, si le SGBD ne gère pas les requêtes préparées, PDO va utiliser une émulation logicielle pour les simuler.
Il suffit de voir l'histoire de PHP et de la sécurité pour se rendre compte que c'est une mauvaise idée de compter sur PHP pour gérer ce genre de chose de manière logicielle. A moins que tu ais oublié les super addslashes, magic_quote, mysql_escape_string vs mysql_real_escape_string et compagnie.


Ca ne change pas grand chose. Si on admet que la fonctionnalité X n'est pas supportée par MySQL, elle est donc présente et émulée en PDO mais totalement absente de mysqli d'après ce que tu dis.
Quelle différence il y a entre émuler toi-même la fonctionnalité au-dessus de mysqli ou utiliser l'émulation existante dans PDO ? Est-ce que tu es vraiment sûr de produire du code plus sécurisé ?

OU alors tu ne fais pas confiance au langage que tu utilises. Certes le passé de PHP est mouvementé et il a toujours un peu cet aspect langage de bricoleur, mais je pense qu'on peut tout de même honnêtement considérer qu'ils ont sérieusement décidé de se débarrasser de cette mauvaise réputation depuis PHP 5.3.
Ce n'est pas pour rien que tout ce que tu cites ci-dessus est déprécié depuis bien longtemps...

a écrit :
Tu extrapoles, je n'ai pas parlé de performances en terme de vitesse.


Alors sois plus précis et explicite; décris mieux tes pensées et tes arguments. Désolé mais c'était pas clair.


a écrit :
La documentation de PHP est explicite sur ce point et c'est la seule déclaration officielle que tu trouveras sur le sujet :
http://php.net/manual/fr/mysqlinfo.api.choosing.php

Je cite :
Il est recommandé d'utiliser soit l'extension mysqli, soit l'extension PDO_MySQL. Il n'est pas recommandé d'utiliser l'ancienne extension mysql pour de nouveaux développements sachant qu'elle est obsolète depuis PHP 5.5.0, et sera supprimée dans un futur proche.

Et c'est tout ! Il n'y aucune autre référence dans la documentation qui favorise explicitement l'une au l'autre des API quand on utilise MySQL.


OK, j'admets effecctivement m'être trompé sur ce point, et du coup ça invalide aussi le point suivant, mysqli ne disparaîtra pas maintenant. Ca ne justifie toutefois pas de me traiter de chèvre ou de bullshiter.
Comme l'adage le dit si bien, errare humanum est. Pas besoin de s'affoler pour ça et il y avait sûrement une façon plus courtoise de me montrer mon erreur.

Ceci dit pour ma défense, dans mon message initial, je n'ai rien explicitement dit contre mysqli, et je n'ai jamais dit non plus que le PO devait refaire tout son code.

Par contre, je maintiens, avoir deux API qui font à peu près la même chose est à terme un embarassement inutile. Ca ne serait pas surprenant qu'un jour, une des deux disparaisse.
Ceux qui font PHP ne sont pas aussi sympas que Java en ce qui concerne la rétrocompatibilité.

a écrit :
Tout est là, il suffit de lire pour se rendre compte que tu racontes justes des conneries. T'es quoi ? Un genre de fanboy PDO ? T'as des trucs à vendre à tes followers ?


Je préfère ne pas commenter cette provocation gratuite.

Je crois bien que je t'ai reconnu, laisse-moi retrouver un peu ton ancien pseudo...
JE me disais bien qu'attaquer les gens de cette façon dès son premier post, c'était louche.
Ah, les boulets qui persistent à faire du multicompte; quelle plaie.
Modifié par QuentinC (12 Sep 2015 - 08:46)
Justsix a écrit :
N'écoute pas ces 2 chèvres.

Justsix a écrit :
Et chèvre n'est pas une insulte, c'est le truc qui se trouve juste au dessus du mouton dans la hierarchie des crétins 2.0. Tu vois si j'avais voulu être insultant j'aurais dit "mouton" ou pire "pelouse" (le truc juste en dessous).

Encore un frustré de la vie...
C'est le même le discours quand tu es en face des gens ?
Je suppose que tes références de berger te jouent des tours et que tu serais pris de vertiges à l'idée de tenir un discours moins proche du sol.

J'espère vraiment que tu n'as pas plus de 15 ans.
Justsix a écrit :
Total bullshit...

Justsix a écrit :
Encore du pur bullshit

Justsix a écrit :
[...] Un genre de fanboy PDO ? T'as des trucs à vendre à tes followers ?


J'imagine que QuentinC est déjà très poli pour avoir répondu.

Pour argumenter tout de même le choix PDO, ce dernier prend en charge différents pilotes de SGBD là où mysqli ne gère que MySQL. Un autre avantage avec PDO est la gestion de paramètres nommés.
Question performances, cela dépend des cas mais ils sont sensiblement identiques.

On peut tout de même ne pas être d'accord sans tomber dans la vileté.
gamenumi a écrit :
(...)
xmlhttp.onreadystatechange = function(){ }
(...)
Bonjour Gamenumi,
ne faudrait-il pas mieux écrire :
xmlhttp.open('GET', 'includes/insert.php?name='+name+'&comments='+comments, true);
comme ceci :
xmlhttp.open('GET', 'includes/insert.php?name='+name+' & comments='+comments+' ', true);
comments='+comments+' (ici rectifié) posait problème ?
Modifié par pictural (17 Sep 2015 - 11:20)