Je lis, par ci, par là, different truc au niveau de la sécurité avec php qui me fond réfléchir, par exemple:
 
les include c dangeureux
les formulaires post ca peut etre dangeureux
les parametres dans les url c dangeureux
 
mais alors comment on doit monter ses pages  

Commence par lire ça :
http://www.nexen.net/interview/index.php?id=30

 
jen ai lu une bonne partie tout a l'heure
 
mais jdonne un exemple, jai un formulaire d'inscription, donc dois-je me dire que chaque champs est une menace et doit être validé?
 
faut devenir paranoïaque de tout?

Bah ça dépends c'que tu fais des paramètres après..

bin des exemples:
 
J'ai des formulaires pour des ajouts dans ma base de données, du genre ajout de user, ajout de menu, ajout de nouvelles, je passe tout les champs par post et ensuite jfais l'entré dans la bd
 
J'avais concu mon site d'une maniere à ce que j'aille un "template" dans lequel je ne faisais qu'inclure mon corps. J'avais donc un require_once d'un fichier php pour chacune des pages

les includes :
dangeureux si t'as du code qui se promènes en dehors de toute classe et de toute fonction.
 
les formulaires :
dangeureux si quelque part tu réaffiches tel quel la saisie d'une zone assez grande pour contenir du code javascript ou tout autre code exécuté côté client.
 
les paramètres dans les URL :
dangeureux si une partie de ces paramètres est une valeur sensible et que la vérification corespondante a cette valeur est incomplète ou inexistante.
Par exemple, dans beaucoup de site, il y a une page principale et cette page inclus toutes les autres en fonction d'une variable passé dans l'URL. Si on vérifie pas cette valeur, ou plustôt si on vérifie pas que le visiteur a le droit de voir la page corespondant a cette valeur, il suffit qu'un visiteur modifie l'URL pour rentrer dans les sections a accés réservé tel que la page d'administration du site.
 
Voilà pour le domaine de la sécurité, les conaisances de bases a conaitre a mon avi, pour la création de tout site web dynamique.

Oui, c'est dangeureux si certaines de ces variables sont testé dans la page principale et pas dans la page incluse. Ca veut dire qu'une personne mal intentioné peut sauter par dessus ces tests en appellant directement la page incluse.
D'un autre côté la page principale peut initialiser des variables utilisé par le code de la page incluse et si la valeur de la variable _POST["var"] est aussi donnée automatiquement a la variable $var alors il risque d'y avoir des problèmes vu qu'en appellant directement la page incluse on peut donner n'importe quelle valeur a n'importe quelle variable.
 

Dans ce cas là, c'est vrai que c'est un cas particulié dontt j'aurais du parlé, c'est pas vraiment dangeureux vu que la seule personne qui subirait le code saisie par une personne est elle même. Mais si le formulaire est bien remplis, tu vas surement enregistrer les valeurs quelque part et si tu les restitue a n'importe qui sans auccune modification, alros là, il y a un risque.
 

Moi aussi, j'ai fait ça. Au moins il y a un truc pour lequel j'ai pas fait de bourdes.
 
Bonn en fait, au lieu de parler de danger, j'aurais mieux fait de parler de dangger potentiel.

bin en fait jveux vraiment voir les possibilités d'attaques possible.
 
Je suis avec un copain au départ d'un code d'un intranet + site web. Dans tout ca, va il y avoir de la gestion de serveur et c surtout pour ca que je veux sécuriser le plus possible.
 
Donc la jvois des possibilités d'attaques, mais j'ai plus ou moins de solutions
 
pour en revenir à mes includes... ils sont dans un dossier include/ avec un htaccess qui fait un deny all
 
dans ce cas, jcrois pas que personne ne puisse appeler ces pages d'un moyen externe, vrai? selon moi c'est sécuritaire, car les seules pages pouvant appeler ces script php sont les miennes
 
La seules page pouvant être appelé de l'externe est mon index.php, qui lui appele mes modules de menu et de corps

Tu peux aussi mettre tes includes dans un répertoire en dehors de l'arborescence du site.
 
Par exemple pour apache :
Le site est sur /home/www, donc dans httpd.conf, tu as DocumentRoot=/home/www
 
