+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : injections SQL : caractères utilisés, ôter moi un doute (/showthread.php?tid=204)
RE: injections SQL : caractères utilisés, ôter moi un doute - Sephi-Chan - 07-01-2011
Exact, mieux vaut utiliser htmlspecialchars pour empêcher le XSS.
En revanche, la remarque sur la corruption des données reste vraie : comme leur nom l'indique, les fonctions html* sont faîtes pour filtrer les chaînes de caractères quand elles sont affichées au sein d'un document HTML.
Sephi-Chan
RE: injections SQL : caractères utilisés, ôter moi un doute - php_addict - 12-01-2011
(07-01-2011, 09:01 PM)Sephi-Chan a écrit : Exact, mieux vaut utiliser htmlspecialchars pour empêcher le XSS.
En revanche, la remarque sur la corruption des données reste vraie : comme leur nom l'indique, les fonctions html* sont faîtes pour filtrer les chaînes de caractères quand elles sont affichées au sein d'un document HTML.
salut, je me permet de revenir sur ce sujet
effectivement j'ai fait une grosse boulette en corrompant les données de ma bdd...j'avous qu'avec un framework cela n'aurait pas été le cas...
pouvez vous me corriger si je fais une nouvelle boulette svp? :
1) mes $_POST $_GET et $_COOKIES
je les passe automatiquement et systématiquement dans la moulinette suivante ,equivalent de mysql_real_escape_string() car ces données seront utilisées dans les requetes SQL (à part quelques cas exceptionnels comme le renvois de données <textarea> lors d'une erreur de formulaire par exemple)
function encodage($chaine)
{
$search=array("\\","\0","\n","\r","\x1a","'",'"');
$replace=array("\\\\","\\0","\\n","\\r","\Z","\'",'\"');
return(str_replace($search,$replace,$chaine));
}
2) affichage en HTML des données issues de la base de donnée:
avant affichage je passe les données dans cette moulinette:
function bdd2html($chaine)
{
$chaine=htmlspecialchars($chaine, ENT_QUOTES, 'UTF-8');
return($chaine);
}
j'ai bon ?
je veux dire contre injection SQL et XSS ?bonne journée
PS réédité...
RE: injections SQL : caractères utilisés, ôter moi un doute - Sephi-Chan - 12-01-2011
Pourquoi réécrire ladite moulinette ?
Pourquoi addslashes à l'affichage ?
Sephi-Chan
RE: injections SQL : caractères utilisés, ôter moi un doute - NicoMSEvent - 12-01-2011
J'ai une question (qui parait bête, mais qui je crois a du sens) :
Vaut-il mieux traiter contre les injections SQL :
1°)toutes les entrées utilisateurs (POST, GET, COOKIE, ...) ?
2°)chaque variable séparément?
3°)Le faire dans une méthode qui va utiliser la DB? (accès uniquement à la DB via cette méthode)
J'ai commencé la méthode 2, mais c'est pas facilement maintenable. La méthode 1 me semble un peu trop radicale, et la méthode 3, je ne vois pas trop comment l'implémenter. P-e via les requêtes préparées?
Et donc, implicitement, il faudrait avoir une méthode de rendu qui ferait un htmlentites de tout SELECT destiné a l'affichage?
RE: injections SQL : caractères utilisés, ôter moi un doute - Sephi-Chan - 12-01-2011
Pour implementer la methode 3, il faut une couche d'accès au données (ce que les frameworks font).
Quant à l'affichage, il suffit de filtrer au niveau de la vue. Au lieu de faire un echo de ta variable, tu fais un echo du htmlspecialchars de ta variable.
RE: injections SQL : caractères utilisés, ôter moi un doute - php_addict - 12-01-2011
(12-01-2011, 11:05 AM)Sephi-Chan a écrit : Pourquoi réécrire ladite moulinette ?je sais pas...tu mettrait mysql_real_escape_string() toi ?
(12-01-2011, 11:05 AM)Sephi-Chan a écrit : Pourquoi addslashes à l'affichage ?
oui me suis planté encore une fois..., je réédite mon post...
RE: injections SQL : caractères utilisés, ôter moi un doute - Sephi-Chan - 12-01-2011
Dans la mesure où ta fonction reproduit un comportement existant, autant utiliser la fonction native. De plus la tienne est mal nommée.
Sephi-Chan
RE: injections SQL : caractères utilisés, ôter moi un doute - Holy - 12-01-2011
(12-01-2011, 11:12 AM)NicoMSEvent a écrit : 1°)toutes les entrées utilisateurs (POST, GET, COOKIE, ...) ?
Dans tous les cas tu devras spécifier au cas par cas le type de sécurisation à faire (intval() ou escape()). Voilà une piste pour avoir un système facilement maintenable, selon moi :
<?php
extpost(
array(
'name' => 'NicoMSEvent'
'#id'
);
echo $id; // Revient à $_POST['id']
echo $sql_id; // Variable sécurisé par intval grâce à la dièse (#)
echo $name; // Revient à $_POST['name'];
// Si $_POST['name'] est vide, il prendra la valeur 'NicoMSEvent'
echo $sql_name; // Variable sécurisé par mysqli_escape...
?>Ca permet de ne pas devoir réécrire à chaque fois les fonctions de sécurisation ^^
RE: injections SQL : caractères utilisés, ôter moi un doute - Sephi-Chan - 12-01-2011
Je trouve votre approche bizarre…
Quelle drôle d'habitude que de transformer les données qu'on vous transmet quel que soit son usage.
Vous traitez (ou maltraitez ^^) de la même façon les chaînes à destination d'une base de données, de services Web, etc.
L'échappement pour MySQL doit se faire au moment d'une requête à MySQL, non ?
Sephi-Chan
RE: injections SQL : caractères utilisés, ôter moi un doute - Holy - 12-01-2011
(12-01-2011, 02:50 PM)Sephi-Chan a écrit : Je trouve votre approche bizarre…J'dois mal comprendre, mais y a quoi qui empêche qu'y ait une requête SQL derrière ? Que je sécurise mes variables dans ma requête ou trois lignes avant, c'est la même chose, non ?
Quelle drôle d'habitude que de transformer les données qu'on vous transmet quel que soit son usage.
Vous traitez (ou maltraitez ^^) de la même façon les chaînes à destination d'une base de données, de services Web, etc.
L'échappement pour MySQL doit se faire au moment d'une requête à MySQL, non ?
Sephi-Chan
Et en l'occurrence, j'ai bien un traitement différencié puisque la fonction crée deux variables automatiquement. Alors oui, je perds sûrement un millième de performance parce que je n'utilise pas systématiquement $sql_var ou $var, mais ça reste fonctionnel et pratique ^^.