Reprise du message précédent :

olol comme tu te prends la tête pour rien    
Ton histoire de md5, non seulement c'est inutile, mais en plus ça va nuire au référencement de tes pages. Bah oui, je te rappelle que les adresses de tes pages, c'est plus mieux si elles sont explicites, et en rapport avec la page.

Tant que tu sais exactement à quoi t'attendre au niveau des paramètres, c ok.
 La meilleure méthode sera la plus rapide. Au niveau rapidité (j'ai pas fais les
test),
j'imagine qu'une comparaison d'entier est plus rapide qu'une comparaison
alphanumérique.
De meme que la comparaison alphanumérique (ctype_alnum) devrait etre plus rapide
qu'un regexp.
 
Perso j'ai le plus confiance dans la comparaison numérique ( 13 == 13 ? ).
 
Niveau fiabilité certains utilisateurs de php.net montre par l'exemple qu'une
comparaison:
 
Citation:

 
Il est clair que le hash rend un peu "gore" dans une url.  La dessus on est d'accord.  
Mais alors pourquoi l'utiliser ? La réponse est simple : rendre la tache plus difficile à un hacker.
 
Je m'explique en voyant une url du type url?page="mot.php", on voit immédiatement que l'include est utilisé.
De plus si le filtrage est mal fait, la porte "peut s'ouvrir".
 
Avec une page du type url?page="5", on peut penser qu'il s'agit soit d'une page generee en SQL, soit d'un tableau et dans tous cas une variable récupère cette valeur. Ici page.
Conclusion on identifie une variable du script sans avoir le script sous les yeux. Si globals est ON on casse rapidement ce script.
 
Avec une page url?page="mot"&id="5". Cette fois est mal vu du coté des robots.
 
