8791 sujets

Développement web côté serveur, CMS

Pages :
Désolé, j'ai encore une question de gros débutant du PHP:

dans un champ input type="texte", je saisis par exemple: hello "coco"

en local je récupère bien hello "coco" dans la base Mysql, par contre sur le serveur d’hébergement Amen, tout ce qui est après le premier " disparaît, c'est à dire que je récupère hello.

c'est une histoire de config ???

comme quoi faut pas toujours crier victoire quand tout marche en local, et se dire "je vais vous transférer tout ça sur le serveur en 5mn" lol

je précise que j'ai le magic_quote_gpc à OFF des deux cotés.

merci
en fait, je dis une connerie

quand je saisis, ça va, les " sont enregistrés.

c'est quand j'ouvre un formulaire de modification que le champ s'affiche tronqué, aussi bien en local qu'en distant.

voici ma requête (j'ai coupé du code)

if(isset($_GET['id']))	{

	$id = $_GET['id'];
	$sql = "SELECT * FROM concerts WHERE id ='$id'";
	
	$result = $ma_connexion->query($sql);
	$error = $ma_connexion->errorInfo();
	if (isset($error[2])) die($error[2]);
	$numrows = $result->rowCount();
	
	$result->setFetchMode(PDO::FETCH_OBJ);
	while( $ligne = $result->fetch() )
	{
		$frontpage = $ligne->frontpage;
		$titre = $ligne->titre;
		$image1 = $ligne->image1;
		$image2 = $ligne->image2;
		$soustitre1 = $ligne->soustitre1;
		$soustitre2 = $ligne->soustitre2;
		$jour = $ligne->jour;
		$mois = $ligne->mois;
		$horaire = $ligne->horaire;
		$payant = $ligne->payant;
		$adh = $ligne->adh;
		$loc = $ligne->loc;
		$surplace = $ligne->surplace;
		$texte1 = $ligne->texte1;
		$texte2 = $ligne->texte2;
		$ordre = $ligne->ordre;
	}
	$result->closeCursor();


et voici comment j'affiche un champ (titre ici)

<p><label for="titre">Titre</label>
<input type="text" id="titre" name="titre" value="<?php echo utf8_encode($titre); ?>" size="60" /></p>


je rajoute: il n'y a pas ce problème avec les input type textarea
Modifié par lionel_css3 (21 Aug 2012 - 22:10)
j'ai l’impression que je commence à comprendre, en fait il faudrait que j'affiche comme ceci par exemple?
echo htmlentities($_POST['titre'], ENT_COMPAT, 'UTF-8');

comme c'est le cas dans le formulaire de saisie (quand je réaffiche les contenus des champs en cas de formulaire incomplet).

par contre ça ne semble pas géner dans le cas d'un affichage dans une balise comme ici

<h2><?php echo utf8_encode($row['titre']); ?></h2>


je vais essayer....

merci pour le tuyau
Voila.... c'était ça..........! grâce à toi, maintenant je sais vraiment à quoi sert cette fonction htmlentities.

Merci, Jo_link_noir !!!

PS: super efficace, ce forum....
jb_gfx a écrit :
Sauf que c'est htmlspecialchars pas htmlentities...



ah bon?

pourtant, htmlentities semble résoudre mon problème..

je crois qu'il faudra que je fasse le point demain matin à tête reposée lol
htmlentities remplace les caractères réservés en html mais aussi les lettres accentuées, alors que htmlspecialchars ne remplace que les caractères réservés (ce qui est bien mieux).

En passant n'hésite pas à te créer un petit helper :


function e($string, $charset = 'UTF-8') {
  echo htmlspecialchars($string, ENT_COMPAT, $charset);
}


edit: s/reversés/réservés
Modifié par Felipe (26 Aug 2012 - 19:38)
en fait mon problème n'est pas résolu du tout.

dans mes pages php qui gèrent l'envoi des formulaires de saisie, j'ai employé une requête préparée PDO après avoir lu que c'était le top et que ça protégeait automatiquement de l'injection sql

voici ma requête en gros


  $host = 'localhost';
  $db = 'rocksane';
	$user = 'root';
	$pwd = '';
  
  
    try {
      $ma_connexion = new PDO("mysql:host=$host;dbname=$db", $user, $pwd);
    } catch (PDOException $e) {
      echo 'Cannot connect to database';
      exit;
    }


	$sql = "UPDATE slider SET ordre = ?, actif = ?, image = ?, legend = ?, link = ? WHERE id = ?";
	$stmt = $ma_connexion->prepare($sql);
	$stmt->execute(array($_POST['ordre'], $_POST['actif'], utf8_decode($leFichier), utf8_decode($_POST['legend']), utf8_decode($_POST['link']), $_POST['id'])); 


et là je me suis amusé à taper <script type="text/javascript">alert('hello'); </script> dans un champ du formulaire qui envoie vers cette requête et surprise, le javascript est exécuté, la boite alert s'affiche à l'écran...

donc y a un problème... dans PDO ... l'injection sql est permise..

étant donné que ce problème touche toutes les pages php qui ont des formulaires, il y a t-il une procédure type à adopter, pour que quelque soit la phase:
- saisie dans un formulaire
- lecture dans du html
- lecture dans un champ de formulaire pour mise à jour
il n'y ait plus de problèmes avec les " , ' , > et < ??

merci
lionel_css3 a écrit :

donc y a un problème... dans PDO ... l'injection sql est permise..


Aucun rapport avec une injection SQL ni avec PDO.

lionel_css3 a écrit :

étant donné que ce problème touche toutes les pages php qui ont des formulaires, il y a t-il une procédure type à adopter


Afficher tes données avec htmlspecialchars comme ça t'a été expliqué juste avant.
Modifié par jb_gfx (22 Aug 2012 - 16:05)
jb_gfx a écrit :

Afficher tes données avec htmlspecialchars comme ça t'a été expliqué juste avant.


alors il faut que je le mette partout, dans chaque zone affichée de chaque page?
parce que là ou il n'y a pas la fonction htmlspecialchars d'employée, ça pose le problème.

c'est fastidieux! ou alors il faudrait faire une fonction $echo-bis(truc) qui fait $echo htmlspecialchars(truc, param, param);

non?

edit: tu as une idée pourquoi j'ai pu faire une injection sql, malgré la requête préparée?
Modifié par lionel_css3 (22 Aug 2012 - 16:14)
lionel_css3 a écrit :


alors il faut que je le mette partout, dans chaque zone affichée de chaque page?
parce que là ou il n'y a pas la fonction htmlspecialchars d'employée, ça pose le problème.

c'est fastidieux! ou alors il faudrait faire une fonction $echo-bis(truc) qui fait $echo htmlspecialchars(truc, param, param);

non?

edit: tu as une idée pourquoi j'ai pu faire une injection sql, malgré la requête préparée?


ça ou une boucle...

PS: si tu parle de scripts JS qui s'execute quand tu affiche le contenu du formulaire, ce n'est pas une injection SQL mais XSS (dangeureux, uniquement sur des messages persistants, forum, goldbook, etc...)
Modifié par JJK801 (22 Aug 2012 - 16:30)
JJK801 a écrit :


ça ou une boucle...


donc, tu réponds oui à ma question?, il faut le mettre partout?


et pour le fait que j'ai réussi à faire une injection sql malgré la requête préparée PDO, tu connaitrais une explication par hasard??

merci

edit: je me suis fait une fonction comme ça:
function lio_fn1($string, $charset = 'UTF-8') {
  echo htmlentities(utf8_encode($string), ENT_QUOTES, $charset);
}


ça a l'air de marcher, mais c'est flou.
avant j'utilisais les fonctions intégrées à Dreamweaver et il fabrique une fonction GetSQLValueString etje crois que ça gère le truc.
Là j'ai voulu tout faire de A à Z et j'en bave Smiley cligne
Modifié par lionel_css3 (22 Aug 2012 - 16:35)
lionel_css3 a écrit :


donc, tu réponds oui à ma question?, il faut le mettre partout?


et pour le fait que j'ai réussi à faire une injection sql malgré la requête préparée PDO, tu connaitrais une explication par hasard??

merci


Les injection XSS (avec su JS) et les injection SQL, ce n'est pas du tout la même chose, si tu veut te protéger des injections XSS sans te "faire chier":


foreach($_POST as $key => $value)
{
  if(is_string($value))
  {
    $_POST[$key] = htmlspecialchars($value);
  }
}


bien sur, il faut le faire, avant de rentrer tes données en base, sinon, tu doit le faire a chaque affichage...

PS: a mon avis, c'est tout ton script qui est a revoir ainsi que ton model de BDD (a en juger par la préparation de ta requête, avec des utf8_decode et compagnie)
Modifié par JJK801 (22 Aug 2012 - 16:42)
ceci dit, toutes les pages en questions ne sont accessibles que par mot de passe, y pas grand risque, mais autant faire les choses bien.

donc tu me conseilles de 'traiter' les chaines après soumission du $_POST , juste avant la requête, ok, je vais essayer..

merci
lionel_css3 a écrit :
ceci dit, toutes les pages en questions ne sont accessibles que par mot de passe, y pas grand risque, mais autant faire les choses bien.

donc tu me conseilles de 'traiter' les chaines après soumission du $_POST , juste avant la requête, ok, je vais essayer..

merci


Si ce sont des données provenant d'un utilisateur et ayant pour vocation d'être afficher a d'autres utilisateurs, les traiter avant de les stocker parait la meilleur solution.

Sinon pour info la préparation des requêtes protége bien des injections SQL Smiley cligne
JJK801 a écrit :

bien sur, il faut le faire, avant de rentrer tes données en base, sinon, tu doit le faire a chaque affichage...


Jamais de la vie. Smiley smile

C'est le rôle de la vue d'échapper les données. Sinon tu te retrouves avec un truc impossible à gérer.
Modifié par jb_gfx (22 Aug 2012 - 16:57)
jb_gfx a écrit :
Jamais de la vie. Smiley smile

C'est le rôle de la vue d'échapper les données. Sinon tu te retrouves avec un truc impossible à gérer.

C'est clair. Et le jour où tu veux afficher tes données ailleurs que dans une page HTML, c'est la joie...
Pages :