Si les includes sont dans /var/www_includes par exemple, il seront inaccessibles pour un visiteur.
 
Pour protéger les paramètres en POST et GET, il faut impérativement que register_globals soit off dans php.ini ce qui est le cas par défaut à partir de php 4.2.0.
Il faut aussi "échaper" tous les caractères spéciaux du genre ' ou ". et changer les < et > en &lt; et &gt;
 
Ce sont des recomendations de bases, mais ont peux bien sûr aller plus loin.
 
Par exemple, dans un fomulaire qui propose un <select>, le code PHP devrais vérifier que la valeur reçue fait bien partie de celles qui ont été proposées.
 
C'est pas forcément une simple question de sécurité, çà sert aussi à limiter les bugs.
Pour que ce soit efficace, il faut mettre en place un système qui permette de faire automatiquement des vérifications de base sur les variables reçues. Les controle peuvent se baser sur une convention de nomage des variables.
 
Sur un site sur lequel je travaille, les formulaires sont décrit dans un formalisme XML. Ils contiennent les requêtes à exécuter, et chaque champs est typé. Ensuite un coup de XSLT permet de générer le HTML à envoyer au client. Tout ce qui permet de faire les vérifs est enregistré en session. Quand les données d'un formulaire sont reçues, une moulinette standard passe chaque variables en revue et fait des vérifications en fonction de son type : dates, nombre, choix de case à cocher ou de liste <select>, tout çà à partir des infos en sessions.
 
Pour éviter au maximum les riques d'injection SQL, aucune requête dépendante des données saisie n'est éffectué directement en PHP. Tout passe par des procédures stockées. Dans notre cas, c'est Oracle, mais çà pourait être SqlServer ou postGreSql.
La totalité des traitements de mise à jour des bases est réalisé par des procédures stokées. Les procédures et leurs paramètres sont tous référencés dans des tables, ce qui permet d'avoir un minimum de code spécifique en PHP. Tout est décrit. Notre formalise XML nous permet d'indiquer la ou les procédures à utiliser, dans quelle ordre, condition etc...
 
Bon c'est un peu lourd à mettre en place, mais le principe de base est toujours d'éviter les redondances de code, et surtout de ne pas faire confiance au Client !

et surtout de ne pas faire confiance au Client !
 
pendant 3 années d'études en informatique, on n'a pas cesser de me dire ca et j'ai fini par y croire
 
finalement, dans ma derniere session de cours, ils nous ont données un cours de communication pour diminuer l'influence que les prof ont eu sur ns vis à vis les client  

sinon en réalité, qu'est-ce que vous pensez que je dois faire pour sécuriser mon site? tout les truc mentionnés? ca va grossir mon code de 3 fois surement  

sécurité n'exclut pas facilité

j'ai pas calculé combien de ligne de code corespond a la mise en place d'une sécurité, mais je suis quasiment certain que ca doit faire moins 1/30 éme de la totlité.
 
Mara's dad > Je vois pas en quoi une reqquête stocké est moins dangeureuse qu'une requête écrite par du code php.
Si le code qui créé la requête est bien écrit et que personne ne s'amuses à la modifier alors ca reste aussi sécurisé.
Et si une requête doit être modifié, il y a autant de risque d'erreur humaine que ca soit une procédure stocké ou une requête clasique.
Par contre, vote système de vérification des variables, elle a l'air vraiment costaud.
Dernière remarque : pour le register_global, beaucoup d'hébergeur gatuit le gardent a on alros il vaut mieux être courant de ce risque de problème de sécurité.

Une requête stockée, c'est comme du code compilé, alors qu'un requête écrite en PHP et ensuite transmise au serveur Oracle, ben c'est une requête dynamique que le serveur doit analyser avant de l'éxécuter. La version en procédure stocké est plus rapide que l'autre et plus sécurisée.
 
Par exemple pour une requête de vérification de user/MDP :
 
En php (sans vérifs particulière...):
 

 
Quand on fait çà, y'a un risque en fonction du contenu de $_POST['login'] et / ou de $_POST['password']
 
Un utilisateur mal intentionné qui connais un login ( par exemple "omega2" ) peut essayer de mettre un truc du genre "x' or '1'='1" comme mot de passe.
 
