Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5

sécurité formulaire dans UDT
#1

Citation :#~~~~~ DEBUT BLOC A NE PAS SUPPRIMER ~~~~~
#~ Version du CMS: #1.10.2
#~ Url du site :
#~ Hébergeur / Soft :
#~ Informations Système :
#~~~~~ FIN BLOC A NE PAS SUPPRIMER ~~~~~


Bonjour à tous,

Une question surement un peu bête...
En règle générale, sur cmsms, quelle est la meilleure façon de sécurier des données envoyées par formulaire puis, insérées dans la base de donnée, sachant que le formulaire et le traitement se fait dans une UDT?

merci de vos lumières
Répondre
#2

ça date un peu, mais c'est toujours valable :
http://www.phpsecure.info/v2/article/Mai...Inject.php

De plus il faut "nettoyer" les données $_POST

http://fr.php.net/manual/fr/book.filter.php

il y a aussi des nettoyages manuels du style strip_tags, htmlspecialchars() , htmlentities().

{SEO}
Inscrivez-vous à notre Newsletter sur le site (colonne de droite, en bas).
Vous appréciez CMSMS et l'aide qui vous est fournie ici, aidez-nous en participant au projet.
Formation CMS Made Simple | Création de site CMS Made Simple.

C'est en se plantant qu'on devient cultivé.
J'ai un string dans l'Array (Paris Hilton)
Répondre
#3

lorsqu'on utlise des fonctions comme celle là, les données sont envoées brutes à la bd ou déjà protégées par un mysql_real_escape_string?

Code :
[== Indéfini ==]
$query = 'INSERT INTO '.cms_db_prefix().'module_products_fieldvals (product_id, fielddef_id, value, create_date, modified_date) VALUES (?,?,?,?,?)';

$db->Execute($query, array($idA, $fid, $fival, trim($db->DBTimeStamp(time()), "'"), trim($db->DBTimeStamp(time()), "'")));
Répondre
#4

Citation :lorsqu'on utlise des fonctions comme celle là, les données sont envoées brutes à la bd ou

c'est une requête normale qui passe simplement par ADOdb ou ADOdblite suivant la version du cms

J-C Etiemble v 2.2.xx
Répondre
#5

je m'en suis rendu compte en vérifiant plusieurs éléments.
ayant un soucis avec mysql_real_escape_string je pensais qu'une première couche de protection étaient appliquée mais en fait non, c'est les magic_quotes _gpc qui sont activées sur le serveur provisoire que j'utilise.
donc, pour prévenir des injections sql, je fais comme ça:

Code :
[== Indéfini ==]
$db->Execute($query, array_map('mysql_real_escape_string',(array($idA, $fid, $fival, trim($db->DBTimeStamp(time()), "'"), trim($db->DBTimeStamp(time()), "'"))));

est-ce une façon correcte de gérer le truc?
Répondre
#6

La fonction "prepare" d'Adodb intégré à CMSMS est-elle disponible ?
C'est, d'après ce dont je me souviens, la méthode la plus fiable de sécuriser une requête.
Répondre
#7

je sais pas, va falloir regarder car avec mysql_real_escape_string j'ai du faire un plugin pour stripslasher les données affichées dans les templates du module concerné, plus je dois rajouter un nl2br pour garder mes retours à la ligne rentrés en textarea.
C'est géré comment dans formbuilder?
Répondre
#8

Citation :c'est les magic_quotes _gpc qui sont activées

Cette fonctionnalité est OBSOLETE depuis PHP 5.3.0. Nous vous encourageons vivement à ne plus l'utiliser.
De plus supprimée en PHP 5.4

J-C Etiemble v 2.2.xx
Répondre
#9

je le sais bien, c'est pour ça que j'ai demandé sa desactivation.
Mais ils sont pas vraiment réactifs question hotline chez mon hébergeur!
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 2 visiteur(s)