Bonjour, vous attendez de la communauté un support le plus précis et le plus rapide qu'il soit !
Vous débutez avec Maximus, veuillez consulter de prime abord ce fil de discussion, et celui-ci ... De notre coté, nous sommes désireux d'apporter le support le plus adapté qu'il soit à chaque situation ... Pour commencer, avez vous consulté le wiki maximus et/ou les tutoriaux ???
Aussi la solution est simple et applicable rapidement: 1 ) Pour tout nouveau fil de discussion, mettez un titre le plus explicite possible 2 ) Remplissez du plus précisément possible votre mini-fiche 3 ) Pensez qu'une réponse peut être postée plusieures heures voir quelques jours après votre question, il est donc bon de remonter le sujet de temps en temps mais point trop n'en faut :) 4 ) Pensez que Maximus est livré avec le forum bbToMax version 1.0.0 à l'origine, et que vous trouverez la dernière version 1.0.2 de disponible sur www.bbtomax !!! 5 )Vous reconnaissez, en postant sur ce site, avoir pris connaissance du règlement interne ! Nous vous souhaitons une forte réussite dans votre projet par le biais de Maximus CMS.
Inscrit le: May 16, 2005 Messages: 241 3811 points
Lieu de résidence
Sujet du message: XMFbin et XMFnum: proposition d\'améliorations Posté le: Sam 20 Oct, 2007 1:34 am
Tester si une variable est un booléen ou integer
(fonctions de la classe DB)
voici le code de ces fonctions:
Code:
function XMFbin($var) {
$var = intval($var);
if (ereg("^[0-1]$",$var)) {return $var;}
else {query_die(XMFbin_ERROR, 'XMFbin not allow '.$var.'', '', '', '', $var);}
}
function XMFnum($var) {
$var = intval($var);
if (ereg("[[:digit:]]$",$var)) {return $var;}
else {query_die(XMFnum_ERROR, 'XMFnum not allow '.$var.'', '', '', '', $var);}
}
Ces 2 fonctions sont améliorables
Les 2 fonctions commencent par:
$var = intval($var); à supprimer dans les 2 fonctions.
tester un booléan avec XMFbin($var)
$var = 2 provoque query_die() = NORMAL
$var = 'a' ou tout caractère non numérique et XMFbin($var) renvoie 0 (soit false) NORMAL ?? (plus ou moins)
si on supprime $var = intval($var); soit $var contient 1 seul caractère et qui ne peut être que 0 ou 1 (c'est donc bien un boolean) soit on provoque un query_die()
maintenant $var ='a' déclenche un query_die()
tester un integer avec XMFnum($var)
$var ='1230' renvoie 1230
$var = '1 230' ou $var = '1.230' renvoient 1 . Ce n'est pas satisfaisant.
Voici une syntaxe qui évite ce problème.
Code:
function XMFnum($var) {
if(preg_match('`D`',$var)) // présence d'un caractère autre qu'un chiffre
query_die(XMFbin_ERROR, $var.' is not an integer', '', '', '', $var);
else {
$var = intval($var);// élimine les 0 gauches éventuels
return $var;
}
}
dans ce cas $var ne peut contenir que des chiffres, du début à la fin de la chaîne, ou déclenchement d'un query_die()
$var = '1230' renvoie 1230
$var = '1.230' déclenche un query_die()
$var = '01' renvoie 1
Participez sur nos forums, et retrouvez en lieu et place de la publicité des informations plus précises sur chacun des utilisateurs, identifiez vous dès à présent
Participez sur nos forums, et retrouvez en lieu et place de la publicité des informations plus précises sur chacun des utilisateurs, identifiez vous dès à présent
Inscrit le: Feb 03, 2006 Messages: 2539 30038 points
Lieu de résidence
Sujet du message: Re: XMFbin et XMFnum: proposition d'améliorations Posté le: Sam 20 Oct, 2007 3:57 pm
Hello.
Juste un bémol.
Pourquoi ne pas utiliser is_bool(), is_int() et is_numeric() ?
P.S. : Juste pour dire, hein. Mais ré-inventer la roue alors qu''elle existe, ... .
Participez sur nos forums, et retrouvez en lieu et place de la publicité des informations plus précises sur chacun des utilisateurs, identifiez vous dès à présent
Inscrit le: May 16, 2005 Messages: 241 3811 points
Lieu de résidence
Sujet du message: Re: XMFbin et XMFnum: proposition d'améliorations Posté le: Mar 23 Oct, 2007 4:39 pm
[quote="Helger"]
Hello.
Juste un bémol.
Pourquoi ne pas utiliser is_bool(), is_int() et is_numeric() ?
[/quote]
le problème c'est que pour tester si c'est un booléen un integer ou un numérique, il faut d'abord convertir en booléen numérique integer, hors les données testées venant souvent d'un post d'un get ou d'une table sont nativement des strings. (j'ai supprimé pour raccourcir ce post le petit script de test écrit pour illustrer la chose.) il aurait montré de plus que is_bool ne considère pas $test=1 ou $test =0 comme des booléens, contrairement à XMFbin: il faudrait donc réécrire Maximus.
en les convertissant on retombe dans le pb de $test = "1250" et $test="1 250" qui renverra des valeurs différentes avec intval() mais toutes deux validées par XMFnum
les fonctions is_quelquechose sont donc utiles pour tester le type, mais pas pour formater (et dans la foulée tester le résultat) en booléen ou integer.
[quote="GravuTrad"]ta proposition pourrait t''elle résoudre ce type de pb?:
http://www.php-maximus.org/Maximus_CMS_posts_viewtopic_2842_0_0_.html
[/quote]
j'ai effectivement rencontré ce pb. je crois bien que c'était dans un module (news ou your_account) la valeur reçue d'une table (exemple user_active de la table users) est testée comme un booléen (XMFbin) alors qu'elle peut valoir 0;1;2;3 ou 4. Quand elle vaut plus de 1, déclenche erreur. Il me semble l'avoir signalé (scripts concernés, modifs à faire), dans mes posts sur mes modifs quand j'avais travaillé (ça doit faire un an) sur les modules news et your_account.
[quote="GravuTrad"]ahh, notre ami zorteil! super de te voir dans le coin!
[/quote]
merci pour ce commentaire sympa. En fait je ne travaille plus depuis quelques temps sur Maximus mais un autre système. De temps en temps, j'ai besoin de vérifier quelquechose sur Maximus et si je vois du code que personnellement je modifierais, je fais un post pour le team de Maximus à qui je transmets mes amitiés.
Participez sur nos forums, et retrouvez en lieu et place de la publicité des informations plus précises sur chacun des utilisateurs, identifiez vous dès à présent
Sujet du message: Re: XMFbin et XMFnum: proposition d'améliorations Posté le: Mar 23 Oct, 2007 5:17 pm
salut zorteil
j'ai bien lu et relus ton post, je vais même tester de mon coté
l'idée générale est je pense une bonne progression, reste une chose vers laquelle je voudrait tendre c'est justement d'affecter un type à chaque variable surtout les integer car on les manipule de partout
si justement dans les url on n'a plus que des integer ( et vérifiés comme tel, on élève d'autant le niveau de sécurité puisque les injection via l'url deviennent impossible ( si bien filtré bien évidemment )
c'est dans cette idée que je voulais me servir de ces filtres pour justement affecter un type aux variables
Dans tous les cas je retiens ta solution qui est une bonne évolution.
@ bientôt sur les forums
Participez sur nos forums, et retrouvez en lieu et place de la publicité des informations plus précises sur chacun des utilisateurs, identifiez vous dès à présent
Inscrit le: Feb 03, 2006 Messages: 2539 30038 points
Lieu de résidence
Sujet du message: Re: XMFbin et XMFnum: proposition d'améliorations Posté le: Mer 24 Oct, 2007 11:18 pm
Hello.
Désolé, mais pas d''accord.
Tu tansformes un string en chiffre, alors que il faudrait quand même régler le problème du script lui-même.
Si un script envoie $var=\"1\";, il n''envoie pas $var=1;.
C''est deux choses différentes et je suis bien d''accord avec toi.
Mais plutôt que de mettre une routine qui transformera le string en interger, double ou autre, faudrait quand même regarder de plus près les erreurs.
Car c''est une erreur.
Continuer dans ce sens et justement un non sens.
Et dire que Max a sa plupart des chiffres-nombres envoyés en string, faut quand même pas exagérer.
Je te redis désolé, mais ta manip ne fait que palier les erreurs d''autrefois.
Stop.
Ne palions pas, corrigeons.
Et là Max sera un grand.
Merci pour lui.
Participez sur nos forums, et retrouvez en lieu et place de la publicité des informations plus précises sur chacun des utilisateurs, identifiez vous dès à présent
Inscrit le: May 16, 2005 Messages: 241 3811 points
Lieu de résidence
Sujet du message: Re: XMFbin et XMFnum: proposition d'améliorations Posté le: Jeu 25 Oct, 2007 10:53 am
[quote="Helger"]Hello.
...
Continuer dans ce sens et justement un non sens.
...
Ne palions pas, corrigeons.
Et là Max sera un grand.
[/quote]
Helger, bienvenue au club: nous sommes donc 2 maintenant à dire cela.
Sur le fond je suis donc d'accord 100% avec tes affirmations (j'avais l'impression de prêcher dans le désert).
Dans le détail, je ne suis pas d'accord avec toi; Cyril le dit bien, c'est un pb de sécurité et l'injection de variables étant ma marotte, je ne vais pas reprendre mes arguments, mais redire une vérité incontournable:
personne ne peut m'empêcher d'injecter des variables avec le contenu de mon choix
hors les fonctions que tu proposes ne filtrent pas. En matière de filtration, j'ai décidé pour ma part de faire simple: soit la variable transmise est strictement conforme à ce que j'attends, soit je stoppe l'exécution.
en effet pour revenir à XMFnum (en l'occurence exemple pas très bien choisi) je ne vais pas me prendre la tête pour savoir si la valeur renvoyée différente de celle que j'attendais peut avoir un potentiel dangereux ou non. Qui me dit que ce n'est pas un moyen de contourner un filtre en amont? surtout si on fait du dévelopement mutualisé.
donc j'élimine toute variable qui à l'évidence n'est pas un integer alors que intval() va en faire un integer avec une valeur que moi je ne maîtrise pas mais dont j'imagine que l'attaquant sait ce qu'il fait.
au départ dans mes routines XMFbin et XMFnum je comparais la longueur de la variable transmise à celle de la variable transformée: il fallait qu'elles soient identiques pour que je valide. En travaillant sur les REGEX j'ai trouvé la solution que je propose, qui fait (sauf erreur de ma part) la même chose en consommant moins de potentiel.
attention aux fausses apparences et aux fausses sécurités:
Code:
// Ce code controle que les variables $admin, $admin2, $lang et $user sont bien des COOKIES
je l'ai déjà dit, et continue à l'affirmer, ce code ne contrôle rien du tout: si pas d'attaque ou attaque très primaire $admin est OBLIGATOIREMENT un cookie, même si j'ai injecté $admin par un GET (tant que l'ordre d'importation des variables sera par défaut Get puis Post puis Cookie) avec register_globals à ON ou après import_request_variables('GPC','')
Par contre je sais faire (en théorie) une attaque où $_COOKIE['admin'] contiendra ce que j'y aurais mis et non pas le cookie; il me reste à faire prendre à $admin dans la même attaque la valeur qui va bien; ça ne sert à rien puisque d'autres sécurités dans maximus pallient à cette isuffisance, mais encore une fois ce code ne prouve rien: j'ai longtemps cru que le tableau $_COOKIE contenait les cookies. Et bien pas forcément!
dans le système que je construis actuellement, j'inclue un script import_data.php où j'efface toutes les variables importées,(Get, Post, Cookie, Session) puis je retourne les chercher là où elles sont asez inacessibles et je les reconstruis une à une dans une variable de classe. Ce n'est pas sécuritaire à 100%, mais j'élimine ainsi les farceurs qui auraient réussi à imposer l'exécution de leur script dans lequel après avoir donné les valeurs qu'il faut, ils n'auraient plus qu'à inclure mainfile.php
Je ne peux rien contre les gens capables d'aller manipuler les variables au niveau du serveur et des scripts CGI, mais combien sont-ils capables de le faire?
Participez sur nos forums, et retrouvez en lieu et place de la publicité des informations plus précises sur chacun des utilisateurs, identifiez vous dès à présent
Vous ne pouvez pas poster de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas voter dans les sondages de ce forum Vous ne pouvez pas joindre des fichiers Vous ne pouvez pas télécharger des fichiers
Hebeh.com, hebergement professionnel de sites internet www.hebeh.com
Hicih.com, noms de domaine pour vos sites internet www.hicih.com
Les forums
Accueil
10 derniers posts
SQL=Can't DROP 'idlogs'
3811 points