La requête envoyée par PHP devient :
 
 
"select UserName from Users where login='omega2' and password='x' or '1'='1'"
 
Et on entre alors sans avoir à connaitre le mot de passe...
 
 
Avec une procédure stockée, c'est impossible de faire çà :
 
en PL/SQL :
 

 
Dans ce cas, lors de l'appel à la fonction Oracle "authentification" en PHP, il sera impossible de changer la requête.
Quelle que soit la valeur passée à la fonction dans p_pass, l'intégralité du contenu de p_pass est considéré comme une chaîne unique.
Dans "AND motdepasse=p_pass" c'est le contenu du champs motdepasse qui est comparé au contenu de la variable p_pass.
Dans la version PHP, le danger vient du mélange entre code et donnée. C'est le principal problème avec les requêtes dynamiques.
 
Je ne dis pas qu'il est impossible de sécuriser des requêtes dynamiques, je dis que c'est plus simple avec des procédures stockées. En cas de modification de la requête, la sécurité est a revoir en PHP, ce qui n'est pas une charge négligeable.
 
Pour le register_globals, les règles pour se protéger sont simples:
 
- Initialiser toutes les variables avant utilisation. Un bonne habitude, c'est de faire comme si les variables devait-être déclarée. Donc en début de fonction, on "déclare les variables en les initialisant". Il faut donc éviter au max le recours à des variables "Globales" dans les fonctions...
 
- Ne pas utiliser une variable de $_POST ou $_GET sans un minimum de vérification de type, et contenu. Par exemple, pour un mot de passe, on peux décider des caractères autorisés. Cà permet d'éviter les problèmes d'injection SQL...
 
Remarque :
ne pas faire confiance au Client doit s'entendre dans une relation client/serveur. Le serveur WEB ne doit pas faire confiance au client Browser. Par exemple, c'est pas parce-que votre page est censée vérifier en Javascript qu'un Mot de passe ne doit contenir que des lettres et des chiffres qu'il faut croire, coté PHP, que les vérifications ont été faites !
 
Les vérifs Javascripts ne servent pas à la sécurité, mais à l'ergonomie.
 
Quand à savoir si un prestataire de service doit faire confiance au client, ben c'est une autre histoire

Mara's dad, j'avais JAMAIS pensé a un truc pareil. Merde tiens.
 
A part la procedure stockée, comment tu veux te protéger de ca ?
 
Entre autres, pourquoi un "include" est danereux ?
 
Mes include  a moi sont dans un rep protégé par htaccess...

D'ailleurs, en y réflléchissant bien, ton truc, mara's dad, ne marche que si le pass est en clair dans la BDD.
 
Prends un exemple du gars  qui hashe son pass en MD5.
 
Avant de faire sa  requete, il va  appeler MD5($pass)...
 
Et la comment tu veux passer outre ? Même avec des  ' et autres " c'est DSC...

 
Si un include ne contient que des fonctions ou des déclarations de variables, y'a pas de danger à la condition de les nomer avec une extention traité par PHP.
Certains on pris l'habitude de nomer les includes en .inc, et là le problème c'est que si les fichiers ne sont pas protégés par un htaccess, ben le code php est envoyé au navigateur. Ce qui peut être  facheux pour un include qui contient un mot de passe d'accès à un BD.
 
La protection par htaccess, c'est très bien aussi, mais un poil plus compliqué à gérer.
 
Tu commence à comprendre pourquoi c'est risqué de réinventer des systèmes de sécurité au lieu d'utiliser ceux qui font leurs preuves tous les jours ?

oui, mais c'est aussi applicable pour les delete
ex: delete from table where id='aaa'
si tu récupères l'id par lurl (genre delete.php?id=aaa), le client peut mettre "aaa' or 1" dans ton url

 
Je nomme tjs mes include en *.php, et ils sont dans un réppertoire protégé par htaccess...
 
je vois pas trop la difficulté à gérer du truc m'enfin
 
Pour le delete, oui, j'y avais pas pensé... aiou.
 
mais la comment tu veux te protéger de ca ?
 
perso, j'utilise tjs  des  variables de  session, et pour avoir acces a des données X  l'user  doit etre loggé, donc encore une fois la je vois pas comment il peut faire ...
 
