bonjour tout le monde !
Je débute depuis peu dans le php et on me demande de faire un site dans ce language dans le cadre de ma formation (alors que l'on nous a rien a ppris encore, c'est à nous d'apprendre par nous même !!).
Donc j'ai, comme vous pouvez l'imaginez, quelques peitites questions a vous poser !!
 
Je dois faire une zone admin protégée, c'est ce que j'ai fait, mais je n'ai pas utilisé de base de donnée, j'ai tout simplement mis un :
 if... password="*****"... { page admin} else { page de connexion du site }
donc en fait, dans cette page php, il y a la page admin et la page de connexion. Je voulais donc savoir si elle etait bien protégé ?? pâr rapport a une connexion classique avec sessions, md5 et base de donnee...
(http://klsnet.free.fr/gym/site_gym [...] nexion.php)
 
Autre petites question, j'ai un tableau avec des champs qui doivent être facilement modifiable par l'administrateur, peut on le faire sans base de donnee, avec des fichier texte par exemple ? je sais, le mieu, c'est la base de donnee, mais j'aimerais savoir si c'est possible sans !!
 
Merci d'avance pour vos reponses...

t'aimes pas les bdd?  
c'est pas si compliqué tu sais...
désolé de ne pas répondre explicitement à tes questions mais y'a des gens plus calés pour ça.
je sais pas si tu as pensé à mettre un htmlentities pour tes mots de passes et login par exemple, afin d'empecher certaines personnes de rentrer du code dans tes champs de saisie.
 
au fait ta formation c'est quoi?
 

Après pour ta question sur l'obligation d'utiliser une base de données... tu peux aussi passer par des fichiers textes (fonctions fopen, fgets, fputs, etc) si le volume de données n'est pas trop volumineux.

vu que le mot d epasse est défini dans la source en dure tu ne peux pas passer de code dans les champs input Flock86.
 
quand tu passes du code c'est pour les failles de type SQL injection, et le but est de modifier la requete SQL initiale afin de supprimer le mot de passe par exemple. Là c'est complétement différent. Tu n'as pas de SQL donc pas possible d'utiliser cette faille.
 
Là il faudrait voir son code, la seule faille potentielle que je verrai c'est s'il définit mal ses variables qui vérifie l'accès à admin. Par exemple passer la variable de vérification dans l'url. A voir
 
Pour ceux qui veulent montrer leur source : http://paste.clicksources.com/

ok newneo2001!
c'est vrai j'avais pas réfléchis bien loin, là dessus.  
c'est devenu un automatisme pour moi cette méthode, alors dès que je vois un champs...lol je balance ça et voilou..

oui je sais mais il vaut mieux filtrer tous tes champs normalement.
C'est un bon automatisme.
 
Parce que c'est pas impossible qu'on découvre une faille de type BOF par exemple un de ces 4 sur les variables PHP. Enfin je pense que ca serait déjà fait si ca existait.
 
Pour mémo pour ceux que ca intéresse on filtre les variables par 2 fonctions
html_entities (pour éviter les faille XSS)
addslashes (pour les failles SQL injection)
 
Voila ++

newneo2001 > "html_entities" et "addslashes" ne filtrent pas les données, elles neutralisent leur contenu en rapport à certaines attaquent.
 
Si on veut filtrer les données, alors il vaut mieux utiliser "is_numeric" et autres fonctions du genre ainsi que quelques fonctions maisons permettant de faire vérifications plus évolué (validité de l'adresse mail, texte ne contenant que des caractéres autorisés, ...)
 
Quand à "addslashes" si c'est pour éviter du SQL injection, alors il ne faut l'utiliser que s'il n'existe pas une fonction équivalente et spécifique à la base de donnée choisit. La fonction spécifique doit toujours être préféré à une générique qui laissera passer certaines attaques. Par exemple pour mysql, il faudra utiliser "mysqli_real_escape_string".

kl14582 > Si tu veux sécuriser ta page, alors rajoute un

juste aprés le premier <? ou <?php .
Ca t'affichera toutes les erreurs et alertes.
 
Ca te permettra entre autre de vérifier que tu n'utilises pas de variable non initialisé. (si "register_global" est à "on" dans le php.ini alors en faisant un simple "http://tonserver/tapage.php?nomdevariable=valeur" on peut donner une valeur à chaque variable non initialisé.) C'est une faille vu qu'on pourait alors provoquer l'exécution d'une partie de ton code php alors que ca n'aurait pas du être le cas.
 
Pour ton test du mot de passe, j'espére que t'as fait un [/code]if... $password=="*****"...

comme indiqué dans ton premier message. Si t'as mis qu'un seul "=" alors php vérifierais juste que la valeur a bien été affecté à la variable $password (ce qui est toujours le cas) tandis qu'avec un "==", on vérifie que la variable à la même valeur que la chaine de caractére.
 
En dehors de ça, ca a l'air théoriquement assez bien sécurisé à premiére vu mais il faudrait voir le code de la page pour en être sur.
 
 
PS : Le "error_reporting (2047); " sera à mettre en commentaire quand tu montreras ta page à ton professeur ou à d'autres personnes. Ca évitera qu'ils ne voyent les failles éventuelles. En fait, c'est une ligne à ne mettre que pendant qu'on dévelope une page et à enlever aprés.

omega2 >  
 
newneo2001 > "html_entities" et "addslashes" ne filtrent pas les données, elles neutralisent leur contenu en rapport à certaines attaquent.
 
c'est un peu une question de terminologie là quand même, je reprend donc en disant :
 
tu traites au préalable tes variables avec les fonctions html_entities et addslashes.
 
Pour compléter, avant évidemment tu initialise toutes tes variables à grand coup de  
$var = isset($var) ? intval($var) : null
et tu remplaces intval() par les fonctions dont tu as besoin.
Tu utilises même les expressions reg pour vérifier la validité des adresses mail.
 
Je sais, j'avais déjà posté un message pour un problème comme ca (notamment addslashes et mysql_real_escaped_string, tu as aussi le problème de savoir si GPC_quote est à on ou off aussi). Je donne plus d'explication dans le post ci dessous :
 
http://forum.hardware.fr/hardwaref [...] m#t1315957

Voici le code de ma page ( code allégé pour que vous vous y retrouviez !!) :

pour filtrer les données, faut pas oublier strip_tags()

>flock86
ma formation : premiere annee de servic et réseau de com en iut
 
 
>rufo
Tu peux t'expliquer un peu plus, je suis novice en php et j'avoue que je ne connais pas cette fonction (strip_tags() ) et sa fonction, que veut dire "filtrer les donnees" ??
 

http://fr3.php.net/manual/en/function.strip-tags.php
 
filtrer les données => tu ne prends pas telles quelles les données fournies en entrée par l'utilisateur, surtout s'il s'agit de champs texte (il y aura peut-être glissé du code php, html, etc.)

Ok mais d'après newneo2001 qui m'a répondu quelques post avant, dans mon cas, je n'utilise pas de bdd et tout se passe sur une seule page php donc on n'a pas besoin de filtrer les donnees entrées par l'utilisateur, il ne pourra pas mettre de html ou autre langage. Enfin c'est ce que j'ai compris...

 
c'est pas une histoire de BD. Si y'a des champs textes dans ton IHM (des formulaires), alros il faut filtrer ce qui est saisi.

addslashes ne fonctionne pas correctement, ne jamais l'utiliser pour escaper une valeur, utiliser les fonctions db-specific (pour mysql c'est "mysql_real_escape_string" )

Non, ne jamais utiliser addslashes
 
Et html_entities s'utilise à l'affichage des données, pas à leur stockage en base (contraitement à *escape_string)

 
C'est intéressant ce que tu dis à propos de addslashes(). Qu'est-ce qu'on lui reproche au juste. Que l'échappement des caractères diffère suivant les sgbd et que donc, addslashes() ne garantirait pas un échappement correct de tous les caractères dans la BD?

En gros, c'est ça. Addslashes échappe ce qui est définit comme dangereux dans PHP, pas ce que le driver de DB définit comme dangereux (== ce qui est réellement dangereux dans la DB)
 
Exemple simple sur mysql, il est défini que \n, \r et \x1a doivent être échappés, addslashes ne les échappe pas....
Et comme les besoins d'échappements varient en fonction du SGBD, au final addslashes est dangereux et inutile dans tous les cas, parce qu'au lieu d'être un wrapper sur les échappements des DBs, c'est un escaping "tiers" sans aucun lien avec les besoins réels.
 
En fait, ça devient encore plus marrant si on utilise pas MySQL: SQL Server n'utilise pas le backslash (\) pour faire ses échappements, pas plus qu'Oracle il me semble => addslashes a une utilité nulle si la DB est en access ou sql server...
(la norme ANSI SQL définit que le caractère d'échappement est la quote ', le backslash est une extension non standard de MySQL et PostgreSQL).
 
Enfin bon, dans l'idéal le mieux est vraiment d'utiliser des prepared statements au lieu de faire ça à la main comme un cochon...

non je reprends, faut pas citer qu'une partie de ce que je dis non plus.
 
j'ai dit pour les failles SQL injection, il faut utiliser mysql_real_escaped_string() qui est fait pour ça.
 
et ce que je disais c'est que pour la vérification de ta zone admin kl14582 tu vérifies if $_POST['pass'] == 'password'
 
donc là je disais que tu ne peux pas corrompre ça en envoyant des " ou des ' , > dans ton formulaire. Mais qq lignes en dessous je te dis de protéger tes variables si tu les affiches ...  
 
Par contre oui il faut TOUJOURS vérifier les variables passées par l'utilisateur.  
 
REGLE n°1 en PHP, ne jamais faire confiance au variables saisies par l'utilisateur.
 

Je ne l'ai pas fait, relis ton message, tu dis texto qu'il faut utiliser addslashes pour les failles SQL injection et c'est faux.

C'est pas une règle de PHP, c'est une règle de programmation tout court

c'est vrai que j'ai marqué ça, mais c'est plus dans le sens que le addslashes escape les ' et c'était le but.
 
mais je parle bien d mysql_real_escape_string.
 
d'ailleurs j'ai même posté une fonction que j'utilise en début de toutes mes pages et qui supprimes le "addslashes" rajouté par la plupart des serveurs qui sont configuré avec magic_quotes_gcp. C'est à dire beaucoup.