Par contre avec url/".mot."/".id."/ et un rewrite qui ne recupere que le "id". On gagne:
- une url unique dans tous les cas
- le mot est toujours visible pour les bots
- le filtrage est doublé puisque nous profitons du filtrage url rewriting ET de celui PHP
- on obtient une url qui "cache" cette faille potentielle et qui peut éviter  
des problèmes  ( Pour l'effort , je pense que cela vaut le cout )
 
Pour répondre à djebel je dirais que la différence entre :
 
-http://www.domaine.com/page/id/
et
-http://www.domaine.com/page/
est si elle existe (?) infime .

 
Pardonne le caractère cru de mon langage, mais c'est du branlage de mouches.
 
 

 
L'obfuscation n'est pas une méthode fiable en matière de sécurité. Les exemples sont légion.
 

Non.
 

L'important est donc de bien faire le filtrage, pas de passer du temps à masquer un filtrage mal fait. D'autant qu'un filtrage efficace est relativement simple à mettre en oeuvre.
 
 

Tiré par les cheveux. De toute façon la majorité des paramètres passés à une page sont utilisés dans des requêtes de base de données. Donc sans grand intérêt.
 

"register_globals ON" est une des pires idées qu'on puisse avoir d'un point de vue sécurité. C'est même pas la peine de parler de sécuriser une application PHP avec register_globals activé.  
 
Le coeur de la sécurité en PHP (et en développement web) ce sont les points d'entrée de l'application. Par point d'entrée on entend les paramètres des URLs de l'application. Tout ce qui permet d'envoyer des données à l'application. Une application sécurisée se caractérise en premier lieu par:
- un minimum de points d'entrée (le strict nécessaire)
- une validation systématique des données passant par les points d'entrée
(la sécurité d'une application se mesure aussi à l'aune de sa robustesse et des informations qu'elle donne en sortie, mais c'est hors de propos ici)
 
Si les paramètres d'une page sont systématiquement vérifiés, l'intérêt pour l'attaquant de les connaître - voire de connaître leur utilité - est nul. C'est le but vers lequel tendre.
 

Certes.
 

D'accord pour les 3 premiers points, aucune différence pour moi sur les points suivants. En général quand il y a des chiffres dans une URL style http://mon.site.fr/12/5/ c'est rarement des noms de répertoire. Faire l'hypothèse de valeurs stockées dans des variables est pas déplacé.
 
Le fait que ça cache le nom des variables est pas une mauvaise chose en soi, mais la sécurité d'un script ne devrait pas reposer sur ce paramètre. Jamais.
 
L'obfuscation est quelque chose que je considère personnellement comme une perte de temps. Le plus important, c'est de se demander ce qui est important à un attaquant potentiel. Le nom des variables n'est pas important, par contre la version de php si par exemple. Faire ce tri là est important.
 
Par ailleurs, il est préférable de passer du temps à blinder ses pages qu'à obfusquer les manquements potentiels à la sécurité. C'est une bien meilleure façon de sécuriser ses scripts et d'éviter un faux sentiment de sécurité.

et op, tu vois plus l'include.
 
forcement, si tu fais  
 

On connait l'include, et tu peux tout faire peter

On est bien d'accord krisscool que je n'aborde pas le filtrage d'input.
Mon premier post avait pour simple objectif de présenter une méthode, fiable.
De plus je ne peux pas écrire un roman, et étudier toutes les possiblités de failles pour chaque affirmations postées.
 
J'ai déliberement choisi de présenter une méthode qui je trouve est bonne.
 
J'arrete la !

On a délibérément choisi de te montrer que la méthode de ton premier post est inutile, présente des désavantages, et n'améliore pas la sécurité d'une appli correctement conçue
Donc avant de faire du méli-mélo, autant concevoir l'appli correctement ça sera plus simple.
 
Je plussoie sur toute la ligne le post de kriscool. J'ajouterais que l'obfuscation n'est non seulement pas une méthode fiable de sécurité, mais qu'en général ça n'obfusque que le développeur qui vient après toi.

supermofo :
entre :
http://mon.site.fr/12/5/
http://mon.site.fr/forum/5/
http://mon.site.fr/index.php?page= [...] ection=php
http://mon.site.fr/index.php?page= [...] n=md5(php)
 
Qu'elle est l'url présentant le plus de risque? En fait, aucune n'est plus sécurisé que les autres.
Pour la premiére, il suffit de changer un nombre pour changer de section (facile de repérer lequel si le site présente plusieurs adresses au visiteur)
La seconde est pareil que la premiére à part que ca demande de trouver le bon mot. (augmentation de la sécurité trés trés trés trés faible au final)
La troisiéme est aussi peu sécurisé que la seconde.
Quand à la derniére, c'est simple, un code md5 à une structure vraiment trés simple à repérer. Il suffit donc d'utiliser un petit programme de rien du tout et de tenter le md5 correspondant à des mots clés (comme "admin" ) pour passer outre cette obuscation.
 
 
Au final ce qu'il y a à retenir? L'obfuscation par hachage de mot, remplacement de mot ou url rewriting ne changera strictement rien à la sécurité d'un site basé sur un include (dans tous les cas, on sait quoi changer dans l'adresse rien qu'en regardant 3-4 pages du site) D'un point de vue sécurisation, ca n'est que de la poudre aux yeux destiné à berner ce qui n'y conaissent rien en sécurité informatique.
La véritable sécurité, c'est du côté du code php/asp/jsp/autre que ca se passe.

Oui oui mais je crois que personne n'a lu le morceau de code suivant. de mon 1er post.
 

 
Apres on me dit que le md5 sert à rien. J suis desolé mais tu pourras pas injecter des admins ou autre puisque:

 
Ensuite on me sort la LECON sur la sécurité. Je pense m'adresser à un public suffisamment connaisseur pour savoir les bases ( INPUT omg ! ).
 
Essayer de lire les posts avant d'assassiner les gens.
 
Vas me trouver un moyen de contourner ce filtrage <<<<D INPUT>>>> !!

  de quoi qui parle ?
 

ça apporte rien de plus niveau sécu tes méthodes, ça rend juste le tout plus prise de tête.

Si le développeur qui a le code comprend rien, le hacker sans le code y comprendra encore moins  

 
En même temps la vraie sécurité c'est quand le hacker comprend qu'il peut pas contourner la protection.

Un hacker contourne tout s'il le veut   La seule solution de pas se faire hacker c'est de rien faire  

 
Fondamentalement oui, s'il a des ressources illimitées. Sauf que dépenser plusieurs millions d'euros et passer des semaines pour pirater le site de la Pizzeria San Maria, c'est pas tout à fait réaliste

Celle là    
 

 
Certes, c'était juste pour le principe    
 
[HS]
La pizzeria San Maria utilise php pour présenter son adresse et sa liste de pizza à prix fixe  
[/HS]