PS : le pire truc  de secu que j'ai vu c'était un truc (pas  de moi) 'display.php?file=fichieralacon.txt'  
 
Trop facile le  display.php?file=../../etc/passwd'

 
dans mon exemple, j'ai mis une chaine de caractère, mais, en général, mes id sont des int, donc je teste que la variable que je récupère osit bien un int.
si c'est une chaine, tu peux interdire la présence d'espace et donc tester que que l'id que tu va suppr ne contienne pas d'espace

Mara's dad > Dans une requête sql fabriqué en php, je ne prends jamais directement les données saisie par l'utilisateurs.
Je fais toujours un add_slashes ne seraisse qu'a cause de la possibilité de la saisie d'un nombre imper de " ce qui fait planté la requête.
Du coup, je n'ai pas ce problème là de sécurité.
 
Mais c'est sur qu'au niveau de la rapidité, les requête stockée  sont considérés comme plus rapide. Moi, je l'ai aient jamais utilisés dans mon site tout simplement par ce que je ne sais pas si mon hébergeur les autorises.
En plus, je compte mettre dans quelques mois une partie de mon site en open source alors mêm si en changeant d'habergeur je peux les utilisés je préfaires les éviter du moins pour cette partie là.

Et il faut pas oublié également de vérifié que le visiteur a le droit de suprimé cet enregistrement là.

 
Encore une fois, je ne dis pas qu'il est impossible de faire attention ! (T'as lu çà http://www.nexen.net/interview/index.php?id=30 cité plus haut ? )
 
Le coup du MD5($pass) est une méthode, mais est-ce suffisant dans tous les cas ? Non, çà l'est peut-être pour la requête de vérification du LOGIN/MDP, mais y'a plein d'autres requêtes dans une appli...
On peut aussi jouer avec le login :
 
Par exemple, l'utilisateur envoie çà :
 
$_POST['login'] = "omega2'; drop table posts; select count(*) as toto from UserName where '1'='1";
$_POST['password'] = "motdepassebidon";
 
Tu fais un gentil $MDP=md5($_POST['password']);
 
Et tu exécute la requête qui devient :
 
"select UserName from Users where login='omega2'; drop table posts; select count(*) as toto from UserName where '1'='1' and password='CHARABIA_EN_MD5'"
 
Et qu'est-ce qui se passe à ton avis ?
 
Essaye avec phpMyAdmin tu va voir, c'est rigolo !
 

putin c trop fou    
 
sinon pour les procédures stockés, jdéveloppe avec easyphp et mysql pour le moment, comment jpeux faire ca?

et pourqoi ca donnerait pas plutot
 
 
"select UserName from Users where login='omega2' and password='x or 1=1' "
 
   ?

 
Heu, ben c'est le problème avec mysql, y'a pas les procédures stockées...
 
T'es obligé de faire SUPER gaffe à tes requêtes.
 

 
Parce-que je met des ' dans le mot de passe. Pour que çà ne pose pas de problème il suffit de le échapper. Faut juste penser à le faire...

 
ca c'est bien ce que je reproche a MySQL : pas de procédures stockées, pas de PL/SQL, pas de triggers

attendre MySQL 5  
 
*soupir*

 
Y'a PostgreSql !

 
ben je l'ai déjà  dit a mmon hébergeur mais bon

et passer les variables dans des fonctions comme mysql_real_escape_string(), mysql_escape_string()
 
c une solution?

je viens de faire un truc en local (marchera sans doute pas chez les hébergeurs et c'est dommage ), c'est carrément interdire l'accès aux fichiers .inc (mes includes sont en .inc). Directement dans httpd.conf.
 
Sinon pour les pages, je fais toujours une vérification exhaustive des paramètres en entrée, paranoia inside

bin le faire dans httpd.conf ou placer un .htaccess deny all *.inc dans le dossier des .inc ca revient pas mal au meme

ben au niveau rapidité en tout cas le httpd.conf est mieux
 
et puis j'ai pas encore compris comment activer les .htaccess

 
ca c mon .htaccess qui se trouve dans mon dossier www/include/

j'ai quasi la config par défaut d'Apache et il ne semble pas prendre en compte mon .htaccess

avec easy php 1.6 ca marche #1...